Re: Iterating through two arrays at once
On Wed, Dec 10, 2003 at 11:44:15PM -0500, Joe Gottman wrote:
:In Perl 6, how will it be possible to iterate through two arrays at the
: same time? According to Apocalypse 4, the syntax is
: for @a; @b -> $a; $b {
:
: According to the book "Perl 6 Essentials" the syntax is
: for zip(@a, @b) -> $a, $b {
:
: Which of these is right? (of course, this being Perl, both may be right).
The latter is righter.
: Whichever of these syntaxes is right, what happens when @a and @b are of
: different sizes? I can think of three possible behaviors, each with its
: potential drawbacks:
:
: 1) The loop executes min(+ @a, + @b) times, then finishes successfully.
: 2) The loop executes min(+ @a, + @b) times, then throws an exception
: because the arrays were not of the same size.
: 3) The loop executes max(+ @a, + @b) times. If @a has fewer elements
: than @b, then after @a's elements are exhausted $a is set to undef, and
: similarly if @b has fewer elements than @a.
3 is what happens. That has not changed from the Apocalypse.
:In cases 1) and 2), the problem is how to get the elements of the larger
: array that were never iterated over. Case 2) is probably better than case
: 1), because the exception that is thrown might contain information about
: which array was larger and which elements of it have yet to be examined. In
: case 3), the problem is differentiating between an undef returned because
: the arrays were of different sizes, and an undef returned because one of the
: arrays contained an undef.
In Perl 6, undef is not necessarily a unique value. It might well contain an
unthrown exception with all the information you want hidden in a property.
That being said, it's generally erroneous to rely on any undefined value
regardless of its origin.
Larry
Iterating through two arrays at once
In Perl 6, how will it be possible to iterate through two arrays at the
same time? According to Apocalypse 4, the syntax is
for @a; @b -> $a; $b {
According to the book "Perl 6 Essentials" the syntax is
for zip(@a, @b) -> $a, $b {
Which of these is right? (of course, this being Perl, both may be right).
Whichever of these syntaxes is right, what happens when @a and @b are of
different sizes? I can think of three possible behaviors, each with its
potential drawbacks:
1) The loop executes min(+ @a, + @b) times, then finishes successfully.
2) The loop executes min(+ @a, + @b) times, then throws an exception
because the arrays were not of the same size.
3) The loop executes max(+ @a, + @b) times. If @a has fewer elements
than @b, then after @a's elements are exhausted $a is set to undef, and
similarly if @b has fewer elements than @a.
In cases 1) and 2), the problem is how to get the elements of the larger
array that were never iterated over. Case 2) is probably better than case
1), because the exception that is thrown might contain information about
which array was larger and which elements of it have yet to be examined. In
case 3), the problem is differentiating between an undef returned because
the arrays were of different sizes, and an undef returned because one of the
arrays contained an undef.
Joe Gottman
Re: More object stuff
At 4:28 PM + 12/10/03, Harry Jackson wrote: Dan Sugalski wrote: If someone'd like to take a shot at making a nice OO wrapper for Postgres, especially if they'd like to upgrade the postgres interface to 7.4, I would very much appreciate it. It'd be a nice demo, and a good start on a DBI module for us. (And yeah, there's an element of "do my job for me" here. Sorry 'bout that) Could you be more specific. If part of what you want is the following files updated to reflect libpq-7.4 then I am more than willing to do it for you. parrot/library/postgres.declarations parrot/library/postgres.pasm Although I imagine there is more to it than this ;-) Yep, though that's a big part of it. postgres.pasm is generated from postgres.declarations, FWIW--there's a script in the library somewhere. As for the OO wrapper. Are you after a pasm library that takes advantage of objects and hides the details of libpq-fe.h? I think I could start something if no one else has already started anything. Yep, that's what I was thinking of. If you take a look, there are parts of the interface that are somewhat awkward to use from a higher level -- the record fetching code is definitely skewed down to the bottom end of things. Certainly fine enough, but it'd be nice to be able to get back an array or hash for a record rather than having to query individual fields. :) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
More IMCC bugs
A .sub that's prototyped (Dunno about the non-prototyped case) that doesn't have a .pcc_begin_return/.pcc_end_return pair in it (empty is fine) will cause parrot to crash'n'burn. Subs without a designated return should be assumed to return nothing, the same as if an empty begin/end pair was specified. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
IMCC fun 'n goodness. (Or not)
As I write more PIR by hand... *) The function call version of function calls is unprototyped, which is fine (well, OK, I'd prefer it to be prototyped), but it doesn't coerce its parameters to be PMCs. So "foo(10, 20)" pushes two integers, rather than two PMCs, into the overflow array. *) Args go into the overflow array before the PMC registers are filled. Not quite right, registers first *) You can't .pcc_call a sub you've declared with .sub -- you have to create a sub PMC for it. (Though you *can* call a .sub by name with the function call syntax) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[perl #24638] [PATCH] brushup of Getop_Long.imc and getopt_demo.imc
# New Ticket Created by Bernhard Schmalhofer # Please include the string: [perl #24638] # in the subject line of all future correspondence about this issue. # http://rt.perl.org:80/rt3/Ticket/Display.html?id=24638 > This patch mostly improves the embedded POD in Getopt_Long.imc and getopt_demo.imc. There are also some code beautifications, including a s/.pcc_sub/.sub/. Getopt_Long.imc is PIR sample code, that makes a modest attempt to parse 'long style' command line options. -- +++ GMX - die erste Adresse fÃÂr Mail, Message, More +++ Neu: Preissenkung fÃÂr MMS und FreeMMS! http://www.gmx.net getopt_demo.imc.patch Description: Binary data
Re: [CVS ci] object stuff
On Wed, Dec 10, 2003 at 12:26:04PM -0500, Melvin Smith wrote:
> At 12:16 PM 12/10/2003 +, Tim Bunce wrote:
> >*{"Foo\0Bar\0Baz"}->{var};
> >or
> >*{"Foo\0Bar\0Baz\0var"};
> >
> [snip]
> >I think Dan was proposing the first and that's fine.
> >I think the second would be a mistake.
>
>
> Using a character that won't collide with HLL has a disadvantage [...]
I should clarify that I wasn't suggesting \0 itself was good, just the
principle that package names are stored as a single string and the names
of package contents don't include the package name.
I've no strong view about \0 vs other (presumably utf8) byte sequences.
Tim.
Meta-post about perl6-internals (was: object stuff)
>Voting for myself for having the most consecutive posts with bad grammar. > >-Melvin This may be the wrong forum to post this, but it has to be said: the combination of humility, professionalism, and competence in the developers of Parrot is amazing. It is very refreshing and encouraging.
RE: [CVS ci] object stuff
At 11:34 AM 12/10/2003 -0600, Robert Eaglestone wrote: Quoth Melvin Smith: >It be a bit friendlier to make the scope resolution operator something ^^ ACK >that at least 1 or 2 languages use as their own already; then all the rest >still have to mangle. Uh oh, time to vote? Voting for myself for having the most consecutive posts with bad grammar. -Melvin
RE: [CVS ci] object stuff
Quoth Melvin Smith: >It be a bit friendlier to make the scope resolution operator something >that at least 1 or 2 languages use as their own already; then all the rest >still have to mangle. Uh oh, time to vote?
Re: [CVS ci] object stuff
At 12:16 PM 12/10/2003 +, Tim Bunce wrote:
*{"Foo\0Bar\0Baz"}->{var};
or
*{"Foo\0Bar\0Baz\0var"};
[snip]
I think Dan was proposing the first and that's fine.
I think the second would be a mistake.
Using a character that won't collide with HLL has a disadvantage
in the general case:
1) ALL qualfied names (not some) have to be translated/mangled.
What is the benefit, then, if all HLL compilers have to mangle it anyway?
It be a bit friendlier to make the scope resolution operator something
that at least 1 or 2 languages use as their own already; then all the rest
still have to mangle.
Benefits:
-Some languages don't have to translate, so they win.
-Parrot hackers don't have to write 'Foo\0Bar\0Baz'!
-Compiler hackers have enough headaches without worrying about handling
strings with embedded null characters.
-Melvin
PS: I still haven't seen Dan say if he has some other neat cheat trick
in mind for using \0. I can see that it would be pretty fast for tokenizing
Foo\0Bar\0Baz into its components given C strcpy semantics.
Re: [CVS ci] object stuff
At 01:37 AM 12/10/2003 -0700, Luke Palmer wrote:
Dan Sugalski writes:
> At 05:14 PM 12/5/2003 +0100, Leopold Toetsch wrote:
> > set I2, P1["Foo\x00i"] # I1 == I2
> >
> >gets currently the attribute idx (0) of "$Foo::i".
> >Q: Should the assembler mangle the "Foo::i" to "Foo\0i"
>
> I don't like it either, but the alternative is to impose an external
> hierarchic structure. Which we certainly could do, though it may make
> some things more difficult.
>
> I'm more than willing to entertain arguments for and against the
> hierarchic structure, but we're closing in on the point where we fix
> the scheme and don't change it any more.
I'm not sure mangling is a good idea: think about anonymous classes. If
we assign a name to each lexical class, then there are problems when one
instance of a class inherits from another instance of the same class.
That is:
sub make_class(Class $parent) {
return class is $parent {
has $.stuff;
}
}
my $class1 = make_class(Object);
my $class2 = make_class($class1);
So, if you name that lexical class _class_0001 or something,
"_class_0001\0$.stuff" refers to both attributes.
I don't think so. I'm definitely not up to your level regarding Perl6 but I
believe
the example you give translates to:
1st call
return class is Object {
has $.stuff # Object::_class_0001::$stuff
}
2nd call
return class is "_class_0001" {
has $.stuff # Object::_class_0001::_class_0002::$.stuff
}
No collision.
$class2 has 2 $stuffs but at different class scopes.
I'm also not disagreeing, I prefer a hierarchical approach as well but I
need to
take time to formulate a good argument for Dan.
If you generate a name for each instance of a lexical class, you're
setting yourself up for some major runtime cost -- concatenating the
class name to the attribute on each access (or memory cost if you want
to cache).
This is why I don't like the non-hierarchical approach.
There are, of course, disadvantages. It would be slower for cases where
$something::or::other are acessed a lot, as it's three lookups in the
absence of cache. Also, it's not as easy to tell where a symbol table
I think this is a Perl6 problem more than a Parrot problem since no matter
how many optimizations we add to Parrot, Perl6 may or may not be
able to use them due to the dynamic nature it has.
I definitely want to tie namespaces though.
Me 2.
-Melvin
Re: More object stuff
Dan Sugalski wrote: If someone'd like to take a shot at making a nice OO wrapper for Postgres, especially if they'd like to upgrade the postgres interface to 7.4, I would very much appreciate it. It'd be a nice demo, and a good start on a DBI module for us. (And yeah, there's an element of "do my job for me" here. Sorry 'bout that) Could you be more specific. If part of what you want is the following files updated to reflect libpq-7.4 then I am more than willing to do it for you. parrot/library/postgres.declarations parrot/library/postgres.pasm Although I imagine there is more to it than this ;-) As for the OO wrapper. Are you after a pasm library that takes advantage of objects and hides the details of libpq-fe.h? I think I could start something if no one else has already started anything. Harry Jackson (no longer surnameless ;-)
Re: This week's summary
On 2003-12-10 at 15:05:09, The Perl 6 Summarizer wrote: > Oh yes, if you've not been following, "^op" (ie, the vector operators) > has become " >>op<< " which is, if nothing else, a right swine to write > in a POD C<> escape. Eh, >>op<< is just a hack for people who can't type C<»op«>, like ANSI C trigraphs. :) > Nope, still no link shortening. Noticed. Why is that? -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
Re: This week's summary
The Perl 6 Summarizer <[EMAIL PROTECTED]> wrote: > PMC Compiler 2nd edition > ... Melvin wondered if the time had come to replace the > existing ops2c and pmc2c with the newer versions. Leo thought that > pmc2c2 was definitely stable enough, but wasn't too sure about ops2c2. RGWF[1] I was and am sure that ops2c2.pl isn't a problem because it simply doesn't exist. pmc2c.pl will be removed before next release. Thanks again for your concise summaries, leo RGWF ... Running Gag of the Week Followp. That is: our dear summarizer hasn't to mention Leon Brocard any more :)
Re: Symbolic vs Named variable register allocation
>At 03:01 PM 12/3/2003 +0100, Leopold Toetsch wrote: >>Pete Lomax <[EMAIL PROTECTED]> wrote: >> > The following demonstrates that $I1 and .local int i map to the same >> > register in the output pasm code: >> >>Yep. The problem seems to be the backward branch. When you put the >>"test" sub after the "end" op, its working fine. > Just a quick comment inspired by reading the perl 6 summary: As Leo said, it is backward branch. $I1 and $I2 can both get stored in the same register, as can .local int i and .local int j. I'm just pointing out that my subject line was a little misleading. Pete
Re: Some PIR "How do I?" questions
On Mon, 01 Dec 2003 22:28:00 -0500, Melvin Smith <[EMAIL PROTECTED]> wrote: >2) printf/sprintf - we do need it (and implemented in C) since it is a >staple and is the >reasonable hook for HLL implementors to do interpolation without having >to write a special native method or PMC for each language. > Rummaging around /ops/ops.num, I spotted: sprintf_s_s_p 1140 sprintf_s_sc_p 1141 sprintf_p_p_p 1142 (don't recall seeing sprintf mentioned elsewhere) So I tried them (well the first two anyway), and they work. Pete
This week's summary
The Perl 6 summary for the week ending 20031207 Another week, another late summary. Luckily it's been a quiet week so I should get this written faster than usual. As is traditional, we start with perl6-internals Parrot build system tinkering Andy Dougherty and other discussed extending the Parrot build system to allow for building parrot itself outside the main source directory (useful when Parrot's mounted read only via NFS for example. It's not (quite) possible to do this just yet because of a couple of generated files in the IMCC tree. Leo suggested only generating those when "Configure.pl --maintainer" is run, on the grounds that a maintainer shouldn't be building from a read only source. Dan asked for a volunteer to fix things up. http://groups.google.com/[EMAIL PROTECTED] Object stuff I (and others I presume) got ready to do the "Happy! Happy! Joy! Joy!" dance of delight; this was the week that Parrot finally got objects. Or, as Dan described them, 'objects-ish'. Parrot now has single inheritance objects. They're not the final word on the matter, but it's definitely better than a poke in the eye with a sharp stick. Dan went on to discuss what needs to be done with them before we're ready for Parrot 0.1 (Objects are one of the criteria for making a point release). Dan then went rather quiet, apparently because he got mugged by flu, or something like it, and spent the rest of the week wishing he were dead. Meanwhile, Leo lived up to his Patchmonster nickname by checking in a bunch of object related stuff. http://groups.google.com/[EMAIL PROTECTED] -- Rumblings http://groups.google.com/[EMAIL PROTECTED] -- Announcement http://groups.google.com/[EMAIL PROTECTED] -- The way forward http://groups.google.com/[EMAIL PROTECTED] -- Dan gets mugged by flu http://groups.google.com/[EMAIL PROTECTED] -- Leo's patches Raising exceptions Cory Spencer wondered about 'proper exception raising' and wondered what the state of play was, and if there were any good examples. Leo Tötsch pointed him at t/pmc/exception.t http://groups.google.com/groups?selm=Pine.LNX.4.58.0312011749290.13872@ okcomputer.antiflux.org Compilation units and the boundaries of IMCC Pete Lomax had wondered about package/file local variables in IMCC. At the moment IMCC variables can't be file or package scoped, but Melvin Smith is working on it. As he said this, he asked for suggestions for other potential IMCC features. Cory Spencer wanted to be able to write if _some_test() goto LABEL but that was vetoed by Dan (and Melvin) as being rather too high level for an intermediate language that's meant to be a compiler target. http://groups.google.com/[EMAIL PROTECTED] String manipulation Melvin Smith put forward a convincing argument that IMCC shouldn't concern itself with doing string interpolation as the expected behaviour is too 'high level language' dependent, but that Parrot should have a "printf"/"sprintf" equivalent, implemented in C for speed. Dan seemed to agree and reckoned it should be addressed as soon as objects were out of the way. http://groups.google.com/[EMAIL PROTECTED] IMCC pending changes Melvin Smith posted a list of pending IMCC changes, most of which were concerned with tightening up IMCC behaviour (making it both stricter nd more forgiving...). Discussion ensued. A few days later, Melvin committed some of his changes. http://groups.google.com/[EMAIL PROTECTED] http://groups.google.com/[EMAIL PROTECTED] PMC Compiler 2nd edition Leo applied a 'really long pending patch' which should simplify upcoming vtable changes. Melvin wondered if the time had come to replace the existing ops2c and pmc2c with the newer versions. Leo thought that pmc2c2 was definitely stable enough, but wasn't too sure about ops2c2. Jonathan Worthington pointed out a Win32 bug that was quickly fixed. http://groups.google.com/[EMAIL PROTECTED] "get_pmc_keyed()" in PerlString Sterling Hughes noted that, in PHP it's valid to index a string as if it were an array. He wondered it would be possible to implement "get_pmc_keyed()" on the PerlString vtable to allow for similar tricks with the standard string PMC. I'm confused as to what the decision was. I think Leo agreed that it was a good idea, but that it should probably be implemented in a new PMC for the time being... http://groups.google.com/[EMAIL PROTECTED] Symbolic vs. Named variable register allocation Pete Lomax stumbled over a bug in IMCC's register allocation. Melvin thinks the problem is that much of IMCC's flow analysis code doesn't yet know about the Parrot Calling Conventions and went to have a look to see if there was a quick fix available. http://groups.google.com/[EMAIL PRO
Re: Incorrect scoping of constants in IMCC
At 4:40 AM + 12/10/03, Pete Lomax wrote: Can I ask a stupid question? Guess I'm going to anyway... Is there much benefit to .const, over sticking a value in a register and not modifying it? (which is what I've done to get round this) These are the equivalent of C's #define constants, so there's quite a lot of benefit, but it's all in source code abstraction. Not that useful if you're writing a compiler, though, as you can spit out the expanded constant then. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: cvs commit: parrot/config/auto cgoto.pl
At 12:38 PM +0100 12/10/03, Leopold Toetsch wrote: Dan Sugalski <[EMAIL PROTECTED]> wrote: Better handle dependencies for make -j 4 builds. This seems now to force rebuilds forever after opcode changes. Ah, damn. OK, we can back it out. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [CVS ci] object stuff
On Wed, Dec 10, 2003 at 01:37:22AM -0700, Luke Palmer wrote:
>
> I think a heirarchy is a good idea for namespacing in general. I've
> always wanted to be able to tie namespaces in Perl 5. It would only
> make sense that if I tie Foo::, that Foo::anything:: would also go
> through that tie to get the anything:: stash.
That's a good point.
Another related one include any perl code that
manipulates/introspects/iterates over a package.
Package aliasing (something like *{"Bar::"} = \*{"Foo::"}) might
not work well in Perl 5 but I think Perl 6 is meant to be able to
do things along those lines.
But there may be some misunderstanding here (perhaps just on my part :)
Given
package Foo::Bar::Baz;
$var = 1;
In perl5 the var variable is stored something like this (excuse the
probably imprecise syntax, but you'll get the idea):
*{"Foo::"}->{"Bar::"}->{"Baz::"}->{var};
For parrot I'm not sure if Dan was proposing
*{"Foo\0Bar\0Baz"}->{var};
or
*{"Foo\0Bar\0Baz\0var"};
The first just flattens the package name but keeps the contents of
the package as distinct elements within the package 'object'.
The second flattens both the package name and the name of the item
within the package into a single key.
I think Dan was proposing the first and that's fine.
I think the second would be a mistake.
Tim.
Re: cvs commit: parrot/config/auto cgoto.pl
Dan Sugalski <[EMAIL PROTECTED]> wrote: > Better handle dependencies for make -j 4 builds. This seems now to force rebuilds forever after opcode changes. leo
Re: Missing branch instructions?
Dan Sugalski <[EMAIL PROTECTED]> wrote: > Yeah, we need all the comparison operators for PMCs in both numeric > and string versions. I'd like to throw a _str and _num suffix on > them, so we have: >eq_str >lt_num >cmp_str Done. Tests wanted :) leo
Re: [RfC] Testing for null
Dan Sugalski <[EMAIL PROTECTED]> wrote: > Add an isnull branch op: >isnull Px, destination Done. leo
Re: [CVS ci] object stuff
Dan Sugalski writes:
> At 05:14 PM 12/5/2003 +0100, Leopold Toetsch wrote:
> > set I2, P1["Foo\x00i"] # I1 == I2
> >
> >gets currently the attribute idx (0) of "$Foo::i".
> >Q: Should the assembler mangle the "Foo::i" to "Foo\0i"
>
> I don't like it either, but the alternative is to impose an external
> hierarchic structure. Which we certainly could do, though it may make
> some things more difficult.
>
> I'm more than willing to entertain arguments for and against the
> hierarchic structure, but we're closing in on the point where we fix
> the scheme and don't change it any more.
I'm not sure mangling is a good idea: think about anonymous classes. If
we assign a name to each lexical class, then there are problems when one
instance of a class inherits from another instance of the same class.
That is:
sub make_class(Class $parent) {
return class is $parent {
has $.stuff;
}
}
my $class1 = make_class(Object);
my $class2 = make_class($class1);
So, if you name that lexical class _class_0001 or something,
"_class_0001\0$.stuff" refers to both attributes.
If you generate a name for each instance of a lexical class, you're
setting yourself up for some major runtime cost -- concatenating the
class name to the attribute on each access (or memory cost if you want
to cache).
I think a heirarchy is a good idea for namespacing in general. I've
always wanted to be able to tie namespaces in Perl 5. It would only
make sense that if I tie Foo::, that Foo::anything:: would also go
through that tie to get the anything:: stash.
There are, of course, disadvantages. It would be slower for cases where
$something::or::other are acessed a lot, as it's three lookups in the
absence of cache. Also, it's not as easy to tell where a symbol table
entry came from. I don't think either of these are major concerns, but
it depends on our ultimate goals.
I definitely want to tie namespaces though.
Luke
Re: [CVS ci] object stuff
On Dec 9, 2003, at 3:40 PM, Dan Sugalski wrote: At 5:46 PM +0100 12/5/03, Leopold Toetsch wrote: Melvin Smith <[EMAIL PROTECTED]> wrote: At 05:14 PM 12/5/2003 +0100, Leopold Toetsch wrote: set I2, P1["Foo\x00i"] # I1 == I2 gets currently the attribute idx (0) of "$Foo::i". Q: Should the assembler mangle the "Foo::i" to "Foo\0i" Why was this even needed in this example? Since P1 was the class Foo, why do we need scoping here--shouldn't the above just be: set I2, P1["i"] # I1 == I2 Something about this embedded \0 character bugs me. I know its what Dan has in the design doc but it just seems too cryptic. Yeah its ungly. OTOH it should be really transparent for all possible HLLs. And the NUL most certainly is. I don't like it either, but the alternative is to impose an external hierarchic structure. Which we certainly could do, though it may make some things more difficult. I'm more than willing to entertain arguments for and against the hierarchic structure, but we're closing in on the point where we fix the scheme and don't change it any more. I don't see a big advantage of using a null byte over any other character--a null may seem unlikely to conflict with an HLL, but that's just hoping. If we're going to define a syntax, then we may as well make it easy to print out in the debugger, and use "." or ":", and either restrict identifiers to be underscore-letter-number combinations, or define an escaping syntax so that "foo\.bar.baz" means "baz" in the "foo.bar" namespace (ugly, but workable). If we _really_ want these to be strings and reserve some special character, then we should pick something in the Unicode private use area. But either way, I think we need an escaping syntax, so that I can really have a null byte (or whatever) in the middle of something. If we really want to allow the most freedom possible to HLLs, then these should be specified as arrays--no special characters needed. That is, "foo:bar:baz" in Perl code would assemble into an array of "foo", "bar", and "baz" (and "foo.bar.baz" in Java would assemble to the same thing). It would be natural then to store these in nested hashes, but not 100% necessary. I think this is what you meant by a hierarchic structure. It seems straightforward, though with some overhead. We could get around the need for hashes by defining an escaping scheme as mentioned above, but as an internal implementation detail--that is, the API uses arrays, but internally uses strings. Hiding that detail lets us change it later. JEff
