On May 9, 2015, at 8:59 AM, Matthew Flatt <[email protected]> wrote:
> Yes, with the current expander, adding a fresh mark on the > reader-introduced identifiers makes them impossible to bind (except by > picking apart the form produced by `#λ...` to extract the special > identifiers). > > Although that strategy doesn't work with the set-of-scopes expander, > you can get the same result for both expanders by making the symbolic > half of the identifier fresh, instead of the lexical-context half. That > is, with > > (define-syntax (define-unbindable-id stx) > (syntax-case stx () > [(_ name id) > (with-syntax ([gen-id (string->uninterned-symbol > (symbol->string > (syntax-e #'id)))]) > #`(begin > (require (only-in racket/base [id gen-id])) > (define name (quote-syntax gen-id))))])) > > (define-unbindable-id afl-lambda-id lambda) > > use `afl-lambda-id` in place if `#'lambda`. Do you mean that the afl reader would add a (define-unbindable-id ….) to the module body? But then what if I use something like #lang afl syntax/module-reader or something else that’s dependent on stuff like that? Plus there’s also the possibility of one of begin, require, only-in, define, or quote-syntax being shadowed, right? Or do you mean that this would work if I put define-unbindable-id in once in afl/reader.rkt, or something else? > I see that you've set up `afl` so that `#λ...` will work in phases -10 > to 10. I also see that `rackjure` doesn't do that, supporting only > phase 0. It may be worth noting that the change applied to `rackjure` > means that `#λ...` can no longer work in phases other than 0 (since > client code cannot introduce a suitable binding). And we'd probably > agree that `afl`'s support for specific phases is a hack. Yes; that’s why before I had been asking about whether there was a way to create an identifier that told the macro expander that it’s supposed to be bound to lambda from racket/base no matter what phase level it’s in, but you already answered that question. > The uninterned-symbol approach has the same limitations. I think I’m misunderstanding something here, so this depends on you answer to my first few questions, but how? > Those limitations make me feel that these approaches are the wrong > direction for a general solution. Both approaches introduce a dimension > (i.e., scopes) into reader results that isn't supposed to be at that > level, similar to the way that syntax objects are not supposed to be > "3-D". Another way to put it is that `read` is meant to work for > reading code (although with a loss of source-location information), not > just `read-syntax`. Even if you pretend that it never worked at all, though, Why shouldn’t the reader be able to tell the macro expander about how identifiers should be bound? I understand the problem with 3d-syntax based on the separation of phase-levels and the separate-compilation guarantee, but is there a similar argument for why this shouldn’t work? > Meanwhile, I think that reader extensions should be able to define new > kinds of literals, and those literals should work with `quote`. While > `#λ...` isn't that kind of extension, it should have a more predictable > result under `quote. But `quote` is a bigger problem for other > extensions that we've tried, such as images or quaternions. Do you mean that you would expect (quote #fn(+ % 1)) to produce the same procedure as it would without the quote? But that’s starting to get into more 3d-syntax, right? This is off topic and has nothing to do with #fn, but would the structs for the images or quaternions need to be defined in a cross-phase-persistent module? > Maybe the answer is that reader extensions produce a certain kind of > prefab struct, and something in the expander level should allow those > prefabs to be handled differently, even under `quote`. Something like > that might enable extensions that are abstract and work across phases > while also giving languages control over what kinds of values are > allowed. Um, I think I’m lost again. How would this work? Are you saying that this would be an alternative to 3d-syntax, or would this be used for things like #fn? -- 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/80A99573-91A4-4950-849E-34AB3077E968%40knauth.org. For more options, visit https://groups.google.com/d/optout.
