[r6rs] probably bad syntax expansion

[r6rs] probably bad syntax expansion

[Marco Maggi]

The following R6RS program:

(import (rnrs))

(define (%general-string-append . args)
  (let-values (((port getter) (open-string-output-port)))
    (let loop ((args args))
      (if (null? args)
	  (getter)
	(let ((thing (car args)))
	  (display (if (identifier? (car args))
		       (identifier->string (car args))
		     (car args))
		   port)
	  (loop (cdr args)))))))

(define-syntax identifier->string
  (syntax-rules ()
    ((_ ?identifier)
     (symbol->string (syntax->datum ?identifier)))))

(define (identifier-prefix prefix identifier)
  (datum->syntax identifier (string->symbol (%general-string-append prefix identifier))))

(identifier-prefix "make-" #'salut)

fails with:

Backtrace:
In ice-9/boot-9.scm:
 170: 10 [catch #t #<catch-closure 8e80610> ...]
In unknown file:
   ?: 9 [catch-closure]
In ice-9/boot-9.scm:
  62: 8 [call-with-prompt prompt0 ...]
In ice-9/eval.scm:
 389: 7 [eval # #]
In ice-9/boot-9.scm:
1858: 6 [save-module-excursion #<procedure 8f22840 at ice-9/boot-9.scm:1871:3 ()>]
1148: 5 [load "proof.sps" #f]
In unknown file:
   ?: 4 [load-compiled/vm "/home/marco/.cache/guile/ccache/2.0-0.R-LE-4/home/marco/var/tmp/proof.sps.go"]
In proof.sps:
  23: 3 [identifier-prefix "make-" #(syntax-object salut ((top)) ...)]
  12: 2 [%general-string-append "make-" #(syntax-object salut ((top)) ...)]
In ice-9/boot-9.scm:
 115: 1 [#<procedure 8d742f8 at ice-9/boot-9.scm:109:6 (thrown-k . args)> wrong-type-arg ...]
In unknown file:
   ?: 0 [catch-closure wrong-type-arg "vm-debug-engine" ...]

ERROR: In procedure vm-debug-engine:
ERROR: Wrong type to apply: #<syntax-transformer identifier->string>

on       a        i686-pc-linux-gnu       using       commit
8d10ccae79ff46f0ebea92ba36acfaebafba8d86;  I  get  the  same
error when precompiling and when not precompiling.

  If  I try  to reduce  the programs  to simpler  forms (for
example  simplifying %GENERAL-STRING-APPEND) the  error goes
away.

  The program works fine with other R6RS implementations.
-- 
Marco Maggi

Re: [r6rs] probably bad syntax expansion

[Marco Maggi]

"Marco Maggi" wrote:
> The following R6RS program:

Sorry  for the self  reply; the  problem goes  away defining
IDENTIFIER->STRING before its usage.  I can understand this,
but it is not R6RS  behaviour.  Maybe just documenting it as
incompatibility is fine.
-- 
Marco Maggi

Re: [r6rs] probably bad syntax expansion

[Marco Maggi]

"Marco Maggi" wrote:
> Sorry for  the self reply; the problem  goes away defining
> IDENTIFIER->STRING  before its  usage.   I can  understand
> this,  but   it  is   not  R6RS  behaviour.    Maybe  just
> documenting it as incompatibility is fine.

I take  it back.  It  imposes an order on  definitions which
can cause problems in complex libraries (like mine).
-- 
Marco Maggi

Re: [r6rs] probably bad syntax expansion

[Andy Wingo]

Hello,

On Mon 21 Jun 2010 09:59, Marco Maggi <marco.maggi-ipsu@poste.it> 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".

It would seem that both for toplevel programs and for libraries --
because Guile expands the `library' form to toplevel definitions -- that
these REPL semantics do diverge from lexically-nested semantics.

It's the difference between:

    (let ()
      (define even?
        (lambda (x)
          (or (= x 0) (odd? (- x 1)))))
      (define-syntax odd?
        (syntax-rules ()
          ((odd? x) (not (even? x)))))
      (even? 10))
     => #t

and

    (begin
     (define even?
       (lambda (x)
         (or (= x 0) (odd? (- x 1)))))
     (define-syntax odd?
       (syntax-rules ()
         ((odd? x) (not (even? x)))))
     (even? 10))
    ERROR: In procedure vm-debug-engine:
    ERROR: Wrong type to apply: #<syntax-transformer odd?>

It is unfortunate for users that expect R6RS semantics for toplevel and
library definitions. I would be happy to accept a well-reasoned patch to
letrec-compile the first forms from a file that prove to be definitions,
though we cannot remove support for mixed definitions and expressions at
the toplevel. However, I don't have the motivation to work on this in
the foreseeable future.

Thank you for the report, though, and I will document the
incompatibility.

Andy
-- 
http://wingolog.org/

Re: [r6rs] probably bad syntax expansion

[Andy Wingo]

Hello,

On Mon 21 Jun 2010 21:24, Andy Wingo <wingo@pobox.com> writes:

> On Mon 21 Jun 2010 09:59, Marco Maggi <marco.maggi-ipsu@poste.it> 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/