At Wed, 15 Apr 2015 17:43:42 -0400, "Alexander D. Knauth" wrote: > > On Apr 13, 2015, at 8:40 AM, Matthew Flatt <[email protected]> wrote: > > > Most packages build ok using the above snapshot: > > > > http://next-pkg-build.racket-lang.org.s3-website-us-west-2.amazonaws.com/ > > > > Several failures are "ambiguous binding" errors. That error usually > > indicates an unavoidable incompatibility between the old and new macro > > systems. I'm interested to hear whether the package authors can > > understand the errors and fix them and whether the incompatibilities > > seem manageable. > > For a “hygienic" reader-extension, that outputs syntax with lexical context > telling it where an identifier should be from so it isn’t captured, what > should > I do in the new expander? > > For example the afl and rackjure pkgs both provide a reader extension that > looks like for example: > #λ(+ % 1) > Which is read as: (sort of) > (lambda (%) (+ % 1)) > Where the `lambda` identifier has lexical context that says that it comes > from > racket/base. > > But with the new macro expander, I’m seeing errors like this: [...] > > So, is there a way to do this in the new macro expander?
I don't think a "hygienic" reader extension works in the old expander, either. The `lambda` produced by the `afl` or `rackjure` reader doesn't reliably refer to the `lambda` from `racket/base`, because a local binding for `lambda` captures the reader-produced `lambda`: #lang rackjure (let ([lambda 5]) #λ(+ % 1)) ; => unbound `%1` There's another problem, but it's more subtle: #lang afl racket/kernel #λ(+ % 1) This one goes wrong because there's no run-time dependency on `racket/base`. (In the case of `#lang rackjure`, that particular problem doesn't happen, because the reader is bundled with a regular module dependency that pulls along `racket/base`.) Some of us refer to these problems as the "graphical syntax problem", because we've run into them when attempting to implement non-textual syntax. We don't yet have a solution, but I hope we find one eventually. Meanwhile, I think readers have to produce syntax objects that have no lexical information (i.e., no scopes). -- You received this message because you are subscribed to the Google Groups "Racket Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/20150416121737.573866501BC%40mail-svr1.cs.utah.edu. For more options, visit https://groups.google.com/d/optout.
