Ambiguous binding error in my curly-fn package under the new macro expander?

31 views
Skip to first unread message

Alexis King

unread,
Jul 18, 2015, 2:41:28 PM7/18/15
to Matthew Flatt, dev
I’ve found an error that I believe is the fault of my curly-fn package under the new macro-expander, but it’s a little bit odd, and I’m having trouble figuring out exactly what the problem is. Specifically, the error doesn’t occur within the curly-fn package itself, only a package that depends on it, and even then I’ve only managed to reproduce the error using two files. Trying to cause the same problem using submodules doesn’t work, either.

The simplest possible test case I’ve found to reproduce the problem is as follows:

; ambiguous.rkt
#lang curly-fn racket/base
#{values}

; dependent.rkt
#lang racket/base
(require "ambiguous.rkt")

An error is signaled by ‘dependent.rkt’:

let: identifier's binding is ambiguous
context:
#(21084 module) #(21093 module curly-parser 0) #(113962 module)
#(113963 module ambiguous 0)
matching binding:
#<module-path-index:(racket/base)>
#(113962 module) #(113963 module ambiguous 0)
matching binding:
#<module-path-index:(racket/base)>
#(21084 module) #(21093 module curly-parser 0) in: let

If I understand this correctly, this means that for some reason, there are conflicting bindings for ‘let’ in this example, probably due to how my curly-fn meta-language provides identifiers (and uses ‘let’ from racket/base in its expansion), but I really have no idea why this is manifesting in this way, nor do I know how to fix it.

Could anyone point me to what exactly is wrong here?

Alexis

Matthew Flatt

unread,
Jul 18, 2015, 5:41:04 PM7/18/15
to Alexis King, dev
I think this is the essentially same issue as in `afl` in the thread
where I just re-replied.

It looks like `curly-fn` wasn't introducing a mark the way that `afl`
did, and so it wasn't defending against a local `let` binding with the
old expander. For example,

#lang curly-fn racket
(let ([let 5])
#{values})

reports an error with the old expander, instead of avoiding the local
binding of `let` for the identifier introduced by `#{....}`.

For the new expander, the idea is to add a scope to the entire module
read by `#lang curly-fn`, but arrange for that scope to be removed in
the identifiers introduced by `#{....}` so they won't be bound by
anything in the enclosing module.
> --
> 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 racket-dev+...@googlegroups.com.
> To post to this group, send email to racke...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-dev/B5D45B8F-6059-4104-AC35-CB0B683EFF
> BA%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages