Roger Browne <[EMAIL PROTECTED]> wrote: > > HLL Private Namespaces > > HLLs should use a namespace with an underscore and the lowercased > > name of the HLL to store any private items. For instance, Tcl should > > use the "_tcl" namespace to store the subroutines that make up the > > compiler. > > Is it the intention that Parrot will enforce that these names are kept > private?
Nope. ParTcl is written in PIR. Other compilers may also be written in PIR. There are two things we want to avoid: conflicting symbols between different compilers and conflict symbols between compilers and user-defined code. If compilers don't place their symbols in a namespace other than the root namespace, two compilers may end up defining different symbols that have the same name. ParTcl has a compile() sub, for instance. If another compiler were to introduce a compile() sub in the same namespace, things would break. So we need to put these somewhere. You've suggested putting these internal subs under "tcl". But what happens if the user tries to define a compile() sub in Tcl's root namespace? Now we have the some problem: 2 different symbols with the same name. We can't just change the internal sub to be _compile(), because the user could also define a _compile(). We could prefix all user-defined subs with some char, but that's a far amount of work. Which is why I've suggested private HLL namespaces for compiler internals. > If so, it would be good to say so. > > If not, then the HLL can store its private stuff however it wants (under > its own first-level namespace), and define "import_into" so that it will > refuse to share its private stuff. In that case, the HLL is responsible > for keeping its own private stuff private, and there is no need for the > spec to refer to unenforced private namespaces. I don't think you'll really be interested in importing the guts of the Tcl compiler into your program. But if that's what you really want, I'm not going to stop you. (And neither should Parrot.) -- matt diephouse http://matt.diephouse.com