At 04:02 PM 8/11/00 -0400, Karl Glazebrook wrote:
>Dan Sugalski wrote:
> >
> > At 07:57 AM 8/11/00 +1000, Jeremy Howard wrote:
> > >Dan Sugalski wrote:
> > > > Strong typing and sparse arrays are orthogonal--no reason we
> shouldn't use
> > > > them if someone does:
> > > >
> > > > $foo[time]
> > > >
> > > > or something of the sort. (People like huge arrays with few scalars in
> > > > them too... :)
> > > >
> > >Good point. It also occurs to me that we would want some syntax to say
> > >"Don't make this sparse". That way, arrays that are, for example, read
> from
> > >a file, could be stored contiguously and can be accessed without
> traversing
> > >extra pointers.
> >
> > I dunno. If someone tells perl an array's sparse, I'd tend to believe they
> > knew what they were doing. Wouldn't hurt to have some sort of debugging
> > analysis messages that's notice you declared an array sparse but it really
> > wasn't, but...
>
>
>It sounds like we are after something like
>
>my compact sparse @a;
>
>If we are going to have @a * @b are we also going to be able to do
>return (@a, @b) and not have them splattered into one list?
>
>i.e. implicit references everywhere
I'm thinking instead of proposing that lists become first-class data
elements themselves, lazily evaluated. That way we don't flatten until
someone actually references the list, which makes returns cheaper too. In
this case we'd push two array markers on the stack, so if the outer code was:
($foo, $bar) = whatever();
and whatever() returned two arrays of a thousand elements each, we wouldn't
bother pushing 1998 worthless elements on the stack...
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
