Re: [r6rs] probably bad syntax expansion

[Andy Wingo]

Hello,

On Mon 21 Jun 2010 21:24, Andy Wingo <address@hidden> writes:

> On Mon 21 Jun 2010 09:59, Marco Maggi <address@hidden> writes:
>
>> (define A <function-using-macro-B>)
>> (define-syntax B <>)
>> (A)
>
> I have abbreviated your illuminating example. I don't really know what
> to think of it, except to say that for top-level programs Guile
> implements "REPL semantics".

This is not quite the right explanation of the situation. Here is what I
have put in the section "R6RS incompatibilities" in the manual.

  Instead of using the algorithm detailed in chapter 10 of the R6RS,
  expansion of toplevel forms happens sequentially.

  For example, while the expansion of the following set of recursive
  nested definitions does do the correct thing:

  @example
  (let ()
    (define even?
      (lambda (x)
        (or (= x 0) (odd? (- x 1)))))
    (define-syntax odd?
      (syntax-rules ()
        ((odd? x) (not (even? x)))))
    (even? 10))
  @result{} #t
  @end example

  @noindent
  The same definitions at the toplevel do not:

  @example
  (begin
   (define even?
     (lambda (x)
       (or (= x 0) (odd? (- x 1)))))
   (define-syntax odd?
     (syntax-rules ()
       ((odd? x) (not (even? x)))))
   (even? 10))
  <unnamed port>:4:18: In procedure even?:
  <unnamed port>:4:18: Wrong type to apply: #<syntax-transformer odd?>
  @end example

  This is because when expanding the right-hand-side of @code{even?}, the
  reference to @code{odd?} is not yet marked as a syntax transformer, so
  it is assumed to be a function.

  While it is likely that we can fix the case of toplevel forms nested in
  a @code{begin} or a @code{library} form, a fix for toplevel programs
  seems trickier to implement in a backward-compatible way. Suggestions
  and/or patches would be appreciated.

Admittedly, it seems silly to document incompatibilities instead of
fixing them :P

Andy
-- 
http://wingolog.org/