3.1.3 There is *no* global namespace in Dylan
Jason
Is it non-Dylan thinking to wish there was access to the namespace?
Mark Craig Chu-Carroll
Two things:
  • Why do you *want* access to the namespace?

    I'm used to be able to much around with symbol bindings in CommonLisp, but I've needed to in Dylan. It's a *lot* cleaner and safer to just use a table.
  • Names don't exist at runtime in Dylan.
If you give up that distinction, and require the implementation to maintain symbol tables at runtime, then you're crippling a huge number of useful optimizations. It can also get terribly confusing, because
     there is *no* global namespace in Dylan.
  • The names of variables depend on the module in which they're used.
  • The names of modules depends on the libraries in which they're used.
  • And the names of libraries depend on the environmental context in which they're compiled!

In most Dylan implementations, a libraries name can be altered by the environment. When you declare a library "A" which imports a library "B", the binding of the name "B" to a particular library is performed by the environment. There is no guarantee that the library that you use as "B" was compiled as "B"; it may have been compiled as "HickeldyGobblyGook".
Top