Leopold Toetsch <[EMAIL PROTECTED]> wrote: > Some unsorted notes while reading through it: > > *) definition: "current namespace"
> *) namespace separator: "::" > In this document, "::" indicates namespace nesting. 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.) > *) ... unicode encoding > > I'm not sure if this is a good idea for language interop. Especially > what charsets are allowed? 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. > *) 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. 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. > *) 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? That should work well. I think it's a great idea. We'll just need an okay from Chip. > *) Typed Interface > > I've already layed out earlier in reply to Matt's proposal that this > will be mostly unusable for e.g. Python. 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. > *) load_library($S0, $S1, ...) > > We don't have any va_list syntax like that. 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. > *) 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 > ;) 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
