{reordered for better reading}
On Mon, Jan 23, 2006 at 10:56:33PM +0100, Leopold Toetsch wrote:
> *) Typed Interface
>
> I've already layed out earlier in reply to Matt's proposal that this
> will be mostly unusable for e.g. Python.
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.
> *) 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?
You may be right abou the Hash interface. I'll hack the doc and see if it
works.
> Some unsorted notes while reading through it:
> *) 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.
Don't read too much into the word "separate". I'm just distinguishing
the process of compilation from the process of execution.
> *) namespace separator: "::"
> In this document, "::" indicates namespace nesting.
>
> This looks too much misleading to me.
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."
> *) ... unicode encoding
>
> I'm not sure if this is a good idea for language interop. Especially
> what charsets are allowed?
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?
> *) 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.
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.
> *) load_library($S0, $S1, ...)
> We don't have any va_list syntax like that.
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.
> OTOH there isn't any 'import' hook that might be necessary to deal with
> type mismatches, interop issues, and whatnot.
That's the purpose of the typed interface on the target namespace.
--
Chip Salzenberg <[EMAIL PROTECTED]>
