> Date: Fri, 14 Feb 2003 12:38:59 -0800
> From: David Storrs <[EMAIL PROTECTED]>
>
> Some random musings, for what they're worth...
>
> 1) The fact that we've had this long thread about arrays and shows
> that they are confusing. How could we change the
> functionality/eliminate the differences so as to simplify things?
It seems that what we need to do is come up with a simple
explanation/analogy that describes each. In our minds as it stands,
it indeed is confusing.
> 2) It seems that the functionality of lists is a proper subset of the
> functionality of arrays. If this is the case and I'm not just
> missing something, we might want to at least consider some way to
> eliminate lists as a separate data type.
>
> 2a) What would be the costs (performance and otherwise) of eliminating
> lists and just having people use anonymous array composers where
> they would normally use a list? How much more expensive is it to
> allocate an array on the heap than an equivalent list on the
> stack?
This has been previously discussed in another guise. The distinction
between lists and arrays is important, and I think it is necessary to
have both in the language.
If we don't have lists, what does unary * do? Right now, it flattens
an array into a I<list>, which is why you can use it to fill in
multiple arguments in a parameter I<list>. Without them, we have to
make special cases for all these behaviors, which surely isn't a good
idea.
Also, don't worry about implementation. That's p6i's job.
> 3) More interesting than eliminating lists would be to distinguish
> them...to give them a "special power" of their own. My suggestion
> would be to make lists behave as a shortcut for mapping over their
> elements. Therefore:
>
> (@a, @b, @c).pop();
> # same as @{[@a, @b, @c]}.map({pop})
>
> %z = (@a, @b, @c).{$_[0] => $_};
> # same as @z = @{[@a, @b, @c]}.map({$_[0] => $_});
This is an interesting concept... although, we already have vector
syntax. Is it really worth it to make implicit what was already clear
explicitly? The real question is, if they don't auto-vector, what
I<does> this do:
@a = (4, 1, 2) + 7;
@a could be (9) or (10), maybe even (\(4,1,2)+7), but hopefully not.
Perhaps we should keep the C comma, and have \@a be (9) in this case.
This is justified by + putting the list into numeric context, which is
a derivative of scalar context. If we want @a to be (11, 8, 9),
@a = (4, 1, 2) ≫+≪ 7
will do.
Luke
