Re: The distinction between "do BLOCK while COND" and "EXPR while COND" should go

>>>>> "TC" == Tom Christiansen <[email protected]> writes:

TC> Oh.  You want lists to act like arrays.  That's a very big change.

Do you have any objection? The intended avoidance of flattening to as
late as possible might have that effect.

>> You are letting the scalar context of the caller to bleed through the return
>> and effect the _syntatic_ meaning of the comma.

TC> So what?  

I just find it jarring. If scalar fn( (1,2,3) ) doesn't make the comma
into the comma operator, (This one is galling) nor does 

	sub fn {scalar(return (1,2,3)) }

why should $x = fn() do the same?

TC>     return @ENV{HOME,USER,TERM};

TC> had jolly well not be returning 3.  I'm returning a LIST, dang it.
TC> I don't ever expect a list to be an array.  Try popping it, for
TC> example.

You are confusing me. In perl5 can a routine return an array? So
what is the difference?

	@a = @ENV{HOME,USER,TERM};
	return @a

It still can't be popped. Please tell me what we lose by throwing away
the distinction between lists and arrays? Why not simply make them,
for perl6, into an anonymous array?

Any reason	$foo = pop fn	Shouldn't be valid?
Then perhaps
	@foo = unshift(fn, 12)
might also become reasonable.

TC> Yes, I object.

TC> The comma is NOT changed.  It's doing exactly what a list does.
TC> It never returned an array.  You now want (1,2,3) to be an array!!

Then please explain why scalar(return (1,2,3)) doesn't do what at first
glance it seems it should.

And for the life of me I can't see how
	$x=(1,2, (3,4,fn,6) )	
fn ends up in scalar context.

I'm able to accept that $x=(...) has the inside of the parenthesis in
a scalar context . But with $x=(...., (....), ...), why shouldn't the
nested set of parenthesis make its insides into a list.

Perhaps that's my block. For me the return takes away the thrust of the
outside scalar context.

<chaim>
-- 
Chaim Frenkel					     Nonlinear Knowledge, Inc.
[email protected]				               +1-718-236-0183