Re: Revised straw proposal for heuristic info

[Michael R. Blair <ziggy@martigny.ai.mit.edu>]

> "N.0" might even be taken to imply that
> the procedure accepts N required and 0 "rest" arguments, since the
> "dot" in the middle looks a lot like the dot in an argument list.

Heh heh heh.

This gives me an idea.  Why not make this less misleading by specifying a
semantics for it, like:

  3.14

means

 requires 3 arguments and excepts 1 or 4 additional rest args.

It is not as general as Guy's neat cyclic boolean list proposal but it was
just too cute not to mention.

--

Moreover...

To generalize Guy's suggestion slightly, regular expressions correspond to
deterministic finite automata which, in turn, can be represented as graph
structure.  Therefore, one could say:

 5 required args followed by any number of 2-tuples followed by 4 3-tuples

as:

  (arg)^5 ((arg)^2)* ((arg)^3)^4

which is:

  (define 2-tuple (list #f #t))
  (define 3-tuple (list #f #f #t))
  (define 5-tuple (list #f #f #f #f #t))

  (define 2-tuple* (let ((tmp (list #f #t)))
                     (set-cdr! (cdr tmp) tmp)))

  (define <a^5><a^2>*<<a^3>^4>
          (append 5-tuple
                 (cons 2-tuple*
                       (list 3-tuple 3-tuple 3-tuple 3-tuple))))

Thus, a boolean (scalar) list element matches as Guy suggested by when a
pair is encountered, its CAR and then its CDR must recursively match (where
the empty list is skipped to avoid improper lists).

This, of course, would in general require backtracking.

--

But wait!  Why stop there?  Each element could even be presented with a
prototypical type specification by using not just #t/#f but a pair, where
the CAR carries the #t/#f tag and the CDR holds a type-prototypical element:

 #t  - a boolean
 42  - fixnum
 1.0 - flonum
 (42 . 42) - a pair of two fixnums

 (lambda (x . y)
   `#(#(args: (42 42))
      #(rtns: (42 . 42))))

 - a procedure of 1 required arg and one optional arg
   where each arg must be a fixnum and
   which returns a pair of fixnums.

   You can even invoke the proc prototype spec on dummy arguments
   to reveal the arg & return value type-prototypical elements!

One would naturally reserve, say, #f to mean type `any' or `unknown' since #t
can serve as the prototypical boolean element.

I'll leave it to others to consider a tagging Scheme so that untagged
prototypes can indicate that a known constant or set of constants (one of N)
might be returned, etc.

And just imagine how wonderfully portable such a prototype system would be if
the prototype values generated were implementation specific!!

--

No, I am not seriously proposing such a laughable hack... I was just amused
by the idea.  It goes a long way towards a general pattern matching system
for type checking, if you're into that sort of thing (which I'm not, really).

Just couldn't resist.

My only point is that at some point you must decide how much is enough and
how much is too much for any proposal.  I just find it intriguing to
consider how any proposal might be generalized to express a wide variety of
additional mechanism.

I apologize if this bores or annoys anyone.  I don't mean to be cheeky.