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

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

Dear Scheme authors:

I probably should not be posting to this list,
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. 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)) ???

As a result, we get a new class of "splicing" macros with
unclear (or at least unexpected) semantics. I also had a chance
to discover by myself that this little feature significantly increases the
complexity of a macroexpander code. This is not a problem per se;
clever implementations can support it as well as other nontrivial
things like internal syntax definitions, but I believe that splicing macros
are not yet ready for inclusion into the main body of the upcoming
R5RS report. Allowing only single <expression> inside LET-SYNTAX
and LETREC-SYNTAX does not take out too much functionality
(most applications of this feature seems to be covered by wrapping
body expressions in (BEGIN ...), especially because BEGIN
is "splicing" at top level (5.1, p.16)), but it makes macroexpansion
mechanism easier to understand and implement and does not
affect compatibility of existing (even "splicing") implementations.

Sincerely,
Sergei Egorov

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".

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


-----Original Message-----
From: Richard Kelsey <kelsey@research.nj.nec.com>
To: rrrs-authors@martigny.ai.mit.edu <rrrs-authors@martigny.ai.mit.edu>
Date: Thursday, February 12, 1998 2:30 PM
Subject: R5RS


>
>I believe that it is time for us to stop tweaking R5RS and
>start thinking about R6RS.
>
>R5RS is available as
>
>   ftp://ftp.nj.nec.com/pub/kelsey/authors.ps.gz
>
>In the absence of any major objection I will make a general
>announcement and make the sources available.  The deadline
>for objections is next Thursday, February 19th.
>
>The report does include the section on proper tail recursion.
>To ensure that the requirement actually means something, there
>is a pointer to Will Clinger's upcoming PLDI paper, which has
>a formal definition of proper tail recursion.
>
>I changed the dedication to be to Robert Hieb, in appreciation
>of his work on hygienic macros.
>                                     -Richard Kelsey
>