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