scope-sets-5 section 2.2 Bindings

31 views
Skip to first unread message

Anthony Carrico

unread,
Aug 29, 2015, 12:49:03 AM8/29/15
to Matthew Flatt, racket-dev
> 2.2 Bindings
>
> When macro expansion encounters a binding form, it
>
> * creates a new scope;
>
> * adds the scope to every identifier in binding position, as well as to
> the region where the bindings apply; and
>
> * extends a global table that maps a ⟨symbol, scope set⟩ pair to a
> representation of a binding.

Here it seems like the "<symbol, scope set> pair" itself would make a
fine "representation of a binding". Then the global binding table would
just be a global binding set, and the <symbol, scope set> pair itself
would key the compile time environment.

> Each local binding is represented by a unique, opaque value (e.g., a
> gensym).A binding to a module export is represented by the module
> name paired with a serializable identifier for the definition within
> the module.

Are module exports the reason for a global binding table instead of a
global binding set? Is it mainly for flexibility/convenience of adding
other data to the binding's representation rather than storing such
things in aux. tables? Or am I missing something (very likely!)?

--
Anthony Carrico

signature.asc

Matthew Flatt

unread,
Aug 29, 2015, 4:20:15 PM8/29/15
to Anthony Carrico, racket-dev
The general reason is that the compile-time environment is ephemeral
--- but, yes, the reason that matters mostly has to do with module
bindings.

Suppose you have a module

#lang racket/base
(provide m)
(define-syntax-rule (m) (lambda () #t))

The implementation of `m` includes a syntax object #'lambda, and that
syntax object needs to carry the information that it references
`lambda` from `racket/base`.

By the time the module is expanded or compiled, there is no
compile-time environment, anymore. So, the information that `lambda`
refers to the export of `racket/base` can't be in the compile-time
environment. The information needs to be in the binding store.

The same thing happens with references to top-level bindings, since
references to those can also appear in an expanded term that doesn't
itself include the binding. For references to local bindings (that
haven't disappeared), the connection between the reference and a
specific binding can be rediscovered in a given term; I guess the
symbol plus scope set would work for the binding's representation in
that case, instead of an arbitrary opaque value.
> --
> 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/55E139AB.3010009%40memebeam.org.
> For more options, visit https://groups.google.com/d/optout.

Anthony Carrico

unread,
Aug 30, 2015, 9:49:56 PM8/30/15
to Matthew Flatt, racket-dev
On 08/29/2015 04:20 PM, Matthew Flatt wrote:
> The general reason is that the compile-time environment is ephemeral
> ...

Terrific--thank you for the detailed answer.

--
Anthony Carrico


signature.asc
Reply all
Reply to author
Forward
0 new messages