On Tue, Oct 6, 2015 at 7:50 PM, Paolo Giarrusso <p.giarru...@gmail.com> wrote: > Thanks for the prompt answer and the clarifications! But there's a > third issue, which unfortunately I've hid when I combined the modules > in one file (sorry), and which is more important. Sorry I made this > unclear. > > In the split version > (https://github.com/Blaisorblade/racket-playground/tree/master/bug-with-signatures-and-macros, > client.rkt and its 2 dependencies), for a bug in the first module I > get the error only in the third module (as detailed in the first > email). That's why I talked about separate compilation: maybe I'm > still confused, but I'd expect the error to be on the first module. If > this weren't separate compilation, I believe I'd still argue it's an > important guarantee.
This is a general issue with macros. Racket can't tell that `thunk` will be unbound once its expanded the macro until it actually happens. So no error can be reported until then. You can see the same issue with these two modules: (module m1 racket (provide m) (define-syntax-rule (m) (add1 unbound-id))) (module m2 racket (require 'm1) (m)) The error only happens when expanding m2. > > In addition, I get an error it without any line number — which is > maybe a more subtle matter. Also DrRacket shows no line number. > > $ raco make client.rkt > thunk: unbound identifier in module > in: thunk > compilation context...: > > /Users/pgiarrusso/AeroFS/Repos/racket-playground-bluevelvet/bug-with-signatures-and-macros/client.rkt > context...: > [ the same ] That sounds like somewhere the source location is getting lost in the unit macro, which is probably a bug. Sam > Cheers, > Paolo > > On 7 October 2015 at 01:28, Sam Tobin-Hochstadt <sa...@cs.indiana.edu> wrote: >> I think there are two issues here: >> >> 1. The stack trace in your email is just a result of `raco make` >> printing its current context when there's a syntax error. If you >> replace the whole body of the module with just `(lambda)`, you'll see >> the same stack trace. Probably `raco make` should be changed not to >> print that part of the stack. > > I'm in favor. (Also because I'm used to the Scala compiler, where > stacktraces are bugs and bugs are plentiful). > >> 2. `(require (for-syntax racket/function))` would be needed if you >> used `thunk` to compute the new syntax that your macro expanded into >> -- in other words, if `thunk` gets executed during expansion. However, >> your macro expands into a use of `thunk`, just like it expands into a >> use of `reify-thunk`. > > Sorry, on this point I was plainly confused. > >> If we rewrite your macro not using >> `syntax-rules, the distinction is perhaps clearer: >> >> (define-syntax reify (lambda (stx) (syntax-case stx () [(_ e) >> (syntax (reify-thunk (thunk e)))]))) >> >> The things used in the computation of the new syntax are, here, >> `lambda`, `syntax-case`, and `syntax`. `reify-thunk` and `thunk` >> appear inside `syntax` -- they are part of the program that we expand >> into, and thus need to be available at phase 0. >> >> Hopefully that helps explain what's going on here. >> >> Sam >> >> >> >> On Tue, Oct 6, 2015 at 7:18 PM, Paolo Giarrusso <p.giarru...@gmail.com> >> wrote: >>> I feel I've found (and minimized) a perfectly repeatable bug in separate >>> compilation in Racket 6.2.1, or at least a situation which is a pain to >>> debug for related reasons. The example code is available at >>> http://pasterack.org/pastes/25050 (or at the end of this email) with all >>> modules in one file, but I've first obtained it with modules in separate >>> files. >>> >>> In module base-sig, I can use an identifier (here `thunk`) which is *not* >>> in scope in a "macro" (?) inside define-signature. In module base (which >>> requires module base-sig) I provide a unit implementing the signature. >>> Then, if in module client I require module base, load the unit *and use the >>> macro*, I get a compiler stacktrace mentioning `thunk`, even though `thunk` >>> isn't mentioned (except after macro expansion). No error before. >>> To fix this, I must trace this to module 1 by trial and error — requires >>> elsewhere won't help (because lexical scope is still respected). >>> >>> The needed fix is not (require (for-syntax) but a plain (require). That >>> seems to be as specified, but it seems unintuitive wrt. the phase >>> distinction — I can imagine this makes sense for units, but it should IMHO >>> be better explained. More importantly, undeclared identifiers should be >>> flagged early. >>> >>>> Each define-syntaxes form in a signature declaration introduces a macro >>>> that is available for use in any unit that imports the signature. Free >>>> variables in the definition’s expr refer to other identifiers in the >>>> signature first, or the context of the define-signature form if the >>>> signature does not include the identifier. >>> >>> $ raco make all.rkt >>> all.rkt:11:24: thunk: unbound identifier in module >>> in: thunk >>> compilation context...: >>> >>> /Users/pgiarrusso/AeroFS/Repos/racket-playground-bluevelvet/bug-with-signatures-and-macros/all.rkt >>> context...: >>> /Users/pgiarrusso/opt/racket/collects/compiler/cm.rkt:341:0: compile-zo* >>> /Users/pgiarrusso/opt/racket/collects/compiler/cm.rkt:556:26 >>> /Users/pgiarrusso/opt/racket/collects/compiler/cm.rkt:548:42 >>> /Users/pgiarrusso/opt/racket/collects/compiler/cm.rkt:513:0: >>> maybe-compile-zo >>> /Users/pgiarrusso/opt/racket/collects/compiler/cm.rkt:628:2: do-check >>> /Users/pgiarrusso/opt/racket/collects/compiler/cm.rkt:708:4 >>> >>> /Users/pgiarrusso/opt/racket/share/pkgs/compiler-lib/compiler/commands/make.rkt:81:8: >>> for-loop >>> >>> /Users/pgiarrusso/opt/racket/share/pkgs/compiler-lib/compiler/commands/make.rkt: >>> [running body] >>> /Users/pgiarrusso/opt/racket/collects/raco/raco.rkt: [running body] >>> /Users/pgiarrusso/opt/racket/collects/raco/main.rkt: [running body] >>> >>> == >>> >>> #lang racket >>> (module base-sig racket/base >>> (require racket/unit) >>> (require (only-in racket/function thunk)) ; Omitting this line crashes >>> the compiler >>> >>> (define-signature reify^ >>> (reify-thunk >>> (define-syntaxes (reify) >>> (syntax-rules () >>> [(_ e) >>> (reify-thunk (thunk e))])) >>> )) >>> >>> (provide reify^)) >>> >>> (module base racket/base >>> (require racket/unit) >>> (require racket/control) >>> (require (submod ".." base-sig)) >>> >>> (define-unit reify@ >>> (import) >>> (export reify^) >>> (define (reify-thunk computation) >>> (reset (computation))) >>> ) >>> (provide reify@)) >>> >>> (module client racket >>> (require (submod ".." base)) >>> (define-values/invoke-unit/infer reify@) >>> >>> (reify 0) ; This call is needed to trigger the crash >>> ) >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Racket Users" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to racket-users+unsubscr...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. > > > > -- > Paolo G. Giarrusso - Ph.D. Student, Tübingen University > http://ps.informatik.uni-tuebingen.de/team/giarrusso/ > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
