Re: Revised straw proposal for heuristic info

[William D Clinger <will@ccs.neu.edu>]

Kent Dybvig asked, twice, after requesting changes for
the benefit of unnamed (and possibly hypothetical)
implementations:

> Can you give a reason why the change should not be made?

Yes.  I did, in fact.  Apparently I need to elaborate.

One of Kent's requested changes was that PROCEDURE-EXPRESSION
return the source code for a procedure "as a datum" instead
of "as a list".  Since Kent's requested change fails to
specify any interpretation for a non-list, and the proposal
already allows a non-list to be returned but does not specify
any interpretation for non-lists, Kent's requested change
would not change the meaning of the specification at all.

As a matter of editing, consistency dictates that we make
such a change of wording everywhere or nowhere.  I do not
see the point of tinkering with the English at this time.

Kent's other requested change concerns the possibility of
identifier macros that expand into lambda expressions, and
perhaps the possibility of opening a lambda expression with
a left bracket instead of a left parenthesis.  Now that Kent
has explained this change, I have no particular problem with
it.

I think there's a larger issue under the surface here, in
the form of a conflict between implementors and authors of
portable tools.

If XYZ Scheme is the only implementation that, for example,
prefers to represent the arity of a procedure using strings
such as "=12", ">=3", and "1 or 3 or (5 through 37)", then
specifying an interpretation for that representation is of
benefit only to users of XYZ Scheme.  Presumably XYZ Scheme's
native debugging tools already know how to interpret this
representation, so the specification is of benefit only to
users of that implementation who are using non-native tools.
Even then, the specification is of benefit only if the authors
of the non-native tools bothered to implement an interpretation
for this XYZ-specific representation.

The fact that the specification of PROCEDURE-ARITY does not
assign an interpretation to "=12" does not prevent
PROCEDURE-ARITY from returning "=12" in XYZ Scheme.
It seems to me that it would make more sense for XYZ Scheme
to use a different name, say PROCEDURE-ARITY-STRING, for its
procedure that returns "=12", and to make PROCEDURE-ARITY
return 12 instead, but it is not really my job to tell the
implementors of XYZ Scheme how they could retain their
XYZ-specific features while assisting people who are trying
to write portable tools that make use of heuristic information.

I realize that every implementor would like for all authors
of portable tools to add special cases to support their own
implementation-specific features.  Realistically, I don't
think that's likely to happen.  If our goal is to specify
a small set of abstraction-breaking operations to provide
heuristic support for portable tools, then I think we should
concentrate on specifying things that are portable across at
least two implementations.

That doesn't prevent an author of portable tools from adding
special cases to support some highly implementation-dependent
feature of XYZ Scheme.  Presumably authors will do that if
they think XYZ Scheme is important enough to justify it.

Conversely, specifying an interpretation for some XYZ-specific
representation doesn't mean that it will be supported by any
portable tools.  Presumably the authors of such tools will
just ignore the XYZ-specific parts of the specification if
they think XYZ Scheme isn't important enough to justify those
special cases.

In that sense it really isn't all that important whether we
specify XYZ-specific features.  It matters more for the
specification process than it will to users of the specification.

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?

Will