[plt-scheme] Shadowing imported bindings

From: Bradd W. Szonye (bradd+plt at szonye.com)
Date: Fri Oct 24 13:12:02 EDT 2003

In PLT Scheme, imported bindings cannot be set! or shadowed. For
example, the following module is illegal:

    (module foo mzscheme
        (set! + my-plus)
        (define + my-plus))

I understand why set! is not permitted, by why is rebinding (shadowing)
also disallowed?

You can get both set! and shadowing if you really need them, with one
important exception. Modules can export their own set!-type methods that
let you change their internals. In other words, you can use set!, but
only if the module wants you to, which is good.

And you can manually "shadow" imported names in most cases. For example,
you can get the SRFI-1 and MzLib list libraries to coexist thus:

    (module merge mzscheme
        (require (prefix mzlib: (lib "list.ss"))
                 (prefix srfi-1: (lib "1.ss" "srfi")))
        (provide (all-except ...)))

In other words, you manually select which names you want from each
library, which is also a good thing. However, I don't know of any way to
shadow names from the initial import language, not even manually. Once
you've written

    (module foo mzscheme ...)

I don't know of *any* way to shadow or rebind names from mzscheme. There
is a workaround for this too (create your own module "language" based on
the mzscheme, and use that instead), but it's a lot trickier.

It seems to me that shadowing would be simpler from the user's point of
view, but it might cause problems with "what does this code really
mean?" since module bindings cover the entire module scope. To permit
shadowing, you'd need some rule like "the name provided by the textually
latest REQUIRE covers the entire scope." I suspect that there's an ease
of use vs error-proneness issue here.

Was this a conscious design choice, or did it just fall out of the
implementation? I did notice that Scheme-48 modules are slightly
different; they forbid set! but permit shadowing. (That's not criticism
of PLT Scheme -- just noting that another implementation made different
choices.)
-- 
Bradd W. Szonye
http://www.szonye.com/bradd


Posted on the users mailing list.