[r6rs-discuss] [Formal] defer lambda rather than define rhs when expanding body

From: Abdulaziz Ghuloum <aghuloum>
Date: Mon Mar 12 03:30:45 2007

On Mar 11, 2007, at 5:30 PM, Per Bothner wrote:

> ---
> This message is a formal comment which was submitted to formal-
> comment_at_r6rs.org, 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,,,
Received on Mon Mar 12 2007 - 03:30:06 UTC