On Dec 5, 2005, at 5:55, Matt Diephouse wrote:
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
Of course, now that I think about it more, it's possible that nothing
else will be adding namespaces for Python.
Or: only python itself can create Python namespaces.
In which case I'd advocate
having Parrot keep track of namespaces in a separate hash.
That's more an implementation detail than anything else, but yes, it
sounds reasonable. We have to look, how classes (and PMCs) fit into the
scheme.
Remaining for me is the distiction between a variable and a function
symbol:
- python: no (all names are just names)
Correct. Variables, functions, and namespaces all collide.
- tcl: afaik no (all names are strings)
Incorrect. You can have a variable, a function, and namespace with the
same name.
- perl5: sometimes (via sigil, but $ref_tosub)
- perl6: maybe (sigil is part of the symbol name, but $ref)
Functions, variables, and namespaces _are_ separate here.
Namespaces are always distinct, let's keep them aside. All the opcodes
that deal with namespaces define the interface for a 'namespace'. E.g.
store_global "Foo", "bar", $P0
defines "Foo" being a namespace, or C<get_namespace> returns one, and
so on.
Don't let
the fact you can make a variable reference a sub throw you off. They
are separate entries in the symbol table and separate entities.
How so?
our $a;
sub foo { sub {1} }
$a = foo();
Now you (the compiler) wants to store the 'scalar' $a into an
appropriate namespace. The compiler doesn't know that '$a' is a code
reference, therefore 'add_sub' isn't used.
To make use of this distinction (var, function) we'd need a pair of
such languages, one that can do a typed export, and one that can do a
typed import of symbols.
Not really. It's a useful distinction if one of the languages makes
the distinction. Let's take the case of Tcl and Python. Remember that
functions and variables overlap in Python but don't overlap in Tcl.
If you import a function from Tcl into Python, it should be a
variable. That's fine. add_sub can take care of that. That's the
intention. It'd work the same if you used add_var, but that doesn't
matter. The important thing is that Tcl doesn't need to know anything
about Python.
CPython bytecode or any other implementation can just issue a
'LOAD_NAME' or 'LOAD_GLOBAL' opcode for fetching a name. The Python
import can just ask for some 'tcl.module.name'. Now tcl has the names
split into 3 categories. Which implies that the tcl 'name-exporter' has
to look into all 3 categories and deliver a matching name (and fail, if
there are dpulicates, but only when exporting to Python, and not when
exporting internally).
This means that, while tcl internally has of course the split of the
names, it's not really useful for the export to other HLLs.
Importing from Python to Tcl is a different matter. Python's function
may be variables, but Python still knows that they're functions.
No, CPython doesn't know that:
a = 1
a()
...
2 6 LOAD_NAME 0 (a)
9 CALL_FUNCTION 0
That's absoletly the same bytecode as produced by the 2nd line of:
class a: pass
a()
So
Python can use add_sub to add the function to Tcl's namespace.
Nope. The tcl 'name-importer' has to check the type of the names to
DTRT.
This is
both useful and necessary because function and variable names don't
overlap in Tcl.
It might be necessary but can't and doesn't work like this.
This all doesn't really preclude parrot support for split namespaces,
but I really see not much use for it, as most languages (that need) it,
know how do deal with it (e.g. Perl6: store the sigil with the name).
leo
