At Sat, 9 May 2015 10:10:12 -0400, "Alexander D. Knauth" wrote: > > 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? > [...] > Or do you mean that this would work if I put define-unbindable-id in once in > afl/reader.rkt, or something else?
"No" to the former, "yes" to the latter. The macro and use would be in the reader's implementation. The reader would return the identifier bound to `afl-lambda-id` where it currently returns a `lambda` identifier. > Plus there’s also the possibility of one of begin, require, only-in, > define, or quote-syntax being shadowed, right? Yes, you'd need `(define-unbindable-id afl-define-syntax define-syntax)`, and so on, for all the identifiers produced by reading `#λ...`. For the rest of your message below: I don't know. An answer to these questions is research --- maybe a good topic for you! I'm happy to discuss the issues further, but e-mail is not great for that kind of discussion; if you're interested, maybe we could try a different mode. Meanwhile, relevant to this thread, a question is whether the set-of-scopes expander likely to lose anything --- relative to the current expander --- that's needed for a good solution to the problem. I think it isn't, mostly because we didn't have a good answer so far. > > 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/20150509155926.53F2A6501C0%40mail-svr1.cs.utah.edu. For more options, visit https://groups.google.com/d/optout.
