Re: Revised straw proposal for heuristic info

[dak@sq.com]

[I've cut a lot to get down to this critical point.]

| During the specification process we have to draw the line
| somewhere, or we'll end up specifying representations that are
| so ridiculous that they are used in only one representation,
| while failing to specify representations that are so attractive
| that several implementations assign conflicting interpretations
| to them.  I don't want this proposal to get bogged down in
| disputes over such conflicts, and I don't want the proposal to
| get bogged down in disputes over whether XYZ-specific
| representations should be specified.  If we specify one
| XYZ-specific feature, fairness will dictate that we specify
| ABC-specific and FOO-specific features also, and we'll end up
| with a 100-page specification for something that deserves no
| more than a couple of pages.
| 
| Let's stick to specifying only the simplest and most portable
| representations we can imagine, ok?

Perhaps Aubrey Jaffer's (procedure-formals ...) cuts the Gordian
knot?  It has the advantage of mapping onto what can be represented
in the formals of an R4RS lambda, without delving into the body of 
the procedure, and can be derived directly from the Scheme source
of a given procedure, if implemented in Scheme; otherwise, it can
be synthesized, with or without type information.  

There is some charm in having arity rather than formals, but 
it seems like something where it is hard to draw the line; perhaps
we can simply give up on this point.

(That said, we have arity in SQPSI, and the original PSI, and we
waffled between several different representations of variable-arity
primitive procedures.)

Does anyone else have a preference for names that are something like
procedure->formals instead of procedure-formals ?  We've found this
usage (-> for extraction or selection or conversion, much like an
infix 2 in some other languages) usefully mnemonic in practice.

Best,
Dak