pdd21 notes

*) definition: "current namespace"
...
(Pasm also has its own separate concept of current namespace ...

Why and how? And what doest that mean? I don't see any difference WRT
PASM code.

*) namespace separator: "::"
In this document, "::" indicates namespace nesting.

This looks too much misleading to me. Folks are already creating
'foo::bar' namespaces in parrot all over the place, which just aren't
doing, what perl5 does. These are *not* nested namespaces at all, and
will be unaccessible by e.g. Python. While the document states, that
this is just an annotation, it's too much perlish and doesn't really
help non-perl users. A notation ['perl5';'CGI'] or [perl5;CGI] is much
better IMHO and reflects Parrot's usage of nested namespaces.

*) ... unicode encoding

I'm not sure if this is a good idea for language interop. Especially
what charsets are allowed?

*) definition: "HLL" *and* Parrot

Parrot isn't a HLL, but the document doesn't spec at all, where Parrot
itself should put it's symbols. Currently each PMC and class occupies
an entry in the top-level aka global namespace.

$ cat ns.pir
.sub main :main
.local pmc ns, m
ns = find_global "\0String"
print_item ns
m = ns['lower']
$S0 = typeof m
print_item $S0
print_newline
.end

$ ./parrot ns.pir
Hash[0x808523c] NCI

Additionally the namespace "__parrot_core" is used for MMD builtins.

*) Raw Interface

The choosen method names are either misleading (e.g. 'add' vs
infix:<+>) and/or not available as 'standard' vtable functions. Why not
just use the Hash interface?

*) Typed Interface

I've already layed out earlier in reply to Matt's proposal that this
will be mostly unusable for e.g. Python.

*) load_library($S0, $S1, ...)

We don't have any va_list syntax like that.

*) export_to($P0, ...)

Besides the va_list syntax the wild card support $P1.export_to($P0,
'w*') seems to belong into the HLL. OTOH there isn't any 'import' hook
that might be necessary to deal with type mismatches, interop issues,
and whatnot. (But I haven't thought much about export/import at all yet
;)

leo

> *) namespace separator: "::"

As conventions, these are only here to make it easier to communicate
in the body of the PDD. They're there more for the writer of the
document than its readers. (Although they will hopefully make things
easier for the reader to understand as well.)

The problem is that unicode is necessary in some form (even if it's
just an escaped ascii string) for interoperability. Otherwise a
non-unicode-aware language will have trouble using Tcl, because it can
have unicode characters in namespace names (and vice versa).

In other words, there just needs to be a standard. And the standard
needs to handle unicode.

I would probably move the MMD builtins into a namespace inside of the
parent _Parrot namespace (_Parrot::MMD?). But this is more or less
arbitrary and shouldn't have any effect on any users, I don't think.

I'll defer the question of what to do with PMCs and classes to Chip.
*grin* But it shouldn't be a problem to leave them where they are for
now.

That should work well. I think it's a great idea. We'll just need an
okay from Chip.

Your reply was mostly geared towards how Python would implement the
various find_* methods and how its exporter would be able use the
add_* methods. You argued that CPython doesn't know at runtime whether
an object is a function or just a variable.

I disagree with you. CPython may emit the same bytecode in some
instances, but that just means that its bytecode is ignorant; it
doesn't mean that CPython doesn't know the difference. And to show you
that it does:

harmony:~ mdiep$ python
Python 2.3.5 (#1, Mar 20 2005, 20:38:20)
>>> a = 1
>>> type(a)
<type 'int'>
>>> def a():
... print "a"
...
>>> type(a)
<type 'function'>
>>> class a:
... pass
...
>>> type(a)
<type 'classobj'>

Python's exporter can use type() to choose with add_* interface to use
if necessary. It *is* possible.

I don't have any comments here. If this can't be made to work, the
other option is to use an array of strings.

I'm not sure what you mean by "seems to belong into the HLL".

The typed interface is supposed to eliminate the need for an import
hook. I gave it quite a bit of thought. (Hopefully enough for the both
of us ;-)

--
matt diephouse
http://matt.diephouse.com

I actually had the reader in mind, myself. But perhaps it's not worth the
semantic confusion. Once you get used to ["a"; "b"] it isn't all -that-
more confusing than "a::b".

Indeed, for any given HLL "L", no one is in a better position than L's
exporter to know which of L's objects are more function-like than
variable-like. That's why the idiom is
source.export_to(target)
rather than
target.import_from(source)
--
Chip Salzenberg <ch...@pobox.com>

First, please remember that when Python exports to Python, it's allowed to
notice that the source and target have compatible conventions and go
directly to the untyped interface, thus avoiding the whole typing issue.

Say, that gives me an idea. Python-like untyped namespaces are a
significant subpopulation.

Matt: How about a standard namespace method:

INTVAL is_typed()

which returns false for the simple Python-like unmangled namespaces? This
would allow -all- untyped namespaces to export to each other without hassle,
even if they're from different HLLs.

Meanwhile, for Python->Perl interoperability, I think Matt correctly
observes that e.g. python::namespace.export_to() will be able to make a good
decision in most cases as to whether a given Python object should be
exported as a sub or a variable. The Perl namespace's typed interface will
have to figure out what kind of variable it thinks it's getting. That
decision could be fairly arbitrary, but users will adapt to whatever
decision it tends to make.

As for the uncommon case in the uncommonner case -- oddball objects crossing
from Python to Perl -- well, that's where the Python-on-Parrot
implementation will just have to adapt to its environment, if it actually
wants to be useful to Perl users.

You may be right abou the Hash interface. I'll hack the doc and see if it
works.

Don't read too much into the word "separate". I'm just distinguishing
the process of compilation from the process of execution.

I doubt that problem will ever go away no matter what we write. I can
imagine that Parrot core warnings will someday include "You just created or
looked up a symbol with '::' in its name."

Um, huh? What could be better for language interop than a single unified
encoding like Unicode? And in what sense does "Unicode" leave "charset"
undefined?

I haven't made my mind up on that. The status quo is good enough ATM. It's
possible we'll be polluting the top level with a fair number of things even
at 1.0 time.

Oh yeah, what with all the :flat and :slurpy support I keep forgetting that
the PMC methods are more limited. I'll replace those with array PMCs.

> *) export_to($P0, ...)
>
> The wild card support $P1.export_to($P0, 'w*') seems to belong into the
> HLL.

The base export_to won't do much in the way of pattern recognition; if
wildcards are supported, they will be quite limited, and I'll make that
clearer. Anything more interesting will be implemented by HLLs' customized
namespace PMCs. I'll put that in the pdd.

That's the purpose of the typed interface on the target namespace.
--
Chip Salzenberg <ch...@pobox.com>

The more I think about this, the less I like it.

It would be good for the typed interface to _allow_ an exporter to specify
more precisely what kind of variable it has, if it knows. For example:

add_scalar(STRING, PMC*)
add_array(STRING, PMC*)
add_hash(STRING, PMC*)

these would be defined to default to simply add_var(), but Perl namespaces
would implement them to do the obvious (prepending '$', '@', and '%',
respectively).

I'm less sure about the value of find_{scalar,array_hash}, but they'd be
cheap to write, and consistency is a Good Thing.

/me keeps thinking
--
Chip Salzenberg <ch...@pobox.com>

It definitely shouldn't be a problem. But it's only useful if you
think that languages won't be able to correctly identify their own
types: compiler writers will have to write export code that uses the
typed interface anyway. So this won't generate less code, but it's
possible that it will improve interoperability (and possibly speed).

At this point, I'd probably say to just leave this until later. I'm
not convinced that we need it. But if we do, it'll be simple to add.

As you surmise, it's a performance hack. It's still useful if it just
allows a significant number of export events to *avoid* the processing of
identifying object types. Python-like namespaces will use this test
*instead* of the "are you of the same namespace type as me" test for
shortcut processing.
--
Chip Salzenberg <ch...@pobox.com>

WRT namespaces, I'm starting to think we should replace each *_var()
functions with three functions *_scalar(), *_array(), and *_hash(). Parrot
is ingrained with the idea that values can be unkeyed, integer-keyed, or
string-keyed. More complex keys are also available, of course, but those
three are privileged (and for good reason).

Perlish languages will want the distinction (thus the change is helpful),
and Pythonish languages won't care -- everything is unprefixed (thus the
change does no harm).
--
Chip Salzenberg <ch...@pobox.com>