On Mon, Sep 05, 2005 at 01:43:20PM -0400, Matt Diephouse wrote: > In order to help finish Parrot's HLL namespace support, I've compiled > a list of features and information that I believe is necessary to > support the target languages. I've done so after doing a survey of > these languages. I may have missed something or misunderstood > something: please check that this information matches what you know > about these languages. > > It is my intent that this be merely a factual document. I want to > begin on the implementation details only after we have a clear > specification. > > Naming Strategies and Storage > > Different languages store their variables and subroutines/methods in > different > ways and places. Parrot must support all of these and, if possible, allow > interoperability. > > Types > 1. Python: Variable and subroutine/method names overlap; you cannot have > two > items that share the same name. > 2. Ruby, Tcl: Variable and subroutine/method names do *not* overlap. > 3. Perl 5: Globs prevent overlap. > 4. Perl 6: Sigils prevent name collisions.
> Default Namespaces > > Python: __main__ > Ruby: main > Tcl: :: > Perl5: main > Perl6: ::*Main I think it would be worth mentioning if the namespace is hierarchical (nested) or flat (the delimiters are part of the name). 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 :) > 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. > - 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. 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. --- 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. The most natural way to do that is to give each HLL its own 'virtual root' near the top of a shared namespace hierarchy. 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.) Tim.
