[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


    Date: Sun, 15 Dec 85 06:10:14 EST
    From: Alan Bawden <ALAN at MIT-MC.ARPA>


    Also a minor point about your quasi-quote proposal:  You notate the three
    magic objects that are used for recognition as #!QUASIQUOTE, #!UNQUOTE and
    #!UNQUOTE-SPLICE.  I claim that in a language specification it would be
    better to specify the names of three variables whose -values- are the three
    magic markers.  This is because it is dangerous for those objects to appear
    directly as constants in source code.  (In one message you point out this
    danger yourself, I seem to remember.)

    Instead of


    it is better to write


    And instead of


    (which doesn't work as intended) it is -certainly- better to write


    In fact, I cannot imagine any situation in which I would want to type one
    of the three magic markers directly.  Conceivably a language specification
    should specify how the quasi-quote marker -looks-, so that you can
    recognize it if you happen to see it, but the user should not be encouraged
    to risk typing it in himself.  (Were I in charge I might consider
    specifying the names of the three variables, what the objects look like
    when PRINTed, and that is is an error if that printed representation is
    ever seen by READ.)

I definitely agree with most of this (I have run into exactly this bug,
and I suspect other people have too).  I only disagree with the
parenthetical remark at the end.  I think it's important that the
markers, or at least forms so marked, be rereadable.  One of the things
I was worried about was the problem of being able to print a program out
from one implementation and read it back in in another.  One solution
would be for PRINT to generate ` - , - ,@ syntax properly, and have
isolated occurences of the markers print nonrereadably.  Another
solution would be to require user code to always expand the backquote
form in some way before printing it, but that's unacceptable since your
target implementation might have some spiffy implementation of
backquote, and you'd like to be able to take advantage of it without
knowing what it is (or writing your own version of PRINT).

I tend to agree with Kent Dybvig's suggestion that the asymmetry with
QUOTE should be eliminated somehow.  I suggested a long time ago,
certainly on one of the T mailing lists and probably to the RRRS
authors, that 'FOO should read DIFFERENTLY from the list (QUOTE FOO),
either as a list with a funny marker in its CAR or as an object of a
different datatype, but no one seemed to like that suggestion.  Since
it's too late to change that, I think the markers should be symbols with
long names (no name is ever obscure enough, I know, but what can you
do?), since it's a pain both in some implementations and in the manual
to introduce new datatypes.  We would then have to agree on what the
name is, so that users can be sure to avoid using it.  Probably having
variables whose values are these symbols, or maybe even inventing little
S&ICP-style data abstractions (constructor, accessor, and predication
functions), is desirable too.  But that would be redundant, not
bare-bones the way the rest of scheme is...