Perhaps it is a strategic error not to make REPL semantics primary, as
this example shows. The problem Per is pointing out (it seems to me)
is an unintended consequence of what was intended by the authors as
a simple rule, covering a corner case. What's needed is to align the
intentions of the standard with the reasonable intentions of a "typical
programmer". A simple REPL-oriented semantics of the top-level
is easy for [insert unsubstantiated "many" or "most" here] programmers
to think about -- and thus reflects /their/ intentions. The choice, from
an abstract perspective, seems otherwise arbitrary (for the
editors/authors),
especially given the existence of forms like letrec.
Besides, given REPL semantics, it would seem easier for RnRS to nail
down a mostly-compilable subset while, at the same time, allowing all
kinds of gnarly dynamic extensions as in, y'know, the lisp tradition and
whatnot.
Maybe the path from the current draft to a good R6 mainly involves
deleting/weakening various statements.
SCM still stands, in this odd way of looking at things, as a very important
model implementation.
The really great compilers are, well, really great -- but perhaps there
is no reason not to declare that "these compile a subset" (and then remark
on exactly what subset).
There are probably other ways to reach the strong hunch that REPL
semantics are desirable if you drag in contemplation of reflective
towers and whatnot. I'm not sure there's any really rigorous way to
say it -- things just "harmonize" better.
-t
Per Bothner wrote:
> AndrevanTonder wrote:
>> On Thu, 22 Feb 2007, Per Bothner wrote:
>>
>>> (define VAR (MAC))
>>> (set! VAR (MAC))
>>> (list (MAC))
>>> (MAC)
>>> (define-syntax MAC ...)
>>>
>>> The first 3 (MAC) applications are deferred, so are correctly
>>> done using the following the define-syntax.
>>>
>>> The 4th (MAC) is not deferred, and so "the wrong thing will
>>> happen".
>>
>> Not in a correct implementation. A correct implementation should
>> throw a syntax error. See section 8:
>>
>> "A definition in the sequence of forms must not define any
>> identifier whose
>> binding is used to determine the meaning of the undeferred
>> portions of the
>> definition or any definition that precedes it in the sequence of
>> forms."
>
> I'm missing something here. Is this an argument against my point?
> My reading of the statement you quoted is that the first 3 forms are
> valid, and the 4th should be a syntax error. I think that counts
> as the "wrong thing happening".
>
> You agree that:
> (car (list (MAC))
> is valid while:
> (MAC)
> is a syntax violation? And a user might find this surprising?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.r6rs.org/pipermail/r6rs-discuss/attachments/20070222/33f6a659/attachment.htm
Received on Thu Feb 22 2007 - 18:47:04 UTC