[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>)
         ...
         <SEQUENCE>)
       <UNDEFINED> ...)

(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
semantics:

  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
      to understand.
  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.

Peace, Will