develooper Front page | perl.perl6.internals | Postings from February 2001

Re: PDD 2, vtables

Thread Previous | Thread Next
Dan Sugalski
February 6, 2001 11:14
Re: PDD 2, vtables
Message ID:
At 05:01 PM 2/6/2001 -0200, Branden wrote:
>Dan Sugalski wrote:
> > At 11:26 AM 2/6/2001 +0000, Tim Bunce wrote:
> > >Arrays and hashes should probably be at least mentioned here.
> >
> > And lists, yes. Or they need their own PDD with details.
> >
>What's the difference between array and list? How is a list currently
>(Perl5) implemented? Which operations does it support?

I'll leave this as an exercise for the reader. (Which is a polite way to 
say "go find out, grasshopper" :)

> > > > =item UTF-32 string
> > > > =item Native string
> > > > =item Foreign string
> > >
> > >I'm a little surprised not to see UTF-8 there, but since I'm also
> > >confused about what Native string and Foreign string are I'll skip it.
> > >Except to say that some clarification here may help, and explicitly
> > >mentioning UTF-8 (even to say it won't be a core type and provide a
> > >reference to why) would be good.
> >
> > I didn't put UTF-8 in on purpose, because I'd just as soon not deal with
> > internally. Variable length character data's a pain in the butt, and if we
> > can avoid having the internals deal with it except as a source that gets
> > converted to UTF-32, that's fine with me.
> >
>I would bother a lot, having my strings occupying 4x more memory than they
>do now... For me, at least, UTF32 can be set aside, while UTF8 is a need
>nowadays (damn XML!).

It's a speed/space tradeoff. Dealing with the middle of a string with 
variable-length characters either requires an offset array (in which case 
you've just used more memory and time than a fixed-width representation) or 
scanning from the beginning of the array, which can be costly if you need 
to go too far in. (How costly depends on the architecture. Dealing with 
arrays of 8-bit ints is actually slower on the Alpha than the same size 
(element count, not bytecount) array of 32-bit ints. YMMV, though)

> > > > =item match
> > > >
> > > >    void               match(PMC1, PMC2, REGEX[, key]);
> > > >
> > > > Performs a regular expression match on C<PMC2> against the expression
> > > > C<REGEX>, placing the results in C<PMC1>.
> > >
> > >Results, plural => container => array or hash. Needs clarifying.
> >
> > Yep, especially since I'd considered tossing the match destination
> > entirely. (Though that means special variables, and I'm not sure I want to
> > go there) It'll likely just return true or false. I'll rethink it.
> >
>Will Perl 6 still be based on a stack, to pass a list of parameters and
>return a list of results to the subs? Or is there any other approach
>discussed for it? Is it still undefined? Will it work the same as in Perl 5
>or will it take changes? Too soon to talk about it?

We'll probably pass lists in and out, but it'll have a stack of 
sorts--that's pretty much a requirement for Algol-based languages.


--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai                         have teddy bears and even
                                      teddy bears get drunk

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About