[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: R5RS draft: <body> in LET{REC}-SYNTAX ???


   From: "Sergei Egorov" <esl@informaxinc.com>
   Date: Fri, 13 Feb 1998 00:56:36 -0500

   I probably should not be posting to this list,

Why ever not?

   but since R5RS is about to be officialy approved,
   I thought that there might not be another chance
   to fix what I believe to be a misfeature in both R4RS
   Appendix:Macros and R5RS draft, section 4.3 (Macros).

   The LET-SYNTAX and LETREC-SYNTAX forms are specified
    as having <body> (a sequence of one or more expressions)
   as a binding region. The "semantics" part (p.14) says that
   the <body> is _expanded_ in the corresponding syntactic
   environment, but since the <body> consisting of more than
   one expression does not qualify as <macro use> or
   <expression>, the result of its expansion is not entirely
   clear.

I agree with you up to this point.

   Assuming that <body> expressions are
   expanded one-by-one in the same environment,
   we get another _sequence_ of (expanded) expressions.
   This sequence is also not an <expression>,
   despite the fact that original LET{REC}-SYNTAX
   is declared as <macro block> and thus an <expression>.
   This also means that macro expansion may break
   expression structure of a program and assign
   meaning to some strange forms:

   (define-syntax obscure
      (syntax-rules
	 ((obscure)
	  (let-syntax () (f) (g)))))

   (if (h) (obscure))  expands to (if (h) (f) (g)) ???
   (cons (obscure)) expands to (cons (f) (g)) ???

This interpretation mystifies me.  In the other <body>s
(LAMBDA, LET, LETREC, LET*) the expressions are evaluated
in order and the value(s) of the last one is returned.
There is nothing in the report that supports a <body>
semantics of `the list of expressions are spliced into
the containing expression, if any, which is then reparsed'.

But there is some confusion.  We (or at least I) would
like to allow LET{REC}-SYNTAX forms that are at top level
to expand into a sequence of definitions that are spliced
into the program.  This would be disallowed if the usual
`expressions are evaluated in order and the value(s) of
the last one is returned' language were used.  Splicing a
list of commands into a program has a perfectly reasonable
semantics, and is already done with BEGIN.

One solution would be to say that if a LET{REC}-SYNTAX
is used at top level the commands in the <body> are spliced
into the program, and if it is used elsewhere the expressions
in the <body> are evaluated in order, etc..  This would rule
out using a LET{REC}-SYNTAX to created a sequence of internal
defines, which I don't think would be acceptable to everyone.

I don't know of a simple fix for this, and it's an old problem,
so it will have to wait for an RnRS with n>5.

   P.S. R5RS also mentions (section 5.2.2.) that LET-SYNTAX
   and LETREC-SYNTAX can contain _internal_ definitions (???).
   This phrase is in disagreement with the description of
   LET-SYNTAX in "binding constructs for syntactic keywords",
   p. 14: "<body> should be a sequence of one or more expressions".

No more than it is in disagreement with similar statements
about the bodies of LAMBDA, LET, LETREC, and LET*.  Internal
definitions can be viewed as an alternative syntax for LETREC,
so there isn't any real problem.

   P.P.S. I just noticed that in yesterday's version of authors.ps.gz
   subsections of section 4.3. (Macros) are not numbered.

You've got me there.  I'll put the numbers in.

                               -Richard Kelsey