Leopold Toetsch <[EMAIL PROTECTED]> wrote:
t/pmc/namespace.t
Please have a look at the supported syntax constructs. Are these sufficient for HLL writers?
Some more thoughts WRT namespaces.
We can define a namespace, where a function or method is stored:
.namespace ["Foo"] .sub bar ...
This does effectively (during bytecode loading)
store_global "Foo", "bar", pmc_of_sub_bar
But what happens, if the PIR file contains just a plain
bar()
Since PIR behaviour is ours to define, it can do whatever we want. I'm inclined to rule that a plain
bar()
is equivalent to:
current_namespace::bar()
and as such the PIR compiler should look up the function by name in the current namespace and then invoke it.
The implementation looks into the current namespace and then in other namespaces present in the compiled source file, which seems to be quite wrong to me.
Yeah, this isn't the right thing.
Since invoking a sub in the current file's also useful and something we do (I'm making heavy use of it. It's nice :) I can see having alternate syntax for it. Perhaps:
:bar()
looks for the bar sub in the current namespace in the current file and invokes it, skipping any sort of by-name lookup or runtime sub overriding.
(And yeah, I suggest this even though it'd mean rewriting some of my compiler's codegen code)
Any semantics past these (simple lookup by name, and simple compiletime lookup) should be delegated to the individual language compilers, and they can emit code to do whatever oddball things they may need to do, though I'm not sure there's a whole lot more that'd need to be done for most languages. (Especially since namespaces are supposed to be lexically and dynamically overridable, as well as layered, but that's all a separate thing)
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
