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

macros expanding into definitions


About that DEFINE-MULTIPLE query I sent around before...  sorry it
stirred up such a fuss.  It looks like the answer is that there isn't
consensus to make internal defines like top-level ones; not even the
proposal I sent out does that, since it prohibits
    (define cons (let ((save cons)) (lambda ... save ...)))
which is now valid at top level (I think).  In fact, this wouldn't be
a valid internal define under any of the proposals I've seen.  I
noticed this after I sent out that long proposal, and it makes me
doubt its deirability -- better for two different but similar-looking
things to be very different than for them to be almost the same but
not quite.

So, the answer to my two questions seem to be:

   1. I can write (begin (define foo 3) (set! foo 4)) at top level,
      and use at top level macros that expand into things like this.
      That is, we'll change the report to make BEGIN a splicing form
      at top level:
		<program> ::= <form>*
		<form> ::= <definition> | <expression> | (begin <form>*)
		         | <syntax definition>
      but we won't change the syntax of internal definitions.

   2. I should only use macros that expand into forms that mix
      expressions and definitions at top level, not internally.

However, it looks like there still *might* be a possibility of making
a change to the semantics internal defines, by way of requiring that
the initializations occur in order.  Suppose there were a LETREC*
form, with the same syntax and scope rules as LETREC, but with the
order of initialization specified to be left to right (or top to
bottom).  So

	(letrec* ((name exp) ...) body ...)

would be equivalent to (using SYNTAX-RULES-like notation)

	(let ((name <undefined>) ...)
	  (set! name exp)
	  ...
	  (let ()
	    body ...))

where <undefined> is as described in section 7.3, and the SET!'s are
magical in the same sense as the ones in the LETREC expansion
(dynamically prior SET!'s are invalid but the ones that initialize
are).  Then a <body> with internal definitions would be equivalent to
the corresponding LETREC* form instead of the corresponding LETREC
form.  I'm not suggesting adding LETREC* to the language, only
introducing it to aid the description of <body> semantics easier.

Any takers on this one?  Or rather, I suppose for this group the
question is, any objections to this one?