Suspected lexical context bug

[GoogleCodeExporter]

In revision 87 (and still present in the newest revision) of the SRFIs
collection [1] I manage, in the file srfi/%3a43/vectors.sls, I used
let-syntax in a way so that the original vector-lib.scm reference
implementation file does not have to be modified at all (which helps
maintenance when diff'ing).  This exposed a bug in Ypsilon, which I suspect
involves lexical context issues possibly related to bugs #106 and #107.  I
tried to narrow down the bug, but could not.  See below for the original
bug exposed by srfi/%3a43/vectors.sls.

[1] https://code.launchpad.net/~scheme-libraries-team/scheme-libraries/srfi

$ ypsilon --r6rs srfi/tests/vectors.sps 

error in define: attempt to modify immutable binding
  >  (define make-vector make-vector)
  ..."/home/d/zone/scheme/srfi/%3a43/vectors.sls"

expanding:
  >  (syntax ((AV (quote make-vector)) x ...))
  ..."/home/d/zone/scheme/srfi/%3a43/vectors.sls"
  *  ...
  *  (define-syntax receive
       (syntax-rules ()
         ((receive ?formals ?producer ?body1 ?body2 ...)
          (call-with-values
            (lambda () ?producer)
            (lambda ?formals ?body1 ?body2 ...)))))
  ..."/home/d/zone/scheme/srfi/%3a43/vectors.sls" line 71
  *  (include/resolve ("srfi" "%3a43") "vector-lib.scm")
  ..."/home/d/zone/scheme/srfi/%3a43/vectors.sls" line 71
  *  (SRFI-23-error->R6RS
       "(library (srfi :43 vectors))"
       (include/resolve ("srfi" "%3a43") "vector-lib.scm"))
  ..."/home/d/zone/scheme/srfi/%3a43/vectors.sls" line 70
  *  (with-syntax ((|.L0| (rename (syntax name)))) (syntax (define |.L0| . r)))
  ..."/home/d/zone/scheme/srfi/%3a43/vectors.sls" line 62
  *  (quasisyntax (define (unsyntax (rename (syntax name))) . r))
  ..."/home/d/zone/scheme/srfi/%3a43/vectors.sls" line 62

$ 

Original issue reported on code.google.com by derick.e...@gmail.com on 15 Sep 2009 at 9:23

[GoogleCodeExporter]

Interestingly, Mosh also has issues with the SRFI collection (see
<http://code.google.com/p/mosh-scheme/issues/detail?id=134>), but does
/not/ expose the hygiene issues indicated by Bug 106 and Bug 107.

Original comment by rott...@gmail.com on 11 Apr 2010 at 12:48

[weinholt]

Today the SRFI collection mentioned in this issue is maintained here: https://github.com/arcfide/chez-srfi/. The bug in Ypsilon is still a problem and affects SRFI-43 and SRFI-78 from chez-srfi.

The syntax-violation comes from here: https://github.com/fujita-y/ypsilon/blob/master/heap/boot/macro/library.scm#L469

But if I comment out that code then there is a new error: error in library: attempt to export unbound identifier my:vector-fill!.

My guess is that let-syntax is doing something wrong. It should be permissible to redefine define inside let-syntax and in chez-srfi/%3a43/vectors.sls there is a definition of my:vector-fill! happening inside a let-syntax.

The syntax-violation on library.scm:469 should not be getting triggered because that check is done for define and this is inside let-syntax. And conversely it seems that perhaps the definition of my:vector-fill! is not getting flattened into the library top level? I'm just guessing, I'm not familiar with how your expander is implemented.

It would be nice to get this fixed so that chez-srfi will be working with Ypsilon.

[fujita-y]

I suspect datum->syntax has some issue and continue investigating, since simple redefinition of top-level identifier, and splicing definitions into top-level seems working. Thank you!

$ ypsilon -6
ypsilon-2.0.8 (r6rs)
> (library (foo)
  (export)
  (import (rnrs))
  (let-syntax
    ((define
       (lambda (stx)
         (syntax-case stx ()
           ((_ arg )
            #'(display arg))))))
    (define "foo text")))
foo text
> (library (bar)
  (export hoge1 hoge2)
  (import (rnrs))
  (let-syntax ()
    (define hoge1 "hoge1 text")
    (define hoge2 "hoge2 text")))
> (import (bar))
> hoge1
"hoge1 text"
>