Abdulaziz Ghuloum wrote:
>> #|1|# (define VAR (MAC))
>> #|2|# (set! VAR (MAC))
>> #|3|# (list (MAC))
>> #|4|# (MAC)
>> #|5|# (define VAR (lambda () (MAC)))
>> #|6|# (set! VAR (lambda () (MAC)))
>> #|7|# (define-syntax MAC ...)
> So, your proposal makes #1 invalid (currently valid) and makes #6 valid
> (currently invalid).
Correct.
>> * There are also anomalies with expanding top-level forms. In
>> the above example, the expansion of MAC is deferred in #1, #2, #3,
>> but not #4. This could lead to subtle differences. In my proposal
>> all of these would be expanded eagerly, which removes surprises.
>
> I don't see the surprise since MAC can expand to other top-level
> definitions or other top-level macro definitions which are needed to
> continue the expansion of the remaining forms.
But that is an "implementation reason". *We* understand we it is so,
and *once explained* it makes sense. But it is still an inconsistency
and wart, which my proposal avoids.
> What's so special about expanding a lambda anyways? What about
> case-lambda,
> delay, forms that expand to some occurrence of lambda (e.g. let, cond,
> etc.),
> lambdas embedded in other expressions, e.g. (cons (lambda () (MAC)) 12),
> etc.? What does your proposal say about these?
I believe there are all derived forms, defined in terms of lambda.
(Or at least they can be, and were in R5RS.)
> Last I checked, the spec does not say anything about a repl, so you're free
> to do as you please in your repl implementation. I don't see why the
> report
> should try to provide better support for things not in the report to begin
> with.
Others have made this argument, and it seems wrong-headed to me: Most
Scheme implementations have a REPL, and I expect this will remain the
case, even after they implement R6RS. I.e. most implementations of
R6RS will have REPLs, and thus a specification of R6RS that
"plays better" with REPLs is more useful in the real world.
--
--Per Bothner
per_at_bothner.com http://per.bothner.com/
Received on Mon Mar 12 2007 - 03:54:59 UTC