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.

*)       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

Reply via email to