On Fri, Feb 14, 2003 at 10:10:09PM -0700, Luke Palmer wrote:
> > 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.
Fair enough, and probably the best course. I just want to bring up an
alternative, so that we don't all get "trapped in the box." After
all, the point of a greenfield rewrite is that you can question
things. :>
> > 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.
Good point. But, I'm still not clear on what functionality lists have
that arrays don't. If the abilities of a list are a subset of those
of an array, why not make parameters lists be parameter arrays instead?
< idea type="wildly blue sky" >
What if functions/methods did not take parameter C<lists>? What if,
instead, they took parameter B<arrays>?
Could you modify them at runtime? Might there be some way to get
access to the function/method's body at runtime and rewrite it so as
to make it aware of your new parameter?
This might be a very bad idea...it could lead to ugly, nasty
spaghetti hacks everywhere. On the other hand...code that modifies
code is a powerful technique. You could use this to optimize code
while it was running, without having to reload the entire program
and lose state. I know it's possible, in P5, to replace a
function/method by assigning a code ref to the package symbol table,
but there is no way (that I know of) to actually retrieve the code
that generated the current version of a particular method, rewrite
it, eval it, and then reinsert it into the stash.
Ok, I'll come back to earth now.
< /idea >
> Also, don't worry about implementation. That's p6i's job.
Fair enough. :>
> > 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.
I can see five possible courses here:
1) We decide that my suggestion is a bad one and do nothing with it.
That's fine; I am not wedded to it, I just thought it was an
interesting idea that I wanted to raise.
2) (4, 1, 2) + 7 returns (9). This is C comma behavior, and I always
found it incredibly non-intuitive. I'd really like to get away
from this, even if it means that this expression is a fatal error
"Can't add scalar to list".
3) (4, 1, 2) + 7 returns (10), by adding 7 to the length of the list.
This makes lists look even more like arrays, and doesn't really add
any new power to the language.
4) (4, 1, 2) + 7 returns (11, 8, 9). This is a convenient shorthand
for the vector syntax, IMO.
5) (4, 1, 2) + 7 returns (14). That is, the list is collapsed into a
datatype matching the "RHS" by iteratively applying the operator in
question to the list elements, and then the item on the RHS of the
operator is applied. I'm not sure this is useful; I'm just
exploring options.
This would mean that:
$foo = 'frob';
$bar = 'jaz';
@a = (1,2,3);
@b = ($foo,$bar);
@c = (@a, $foo);
(1, 2, 3) + 7; # returns 13
($foo, 1,2) _ $bar # returns 'frob12jaz'
(@a, @b) * @a; # returns [18] #array ref containing 18
($foo, @a) . print; # returns @{[$foo, @a]}.map({print});
Actually, maybe this is useful. Really what this means is that,
the result depends on what is to the right of the operator:
if it's a datatype, then it gets pushed onto the list (I know
you can't push onto an array; I'm talking conceptually), and
then the operator is vectored across all elements.
if it's a method/funtion, then it's mapped across all elements.
The result is that the first option is a shorthand for summation,
the second a shorthand for C<join>, the third a shorthand for
vector op, and the fourth is a shorthand for map.
> 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.
Wouldn't that need to be:
@a = (4, 1, 2) >>*+<< 7
or have I misunderstood something about vector ops?
--Dks
