Re: [Chicken-users] hygienic named let
Hi! I think the reason for the (r 'apply) not working is that the initial macro definitions (in expand.scm) are created in an empty syntactic environment where (for example) `apply' is not visible yet. There is a fair amount of patching of SE's involved during this phase and during imports. Exactly this (the special treatment of primitive value bindings in the initial syntactic environments) is a tricky issue and probably not particularly well implemented. In any case it has caused many of the bugs you and others reported. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] hygienic named let
On Mon, Sep 1, 2008 at 7:02 PM, Jim Ursetto [EMAIL PROTECTED] wrote: But it is imported. foo imports scheme and uses named let, baz imports foo, therefore the expanded call to bar should see letrec via foo's import environment. As I said, the `letrec' introduced by named let is special. As I said, I modified the expander to stop handling named let (and let in general) specially, and made LET a macro in the default-macro-environment (which works fine). I appended that code to my original message. LETREC is also contained in that environment. So why doesn't it work there? Because `let' is handled specially. That's just how it is implemented. It doesn't work in my er-transformer version of let I posted. I don't understand why let needs to be handled specially, can you explain? Like I said, I stripped out the special let handling code in ##sys#expand-0 and made let a regular er-transformer macro, and it works perfectly fine -- I can even recompile Chicken with it. The problem is that renames don't seem to work properly inside it. If you use ##core#app and ##core#letrec renames don't come into play, so why is the special handling required in the first place? I assume the reason here is that the core macros don't carry a complete static syntax-environment, as compared to user-defined ones. It would probably work if you generalize all special forms to syntax, but the initial macro-environment is not equivalent to the macro- environment of a normal module. Additionally, non-module toplevel code still has to work so there are subtle differences in the ways syntax and core forms interact. I invite you to build with DEBUGBUILD=1 and run csi/chicken with -:d, which will give you reams of debug-output to ponder about. Unfortunately I don't have the time right now to figure out why a modified version of the base expander does something weird, when the current one seems to work. I also don't know how exactly you modified the expander, so perhaps you should send me a patch? cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] hygienic named let
On Sun, Aug 31, 2008 at 7:28 AM, Jim Ursetto [EMAIL PROTECTED] wrote: There's a bit of a corner case I found with hygienic named let. #;3 (module foo (bar) (import scheme) (define-syntax bar (syntax-rules () ((_) (let loop ((x 3)) x) #;4 (module baz () (import foo) (bar)) Warning: reference to possibly unbound identifier: loop Warning: reference to possibly unbound identifier: letrec It seems that (in ##sys#expand-0, where LET is handled specially) LETREC is not seen as a macro, and is renamed like a regular identifier. Yet this works perfectly for regular LET, direct LETREC, and even the chained example below: Indeed, letrec is not detected to be a macro. The named let expansion is somewhat special in that it is the only core syntax that expands into the use of a macro. If that macro is not in the current import environment, it is treated just like a normal value-binding (and thus renamed). #;10 (module foo (bar) (import scheme) (define-syntax bar (syntax-rules () ((_) (let ((x 3)) x) #;12 (module baz (quux) (import foo) (define-syntax quux (syntax-rules () ((_) (bar) #;13 (module xyzzy () (import baz) (quux)) 3 xyzzy does not import scheme, it doesn't know about letrec. My guess was that since LET wasn't a real macro, it had no environment in which to look up the LETREC. I couldn't concoct one in ##sys#expand-0, so I commented out the special LET handling code there and just rewrote it as a regular macro, below. Afterward, regular let continued to work fine, as did named let in normal circumstances. Right - scheme is not imported, so there's no way to detect whether letrec is a macro or not. Unfortunately, named let -still- didn't work in this corner case, even though the LETREC is renamed. Also, if you rename anything else, it fails too --- for example, change ##core#app to ,(r 'apply), and you will get an unbound identifier APPLY. So, I am stumped for now. Any ideas? Named let is handled specially by the expander - redefinitions of let will not help here (unless they exist in a surrounding local binding environment). I have made letrec a core form, which makes the named-let expansion independent of any macros. The current HEAD in hygienic should work better, now. I'm not sure about the 'apply thing as it works for me, if used in a normal module-level macro. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] hygienic named let
On Mon, Sep 1, 2008 at 2:34 AM, felix winkelmann [EMAIL PROTECTED] wrote: On Sun, Aug 31, 2008 at 7:28 AM, Jim Ursetto [EMAIL PROTECTED] wrote: #;3 (module foo (bar) (import scheme) (define-syntax bar (syntax-rules () ((_) (let loop ((x 3)) x) #;4 (module baz () (import foo) (bar)) Warning: reference to possibly unbound identifier: loop Warning: reference to possibly unbound identifier: letrec Indeed, letrec is not detected to be a macro. The named let expansion is somewhat special in that it is the only core syntax that expands into the use of a macro. If that macro is not in the current import environment, it is treated just like a normal value-binding (and thus renamed). But it is imported. foo imports scheme and uses named let, baz imports foo, therefore the expanded call to bar should see letrec via foo's import environment. Right - scheme is not imported, so there's no way to detect whether letrec is a macro or not. See above. Named let is handled specially by the expander - redefinitions of let will not help here (unless they exist in a surrounding local binding environment). As I said, I modified the expander to stop handling named let (and let in general) specially, and made LET a macro in the default-macro-environment (which works fine). I appended that code to my original message. LETREC is also contained in that environment. So why doesn't it work there? change ##core#app to ,(r 'apply), and you will get an unbound identifier APPLY. I'm not sure about the 'apply thing as it works for me, if used in a normal module-level macro. It doesn't work in my er-transformer version of let I posted. I don't understand why let needs to be handled specially, can you explain? Like I said, I stripped out the special let handling code in ##sys#expand-0 and made let a regular er-transformer macro, and it works perfectly fine -- I can even recompile Chicken with it. The problem is that renames don't seem to work properly inside it. If you use ##core#app and ##core#letrec renames don't come into play, so why is the special handling required in the first place? ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] hygienic named let
There's a bit of a corner case I found with hygienic named let. #;3 (module foo (bar) (import scheme) (define-syntax bar (syntax-rules () ((_) (let loop ((x 3)) x) #;4 (module baz () (import foo) (bar)) Warning: reference to possibly unbound identifier: loop Warning: reference to possibly unbound identifier: letrec It seems that (in ##sys#expand-0, where LET is handled specially) LETREC is not seen as a macro, and is renamed like a regular identifier. Yet this works perfectly for regular LET, direct LETREC, and even the chained example below: #;10 (module foo (bar) (import scheme) (define-syntax bar (syntax-rules () ((_) (let ((x 3)) x) #;12 (module baz (quux) (import foo) (define-syntax quux (syntax-rules () ((_) (bar) #;13 (module xyzzy () (import baz) (quux)) 3 My guess was that since LET wasn't a real macro, it had no environment in which to look up the LETREC. I couldn't concoct one in ##sys#expand-0, so I commented out the special LET handling code there and just rewrote it as a regular macro, below. Afterward, regular let continued to work fine, as did named let in normal circumstances. Unfortunately, named let -still- didn't work in this corner case, even though the LETREC is renamed. Also, if you rename anything else, it fails too --- for example, change ##core#app to ,(r 'apply), and you will get an unbound identifier APPLY. So, I am stumped for now. Any ideas? (##sys#extend-macro-environment 'let '() (##sys#er-transformer (lambda (form r c) (##sys#check-syntax 'let form '(_ . #(_ 2))) (let* ([body (cdr form)] [bindings (car body)]) (cond [(symbol? bindings) (##sys#check-syntax 'let body '(_ #((variable _) 0) . #(_ 1))) (let ([bs (cadr body)]) `(##core#app (,(r 'letrec) ([,bindings (##core#loop-lambda ,(map (lambda (b) (car b)) bs) ,@(cddr body))]) ,bindings) ,@(##sys#map cadr bs)))] [else `(##core#let ,@body)]) ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
