Simon Cozens wrote:
>
> =head2 Implementation Language
>
> C++ gives us OO and headaches, is wildly non-portable due to a lack of
> decent implementations, and we don't have enough experience of it. C's
> portable and everyone knows it, but it's a swine for doing OO things.
Don't forget we can mix-and-match C/C++ to some degree, so it's not
necessarily an either/or choice.
> =head2 Variable Storage
>
> AVs - can we do anything better than an array of pointers?
>
> HVs - a hash is a hash is a hash, so fundamentally there's little
> we can do with HVs.
One caveat is something that's been discussed somewhat, and that is the
ability to do this:
@array->length
%hash->keys
Simply keeping @arrays and %hashes as buckets for SV's wouldn't let you
do this. Conversely, the overhead required to maintain SV-like AV/HV's
may kill any potential benefits. Regardless, if we want that
functionality it could impact the design considerably.
This is perhaps one worthwhile argument for at least combining arrays
and scalars into a single "highlander" type. No, I'm not a wholehearted
supporter of that position by any means, but it would solve lots and
lots of problems with context. An "SV" would really just be an AV with
one value. HV's would remain separate since there's more to them (direct
access, etc) than just multiple values. Again, just something worth
tossing around.
> Let's also not forget that we need to provide a method of allowing
> user-defined data types. How does this fit in with the vtable model? Do
> we expect people to provide functions to fit a variable API - if so, we
> need to define that API - or do we allow inheritance from a base
> data type? Is this the sort of thing that's likely to replace ties?
I would hope so. :-) This brings up the whole hairy issue of how
fundamental we can make overloading and inheritance. For example, I
think it would be cool if all stringification was simply:
$some_sv_thingy->STRING;
And the CORE/UNIVERSAL/whatever STRING was just:
sub STRING { return $self->VALUE }
or something like that. So, rather than having to make decisions and
look for methods (like the "magic" - pardon the pun - of tie currently),
STRING could just be called, whatever that STRING was. The same concept
can be applied to ADD for addition, etc. Time permitting, I've been
digging through Python and there are some things Perl could potentially
steal in this area.
> =head2 Symbol Table Handler
>
> One thing that needs careful thought is the way Perl-side variables are
> stored; global variables can be easily dealt with by putting them into a
> hash, which is exactly what happens right now. Lexical variables are
> more tricky, and dynamic variables with C<local> make the situation very
> difficult indeed. Is there a better symbol handling model for lexical
> and dynamic variables?
It's probably worth discussing the "typeglobs must die" issue here as
well (even though I like them :-).
-Nate
