> Behaves in ways that will take hours to explain to newbies, and I assure > you it ain't WIM. Not even a little bit.
Hmm. What *I* would mean, anyway, would be that @a gets pushed nine elements: ([1,2,3], 1, 2, 3, [1,2,3], 1, 2, 3, [1,2,3]). And that works under my proposal. But I may have an idiosyncratic idea of WIM. :-)
But I think Dan's right. I think we should just let this drop for now, let Larry take a look at the mess we've gotten ourselves into, and let him decide whether he needs to Rule-2 something or not.
On Tue, Sep 24, 2002 at 11:14:04AM -0400, Aaron Sherman wrote: > Again, we're wading into the waters of over-simplification. Let's try:
> sub foo1(){ my @foo=(1,2,3); return @foo; } > sub foo2(){ my $foo = [1,2,3]; return $foo; } > sub foo3(*@list) { print @list.length, "\n"; } > @foo = (1,2,3); > foo3(@foo, [1,2,3], foo2(), foo1());
> Ok, so what is the output? 12? 10? 8?
> More importantly, why? I could argue the case for each of the above > numbers, but I think 12 is the way it would be right now.
Hrm. I think it must be 8. Since foo3() flattens it's parameters, we get this:
foo3(1, 2, 3, [1,2,3], [1,2,3], 1, 2, 3);
and since the two [1,2,3] are scalar things, we have 8 scalar things in our list. Splat doesn't "look inside" the thing it flattens AFAIK, so it doesn't flatten the two [1,2,3].
> On Tue, Sep 24, 2002 at 11:14:04AM -0400, Aaron Sherman wrote: > > Again, we're wading into the waters of over-simplification. Let's try:
> > sub foo1(){ my @foo=(1,2,3); return @foo; } > > sub foo2(){ my $foo = [1,2,3]; return $foo; } > > sub foo3(*@list) { print @list.length, "\n"; } > > @foo = (1,2,3); > > foo3(@foo, [1,2,3], foo2(), foo1());
> > Ok, so what is the output? 12? 10? 8?
> > More importantly, why? I could argue the case for each of the above > > numbers, but I think 12 is the way it would be right now.
> Hrm. I think it must be 8. Since foo3() flattens it's parameters, we > get this:
> foo3(1, 2, 3, [1,2,3], [1,2,3], 1, 2, 3);
> and since the two [1,2,3] are scalar things, we have 8 scalar things > in our list. Splat doesn't "look inside" the thing it flattens AFAIK, > so it doesn't flatten the two [1,2,3].
On Tue, Sep 24, 2002 at 12:14:10PM -0400, Trey Harris wrote: > In a message dated Tue, 24 Sep 2002, Jonathan Scott Duff writes:
> > On Tue, Sep 24, 2002 at 11:14:04AM -0400, Aaron Sherman wrote: > > > Again, we're wading into the waters of over-simplification. Let's try:
> > > sub foo1(){ my @foo=(1,2,3); return @foo; } > > > sub foo2(){ my $foo = [1,2,3]; return $foo; } > > > sub foo3(*@list) { print @list.length, "\n"; } > > > @foo = (1,2,3); > > > foo3(@foo, [1,2,3], foo2(), foo1());
> > > Ok, so what is the output? 12? 10? 8?
> > > More importantly, why? I could argue the case for each of the above > > > numbers, but I think 12 is the way it would be right now.
> > Hrm. I think it must be 8. Since foo3() flattens it's parameters, we > > get this:
> > foo3(1, 2, 3, [1,2,3], [1,2,3], 1, 2, 3);
> > and since the two [1,2,3] are scalar things, we have 8 scalar things > > in our list. Splat doesn't "look inside" the thing it flattens AFAIK, > > so it doesn't flatten the two [1,2,3].
> The crux of the no-parens for lists discussion has been the idea that in > the current state of affairs, square brackets are a pointless tumor on > the syntax of Perl 6. You don't need them, not ever... almost. You can > do:
> $x = (1,2,(3,4),(5,(6)))
> And everything except for that last C<(6)> will be an anonymous array, > constructed for your viewing pleasure. Of course (again, NOT PROPOSING > ANYTHING, just citing how it is supposed to be now):
> $x = [1,2,[3,4],[5,[6]]]
> Will do what you intended, but now we're keeping brackets on just for > the single-element anonymous array feature, which is one hell of an > impact on the syntax for such a small feature.
Larry's comment about [1,2,3] being mnemonic because we use @a[1] to index arrays was an excellent point. Since [1,2,3] works for both $a = [] and @a = [], maybe we should consider dropping the parenthesis instead of the brackets. (And I was the putz that first suggested that brackets might be superfluous.) Of course, that won't stop commas from creating lists.
> On Tue, 2002-09-24 at 11:07, Trey Harris wrote: > > push @a, (7,3,2);
> > would push the elements 7, 3 and 2 to the end of @a, but
> > push @a, [7,3,2];
> > would push a single element containing the arrayref [7,3,2] onto the end > > of @a.
From reading the apocalypses, I think Larry, et al, are aware of this, and I fully expect the situation to be clarified when the next apocalypse comes out. Maybe we should have a pool for the release date? :)
> That doesn't really work. Because now you introduce the case where:
> Behaves in ways that will take hours to explain to newbies, and I assure > you it ain't WIM. Not even a little bit.
The parenthesis have no effect because they are only grouping. So the only question in my mind is whether @y gets flattened or is treated as a single object. In either case, we can clarify our meaning by writing *@y to force flattening or \@y to prevent flattening.
It seems that the fundamental problem is the dichotomy between a scalar, and a list of 1 elem. Thus, we want
$a = 7
to DWIM, whether I mean a list, or a scalar. Seems to me that the best way to solve a dichotomy is to declare it to not to be one: a scalar *IS* a list of one element. The only thing that needs to go is the inappropriate casting in numeric context.
This leads to a second clarification, which has bothered me wrt perl6: the purpose of sigils. If everything is an object, and objects are $ things, then why have sigils? I think the answer is that the sigil defines the default interface ("skin"?) on an object. So,
$a = 7; @a = 7;
both create identical objects; but the interface to these objects is different. so +$a == 7, while +@a is 1.
Next:
$b = 7, 6, 5 @b = 7, 6, 5
Again, both create identical objects, under different interfaces. But now we have a problem with +$b: what should this mean? To be consistant with +$a (above), I would suggest that it simply returns the sum of its elements (i.e. +(1,2,3) == 6).
On Tue, Sep 24, 2002 at 11:47:16AM -0700, David Whipp wrote: > It seems that the fundamental problem is the dichotomy between > a scalar, and a list of 1 elem. Thus, we want
> $a = 7
> to DWIM, whether I mean a list, or a scalar. Seems to me that > the best way to solve a dichotomy is to declare it to not to > be one: a scalar *IS* a list of one element. The only thing > that needs to go is the inappropriate casting in numeric > context.
So you're saying that +$a == 7 is inappropriate and it should be +$a == 1? (since lists in numeric context yield their length)
Or are you saying that lists in numeric context should NOT yield their length but rather the programmer must type @a.length to get that?
> I think the > answer is that the sigil defines the default interface > ("skin"?) on an object. So,
> $a = 7; > @a = 7;
> both create identical objects; but the interface to these > objects is different. so +$a == 7, while +@a is 1.
Okay ...
> Next:
> $b = 7, 6, 5 > @b = 7, 6, 5
> Again, both create identical objects, under different > interfaces. But now we have a problem with +$b: what should > this mean? To be consistant with +$a (above), I would > suggest that it simply returns the sum of its elements > (i.e. +(1,2,3) == 6).
Makes no sense to me.
if $b and @b are identical objects then what kind of objects are they? Are the commas list constructors? If so, then why wouldn't +$b == 3?
$a = 10; $b = 7,6,5; $c = $a + $b; # what happens here? Is $c == 28?
Anyway, this is most bizarre. My little perl 5 brain can't intuit.
On Tue, 2002-09-24 at 14:47, David Whipp wrote: > It seems that the fundamental problem is the dichotomy between > a scalar, and a list of 1 elem. Thus, we want
After the first couple of messages, that was really no longer *my* concern, but I can't speak for others. My concern was mostly that parentheses and brackets are now doing exactly the same thing with some very limited non-intersection around single-element lists. So my question was: why would we want that? Why would anyone ever need to have this in their code: C<(1,[2,(3,[4,(5,6),7],8),9],0xa)>.
But, I'm quite content to wait for Larry to get back and have a chance to mull all of this over. He tends to have a very level head about these things, and I imagine he'll have a point of view colored by some concerns he has not yet put into writing.
For what it's worth, I once started working on a cut-down, general-purpose-only version of Perl that I was calling Sand. The interesting thing was that I made a lot of these same decisions, but I went even further. There was no array or hash type at all. They could only be manipulated by reference through anonymous structures or scalar variables. I rat-holed on the topic of how to pass parameters without throwing away the benefit of Perl's sloppy-list-based stack that was always so useful. A lot of these "why do I need parens" and "how do you explode a list when you want, but not when you don't" sorts of issues kept coming up, and I just didn't have time to explore them.
Now that Perl 6 is starting to take shape, I may go back and finish Sand as a Parrot front-end (though it was ultimately aimed at being purely compiled like C).
In a message dated Tue, 24 Sep 2002, Mike Lambert writes:
> Consider: > $a = (1); > and > ($a) = (1);
Yes? They both do the same thing--set $a to 1. It looks like the bottom one is a list assigned to a list, but that might be optimized out, as it doesn't matter.
> > 5. Assignment to arrays and lists.
> > $a = (1, 2, 3); # Same as Perl 5's $a = [1,2,3];
> $a = (1) should then do $a = [1], according to the above.
I most definitely did not write that. Did you read my conclusion? One-tuples are special and can't be created simply with round parens.
> This implies that:
> ($a) = (1) implies that $a is [1], something I don't particularly agree > with.
Once again, did you read my conclusion? One-tuples are special.
> How would you resolve this contradiction you've created? (Or do you think > the last example is perfectly fine?)
No contradiction. One-tuples are special.
> What about: > $a = 1,2,3
I don't know. I think Larry must adjudicate.
> ($a) = (1,2,3)
$a gets 1, I think. Otherwise you can't do list assignment where you throw away the trailing elements, which is a very common and useful thing to do in Perl 5. Losing that ability in Perl 6 would be a great loss.
> $a = (1,2,3)
By definition, according to Larry, $a is [1,2,3].
> ($a) = 1,2,3
Same as without the parens. Larry must decide.
> Do you still believe those should be identical? They have the same > problems mentioned above, and likely other issues as well.
Oh, wait, I think I see where you're going. You didn't read the whole thread to date before responding. I later quoted my own text there and said that arbitrary X was not what I meant. I meant a single scalar item, such as 7, but I changed it to X in an effort to be general without considering what that meant. My mistake.
> From: Jonathan Scott Duff > > $b = 7, 6, 5 > > @b = 7, 6, 5
> > Again, both create identical objects, under different > > interfaces. But now we have a problem with +$b: what should > > this mean? To be consistant with +$a (above), I would > > suggest that it simply returns the sum of its elements > > (i.e. +(1,2,3) == 6).
> Makes no sense to me.
> if $b and @b are identical objects then what kind of objects are they? > Are the commas list constructors? If so, then why wouldn't +$b == 3?
> Anyway, this is most bizarre. My little perl 5 brain can't intuit.
$a and @a are not objects, they are variables. Variables provide access to objects. $a and @a are different kinds of variables: when you view an object though a $ variable, it DWIMs like a scalar; when you view it through an @ variable, it DWIMs like a list. In numeric context, a $ variable obtains its value via a .NUMBER method. In the same context, an @ variable uses the .LENGTH method
In both caes, the underlying object would have both .NUMBER and ..LENGTH methods. The only difference would be that the sigil defines different mappings between the calling context, and the method that returns the value.
And thinking about your example, above, the value of $a + $b is probably 10; for the same reason as 3+"foo" is 3. If you're using -w then, of course, you also get the warning that "argument [7,6,5] is not numeric in add at ...".
As others have said, we need Larry to look at all the various issues and proposals ... and then to chop the baby in half.
> > $a = (1, 2, 3); # Same as Perl 5's $a = [1,2,3];
> $a = (1) should then do $a = [1], according to the above.
> This implies that:
> ($a) = (1) implies that $a is [1], something I don't particularly agree > with.
You may be missing the change in the comma operator. Perl5 uses the "return the rightmost value" comma from C. Perl6 is changing the comma to a "list constructor". So (1,2,3) is definitely a list, but (4) probably isn't.
If I understand our non-conclusions so far, we're waiting for Larry to clarify:
1) how to create a 1-tuple/1-item list?
2) how to interpret the flattened list context? e.g. given this:
> What flattens, what doesn't, and how do you override the behavior?
Mostly I'm interested in the fact that () and [] now do exactly the same thing, except that Perl 6 ()s can't create one-element lists. Given that, ()s are just being wasted, syntacticly speaking, on backward compatibility with Perl 5. I'd like to know if there's any chance of our breaking with that backward compatibility.
Once again, just waiting for Larry to come back. I'm not really very interested in pursuing this debate further until I find out what caveats he may already be planning on introducing.
Once that's in place, I have a whole slew of questions regarding []s that I think people will find interesting.
On Mon, Sep 23, 2002 at 11:54:06PM -0600, John Williams wrote: > After testing various cases of x, I came up with one that I cannot > explain. Can someone tell me what is happening here (in perl5)?
> $ perl -le 'print "@{[ $a = ('a','b') x 3 ]}"; print $a' > a bbb > bbb
> or in other words, after evaluating "@a = $a = ('a','b') x 3", > $a is 'bbb' and @a is ('a','bbb') !
Aaron Sherman wrote: > On Sat, 2002-09-21 at 06:38, Smylers wrote:
> > ... lists now use square brackets.
> I don't disagree that this is a good thing, but let's look at some > cases that might not look the way you had intended: <Snip>
Oh, I hadn't really intending anything. Starting from what Larry said about parens creating array refs, I ended up with the evil thought about square brackets just being for precedence.
Realizing that doing this t'other way round might actually be sensible was very much an afterthought. I posted it knowing that I'd be away for a week, and without even attempting to think through all the consequences.
> Thoughts?
Fortunately by the time I got back online I find that Luke Palmer has created a very sensible RFC based on my suggestion. He's obviously done more thinking about this than I had, so I don't think there's any point in me adding anything.
Luke Palmer wrote: > On 21 Sep 2002, Smylers wrote:
> > But because C<$num> _might_ be used as an array ref, the data has to > > be kept around, which is wasteful.
> The programmer should know whether it would or wouldn't,
Oh, I wasn't doubting that. I was just concerned that if the 'typical' way of determining the size of an array remains as it is in Perl 5 then a programmer could unwittingly be keeping superfluous data around.
> so he could put + or not.
Fair enough. It would probably be good style always to include the C<+> when only the size is required; just doing this when otherwise would leave an array in memory would be too subtle.
