[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ramsdell: truth of (), etc...]
John Ramsdell wrote:
Is there any support for the idea of giving internal definitions the
same semantics as top level definitions? I have yet to hear a strong
argument as to why they should mean something different. Maybe R4RS
should explain the decision it describes.
<BODY> --> (define <I> <EXP>) ... <SEQUENCE> ==>
((lambda (<I> ...)
(set! <I> <EXP>)
(In other words, the proposal is to require that internal definitions be
evaluated from left to right, with each succeeding definition allowed to
use variables defined before it.)
Although I prefer the existing semantics, I would not be strongly opposed
to changing it to require that definitions be evaluated in order. I suspect
that most implementations currently do this anyway for compatibility with
the Abelson&Sussmans book (where a bug makes one of the larger programs
depend on left to right evaluation).
For what it's worth, here are the two reasons that I prefer the existing
1. I find that it is easier to understand code when I can assume that
the order of definitions doesn't matter. That way I can read the
definitions in any order. This is a special case of the general
principle that a more declarative semantics makes programs easier
2. (This reason is pretty weak.) For the compiler writer, I think the
freedom to rearrange definitions makes closure analysis a little
simpler when procedure definitions are mixed with definitions of
variables containing non-procedure values.
Note that I am very strongly proposed to another proposal that was
advanced some time ago, which would require a rather complicated and
unintuitive order of evaluation that could only be specified in terms
of a static dependency analysis.