Tim Bunce <[EMAIL PROTECTED]> wrote: > I think it would be worth mentioning if the namespace is hierarchical > (nested) or flat (the delimiters are part of the name).
Good idea. > Another issue is whether there's an underlying hierarchy that can be > accessed (at leaf and/or non-leaf nodes) to do things like namespace aliasing: > > *Short:: = \%Very::Long::Name::; # (possibly incorrect p5 syntax :) Yes. I had this in mind but didn't write it explicitly. > > Namespace Capabilities > > > > - Importing > > Items must be imported from one namespace to another. Tcl requires > > that > > this be a snapshot - meaning that changes in the original namespace do > > not affect the imported items - while other languages use aliases. > > > > Items can be specified by tags (:all, :default), by patterns (c*), or > > by > > names. > > How items are specified for import/export seems to me a HLL-private issue > and not one that need to be part of this specification. It just needs to be possible to use different methods of specification. Namespaces in Parrot are currently C objects and are not language specific. > > - Exporting > > Not all items can be exported; a list must be kept of which items can > > be. > > These items can also be specified by tags, patterns, and names. > > Patterns > > are not expanded until the time of the import (which may occur more > > than once). > > Same here. > > (I'm just trying to keep focused on the Parrot-relevant issues.) > I think it would be a bad idea to try to implement direct support for > specific HLL behaviours in Parrot. Better to distill a set of primitives > that HLLs can use as a foundation. > > Perhaps you're more focused on the HLL issues because of the need for > interoperability. I'd argue that interoperability doesn't need to be > easy, it just needs to be a) possible, and b) encapsulate-able. > Given those then "easy" can be implemented via add-on modules > that encapsulate the messy details. Agreed. I'm not necessarily as worried about easy as I am about possible, although there's no reason not to have easy if that's also possible. ParTcl already implements a few hacks (in different areas) to work around lack of support from Parrot. These hacks are going to get in the way of interoperability. That's what I'm worried about. > To give a more concrete example: Parrot itself shouldn't have to > understand the semantics of the Perl5 Exporter module in order for > a Python module to import symbols from a Perl5 module. > That kind of understanding belongs in a separate module. > > It may help to think of the HLLs as objects with methods that handle > HLL-specific details. Perhaps HLL_specific subclasses of a Namespace PMC. > Something vaguely like: > > $python_namespace->foreign_import( $perl5_namespace->foreign_export(...) ) > > The issues then become: what gets passed between them, and what > few basic underlying parrot primitives are needed to support them. > > The same applies to unimporting and querying. That's what I'll eventually be getting to. But in order to design those methods well, we need to know what tasks we need to accomplish. What's even more important, I think, is the storage slots for the necessary information. Where should ParTcl store the original namespace for all of its commands, for instance? Probably somewhere in the namespace PMC, but it ought to be a thought out place. > --- > > Having said all that, I don't think it's worth worrying about > inter-language issues until more fundamental namespace co-existance > issues are more settled. > > Will a Python module clash with a Perl6 module of the same name? > (That way lies insanity so I certainly hope not.) > > If not then separate namespace hierarchies are required. Agreed. That's also something that needs to be considered wrt to namespaces and importing/exporting. > The most natural way to do that is to give each HLL its own > 'virtual root' near the top of a shared namespace hierarchy. Agreed. > See this thread, especially message 16 (and then 13,14,15 :) > http://groups.google.com/group/perl.perl6.internals/browse_frm/thread/678fbfc5a14813b5 > > How close is Parrot to supporting that functionality now? > (Please excuse me and point me to the docs if this is already settled.) That's the next step -- figuring out what we can already do. -- matt diephouse http://matt.diephouse.com
