On Mar 11, 2007, at 5:30 PM, Per Bothner wrote:
---
This message is a formal comment which was submitted to formal-
[EMAIL PROTECTED], following the requirements described at: http://
www.r6rs.org/process.html
---
Type: Simplification and enhancement
Priority: Minor
Component: Concepts (?)
Version: 5.92
When expanding a body the current specification defers expanding
the rhs of a define. I suggest it would be more consistent and
natural to defer expanding lambda-expressions instead.
* It improves consistency. Consider:
#|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 ...)
Which of #1-#6 are valid when followed by #7?
By my reading only #1 and #5 are allowed. But that doesn't seem
natural
to me. If #5 is allowed, then #6 should be allowed.
Similarly for #1 and #2.
Let me try again. In the current 5.92 draft, if the above question was
about /libraries/, then the answer is that only #1 and #5 are allowed
to come before #7. #2, #3, and #6 are not allowed because these are
expressions and expressions cannot come before definitions. #4 is not
allowed for a different reason. So, according to the current draft,
the reason why only #1 and #5 are allowed before #7 is because they're
definitions and the rest are not. This is so regardless of the
occurrences of MAC.
If the above question was about /top level programs/, then every form
except #4 is allowed to occur before #7. For top-level programs, when
the expander encounters an expression (or a non-definition), it defers
its expansion until all definitions are found.
In my proposal, #1-#4 are invalid while #5-#6 are valid.
So, your proposal makes #1 invalid (currently valid) and makes #6 valid
(currently invalid).
* 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.
* An informal reason is that this makes the expansion
process more similar to evaluation: Evaluating define means
evaluating its rhs, while evaluating a lambda expression
does not evaluate its body.
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?
* The above reason leads to better support for read-eval-print
loops and other interactive modes where expansion is interleaved
with evaluation: If I type a define in repl, an implementation
can defer expanding a lambda (until it is called), but it can't
defer expanding the rhs of a define in general.
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.
Aziz,,,
_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
