Re: RFC: [] as the solitary list constructor

2002-10-09 Thread Mark J. Reed

On 2002-10-08 at 17:15:06, Larry Wall wrote:
 Seriously, () is just a special token.  We could easily have used a
 special token like NULLLIST instead.  What does INTERCAL use?
Well, INTERCAL doesn't have lists per se, but it does have arrays, whose
size is set by assignment: the lvalue is the name of the entire array,
and the rvalue is the size.  So if you wanted an empty array you'd set it
up with something like this:

PLEASE DO ;1 - #0

(Hey, you asked.)

-- 
Mark REED| CNN Internet Technology
1 CNN Center Rm SW0831G  | [EMAIL PROTECTED]
Atlanta, GA 30348  USA   | +1 404 827 4754 
--
It is not enough to have great qualities, we should also have the
management of them.
-- La Rochefoucauld



Re: RFC: [] as the solitary list constructor

2002-10-08 Thread Larry Wall

On 6 Oct 2002, Smylers wrote:
: Do parens still provide list context on the left side of an assignment?

Er, kind of.  More precisely, use of parens on the left provides a
flattening list context on the right side, just as in Perl 5.  I guess
I did not make clear that a basic Perl 6 design decision was that = will
appear to work exactly as it does in Perl 5, while all the new semantics
get put into := instead.  In fact, = doesn't work exactly the same, because
it lazily evaluates things like ranges and other potentially infinite lists.
But that should be more or less transparent.

Larry




Re: RFC: [] as the solitary list constructor

2002-10-08 Thread Larry Wall

On Sun, 6 Oct 2002, Trey Harris wrote:
: In a message dated Sun, 6 Oct 2002, Noah White writes:
:  On Sunday, October 6, 2002, at 01:50  AM, Brent Dax wrote:
: 
:   Parens don't construct lists EVER!  They only group elements
:   syntactically.  One common use of parens is to surround a
:   comma-separated list, but the *commas* are creating the list, *not* the
:   parens!
:  
: 
:  Following this rule would mean that
: 
:$a = ();  # $a is a list reference with 0 elements
: 
:  should not be a list reference at all and would appear inconsistent.
: 
: No, because there are zero commas.  Squint and you can see them. :-)

Actually, () has -1 commas, which is why it's not ambiguous.  Rather,
it's ($x) that has zero commas, so it's naturally ambiguous, and thus
must depend on context to determine whether to produce a scalar or
a list value.

Seriously, () is just a special token.  We could easily have used a
special token like NULLLIST instead.  What does INTERCAL use?

Larry




Re: RFC: [] as the solitary list constructor

2002-10-08 Thread Larry Wall

On Sat, 5 Oct 2002, Chip Salzenberg wrote:
: According to Larry Wall:
:  I suppose we could make comma merely puke in scalar context rather
:  than DWIM, at least optionally.
: 
: I rather like Perl 5's scalar comma operator.

Most of the uses of which are actually in void context, where it
doesn't matter if we technically build a list and throw it away,
or throw away all but the last value, then throw that one away too.
Which is why it got decided the way it was.  If you really want the
last value, you can always use

(LIST)[-1]

which could be construed as better documentation.  Admittedly it's
not quite the same, since LIST is evaluated in list context.

Anyway, if we did outlaw comma in scalar context, it would not apply
to void context, or we couldn't write:

loop ($a=0, $b=1; $c; $a++, $b++) { ... }

:  :   $a = ();# $a is a list reference with 0 elements
:  :   $a = (10);  # $a is the scalar 10
:  :   $a = (10, 20);  # $a is a list reference with 2 elements
:  
:  I don't think that's an important inconsistency.
: 
: What if $a and $b are both array refs, and maintenance programmer
: changes:
: for $a, $b { print }
: to:
: for $a { print }
: Will that end up iterating across $a?  The equivalent of that gotcha
: was forever bugging me in Python (gack).

No, in list context reference scalars must still be explicitly
dereferenced.  The $ on the front still means something occasionally.
It's only in scalar contexts that $ can be autodereffed as an array
now, so that someone can say

push $a, list;

But if you say

push $a, $a;

you get the ref in $a pushed onto $a, as it currently stands.

Larry




Re: RFC: [] as the solitary list constructor

2002-10-08 Thread Chip Salzenberg

According to Larry Wall:
 On Sat, 5 Oct 2002, Chip Salzenberg wrote:
 : I rather like Perl 5's scalar comma operator.
 
 Most of the uses of which are actually in void context [...]

I didn't realize you were distinguishing scalar from void in this, uh,
context.  I agree that scalar comma is expendable if void comma can be
rescued.  However:

 ... where it doesn't matter if we technically build a list and throw
 it away, or throw away all but the last value, then throw that one
 away too.

Except that it would impose list context on the values; and if the
values to be thrown away are no longer in void context, unnecessary
work may be done to evaluate them fully.  This is a bad thing.

(Or are you rescinding the rule that void context is a special kind of
scalar context?)

 If you really want the last value, you can always use
 (LIST)[-1]

If scalar comma goes away, I'd be inclined to replace it with

do { E1; E2; E3 }

which evaluates E1 and E2 in void context.
-- 
Chip Salzenberg - a.k.a.  -[EMAIL PROTECTED]
 It furthers one to have somewhere to go.



Re: RFC: [] as the solitary list constructor

2002-10-06 Thread Trey Harris

In a message dated Sun, 6 Oct 2002, Noah White writes:


 On Sunday, October 6, 2002, at 01:50  AM, Brent Dax wrote:

  Parens don't construct lists EVER!  They only group elements
  syntactically.  One common use of parens is to surround a
  comma-separated list, but the *commas* are creating the list, *not* the
  parens!
 

 Following this rule would mean that

   $a = ();# $a is a list reference with 0 elements

 should not be a list reference at all and would appear inconsistent.

No, because there are zero commas.  Squint and you can see them. :-)

Trey




Re: RFC: [] as the solitary list constructor

2002-10-06 Thread Smylers

Larry Wall wrote:

 Parens don't construct lists in Perl 6.  They merely group.
 The only difference from Perl 5 is that if they happen to group a
 comma in scalar context, the comma acts differently, not the parens.

Do parens still provide list context on the left side of an assignment?
What do these two do:

  my $x = ARGS;
  my ($y) = ARGS;

Parens just grouping suggests that C$x and C$y should be the same
(which may well be good, as it's a subtle distinction which trips up
many beginners in Perl 5).  If so, what's the preferred way of getting
the 'other' behaviour?

Smylers



Re: RFC: [] as the solitary list constructor

2002-10-06 Thread Luke Palmer

 Do parens still provide list context on the left side of an assignment?
 What do these two do:

   my $x = ARGS;
   my ($y) = ARGS;

 Parens just grouping suggests that C$x and C$y should be the same
 (which may well be good, as it's a subtle distinction which trips up
 many beginners in Perl 5).  If so, what's the preferred way of getting
 the 'other' behaviour?

Maybe:?

my ($y) ^= ARGS;

Luke




Re: RFC: [] as the solitary list constructor

2002-10-06 Thread Smylers

Luke Palmer wrote:

my $x = ARGS;
my ($y) = ARGS;
 
 Maybe:?
 
   my ($y) ^= ARGS;

Or (presumably equivalently):

  my $y ^= ARGS;

But that's horrible.  Presumably with two or more variables the comma
would denote list context, so the caret is only needed for exactly one
variable.  That's an awkward special-case to have to introduce.

Though thinking about this more, it may not be too much of a problem.  A
main use of this in Perl 5 is with C_.  Since Perl 6 will have named
sub params this will be much less common and may not be something to
worry about.

Smylers



Re: RFC: [] as the solitary list constructor

2002-10-06 Thread Glenn Linderman

Larry Wall wrote:

I cringe every time someone says Parens construct lists in Perl 6.
Parens don't construct lists in Perl 6.

: Additionally, parentheses have one inconsistency which brackets do not:
: This is the following case, already shown on perl6-language:
: 
:  $a = ();# $a is a list reference with 0 elements
:  $a = (10);  # $a is the scalar 10
:  $a = (10, 20);  # $a is a list reference with 2 elements
:  # ...
: 
: If the ability to construct lists with parentheses is removed, so is this 
: inconsistency.

I don't think that's an important inconsistency.
  

So is it even true that

 $a = ();  # is this really a list reference with 0 elements?  Or is 
this just undef?  There is no comma...

-- 
Glenn
=
Not everything that is counted counts,
and not everything that counts can be counted.
 -- A. Einstein







Re: RFC: [] as the solitary list constructor

2002-10-06 Thread John Williams

On Sun, 6 Oct 2002, Luke Palmer wrote:

  Do parens still provide list context on the left side of an assignment?
  What do these two do:
 
my $x = ARGS;
my ($y) = ARGS;
 
  Parens just grouping suggests that C$x and C$y should be the same
  (which may well be good, as it's a subtle distinction which trips up
  many beginners in Perl 5).  If so, what's the preferred way of getting
  the 'other' behaviour?
 
 Maybe:?
 
   my ($y) ^= ARGS;

That's like saying 
$y = ARGS[$_] for 0..+@ARGS;
so $y will probably end up with the _last_ element of ARGS.

I suggest:

my $y = shift;   # if this still works in perl6
my $y = ARGS[0];

~ John Williams





Re: RFC: [] as the solitary list constructor

2002-10-05 Thread Larry Wall

On Tue, 24 Sep 2002, Luke Palmer wrote:
: =head1 TITLE
: 
: Square brackets are the only list constructor
: 
: =head1 VERSION
: 
:   Maintainer: Luke Palmer [EMAIL PROTECTED]
:   Date: 24 Sep 2002
:   Number: 362 (?)
:   Version: 1
: 
: =head1 ABSTRACT
: 
: This RFC responds to the fury on perl6-language about the redundancy of 
: parentheses and brackets with respect to list construction.  It proposes 
: that only brackets may be used to create lists (or arrays), and 
: parentheses be left for grouping.
: 
: =head1 DESCRIPTION
: 
: Because of the addition of the flattening operator, parentheses in Perl 6, 
: when used as list constructors, are entirely redundant with brackets. 

I cringe every time someone says Parens construct lists in Perl 6.
Parens don't construct lists in Perl 6.  They merely group.  The only
difference from Perl 5 is that if they happen to group a comma in
scalar context, the comma acts differently, not the parens.  But the
comma acts differently whether or not there are parens.  It depends
only on the context.  I admit that it's difficult to get a comma into
scalar context without parens, at least with the current precedence
table.  But if we swapped the precedence of comma and assignment,
it would still be the case that

$a = 1,2,3;

generates a list because of the comma.  The grouping would be implicit.
(But there are other problems with doing that.)

You can actually do the grouping without parens:

$foo = do { 1,2,3 };

Gee, maybe we should get rid of parens, since they're redundant.   :-)

So the parens have little to do with the list construction.  It's all
the comma's fault.

And in general, parentheses should not be used to construct lists in
scalar context.  It's better to use [] explicitly.  In list context,
the [] is not at all the same as (), because () is essentially a
no-op in list context, while [] creates an array ref.

I suppose we could make comma merely puke in scalar context rather
than DWIM, at least optionally.

: Additionally, parentheses have one inconsistency which brackets do not:
: This is the following case, already shown on perl6-language:
: 
:   $a = ();# $a is a list reference with 0 elements
:   $a = (10);  # $a is the scalar 10
:   $a = (10, 20);  # $a is a list reference with 2 elements
:   # ...
: 
: If the ability to construct lists with parentheses is removed, so is this 
: inconsistency.

I don't think that's an important inconsistency.

: This has the added benefit that there is a significant 
: visual clue about when a list is being tossed around.  This doesn't break 
: any convenience, just changes the look of it:
: 
:   # Perl 6# Perl 5
:   [$a, $b] ^= [$b, $a];   # ($a, $b) = ($b, $a)
:   print *[$a=$b],\n;# print(($a=$b), \n);
:   push @a: *[1,2,3];  # push @a, (1,2,3);
:   push @a: [1,2,3];   # push @a, [1,2,3];

I'd rather they just work the way people expect from Perl 5.  Requiring
people to say *[1,2,3] when they could say 1,2,3 is needless obfuscation.

: =head2 Subroutines
: 
: One place of quarrel is subroutine calls. Would this change the argument 
: list delimiters to brackets?  I argue no, because they were never a 
: parenthesis-delimited list in the first place:
: 
:   print(Hello, World, \n);
:   print Hello, World, \n;
: 
: Thus, in this case, parentheses are used for grouping around the argument 
: list, not constructing it.

Indeed.   :-)

: The following transformation has been 
: mentioned:
: 
:   print($a, $b);
: 
: is equivilent to
: 
:   (print $a, $b);
: 
: so no change is necessary on account of subroutine calls.
: 
: =head2 Semantics
: 
: The semantics of brackets need to be changed slightly to support this.  
: Specifically, instead of creating a list Ireference, they create a list 
: Iobject.  This object may be stored in an @array interface, or a $scalar 
: interface.  The $scalar interface works the same way as array references 
: did.  But the way @arrays are assigned changes in this manner:
: 
:   @array = [1, 2, 3]; # @array has 3 elements, not 1
:   @array = [[1, 2, 3]];   # @array has 1 element: an array object
:   @array[0] = [1, 2, 3];  # same thing
: 
: Slices work as they always have.

I think if you're going to replace the whole array using a reference, it's
better to use the explicit binding:

@array := [1,2,3]

It's awfully handy that the right side of a normal list assignment
automatically flattens.  And it's what Perl 5 programmers expect.
They certainly won't expect [] to flatten.

: =head2 Hashes
: 
: For consistency, parentheses must be disallowed for hash construction as 
: well.  The same semantic changes apply to braces. This fixes the common 
: mistake:
: 
:   %hash = { a = 1, b = 2 };
: 
: will now DWIM.  

Well, that one can be caught, if not the other one.  Again, the right
approach to dealing with references is probably to bind:

%hash := { a = 1, b = 2 };

Re: RFC: [] as the solitary list constructor

2002-10-05 Thread Chip Salzenberg

According to Larry Wall:
 I suppose we could make comma merely puke in scalar context rather
 than DWIM, at least optionally.

I rather like Perl 5's scalar comma operator.

 : $a = ();# $a is a list reference with 0 elements
 : $a = (10);  # $a is the scalar 10
 : $a = (10, 20);  # $a is a list reference with 2 elements
 
 I don't think that's an important inconsistency.

What if $a and $b are both array refs, and maintenance programmer
changes:
for $a, $b { print }
to:
for $a { print }
Will that end up iterating across @$a?  The equivalent of that gotcha
was forever bugging me in Python (gack).
-- 
Chip Salzenberg - a.k.a.  -[EMAIL PROTECTED]
 It furthers one to have somewhere to go.



Re: RFC: [] as the solitary list constructor

2002-10-05 Thread Noah White


On Saturday, October 5, 2002, at 09:33  PM, Larry Wall wrote:


 : Additionally, parentheses have one inconsistency which brackets do 
 not:
 : This is the following case, already shown on perl6-language:
 :
 : $a = ();# $a is a list reference with 0 elements
 : $a = (10);  # $a is the scalar 10
 : $a = (10, 20);  # $a is a list reference with 2 elements
 : # ...
 :
 : If the ability to construct lists with parentheses is removed, so is 
 this
 : inconsistency.

 I don't think that's an important inconsistency.

[SNIP]


 : This has the added benefit that there is a significant
 : visual clue about when a list is being tossed around.  This doesn't 
 break
 : any convenience, just changes the look of it:
 :
 : # Perl 6# Perl 5
 : [$a, $b] ^= [$b, $a];   # ($a, $b) = ($b, $a)
 : print *[$a=$b],\n;# print(($a=$b), \n);
 : push a: *[1,2,3];  # push a, (1,2,3);
 : push a: [1,2,3];   # push a, [1,2,3];

 I'd rather they just work the way people expect from Perl 5.  Requiring
 people to say *[1,2,3] when they could say 1,2,3 is needless 
 obfuscation.

I think needless obfuscation is treating $a = (10); as a scalar instead 
of a list reference containing one item when the rest of the the $a = 
() are list references.

-Noah




RE: RFC: [] as the solitary list constructor

2002-10-05 Thread Brent Dax

Noah White:
# I think needless obfuscation is treating $a = (10); as a 
# scalar instead 
# of a list reference containing one item when the rest of the the $a = 
# () are list references.

I think needless obfuscation is treating $a = (10) differently than $a =
10.  The latter is the behavior we've come to expect from other
languages.

This may not look consistent:

$a = (10);
$a = (10, 20);
$a = (10, 20, 30);
#...

But it is consistent with this:

$a = do { 10 };
$a = do { 10, 20 };
$a = do { 10, 20, 30 };
#...

(Thanks for pointing that out, Larry.)

Parens don't construct lists EVER!  They only group elements
syntactically.  One common use of parens is to surround a
comma-separated list, but the *commas* are creating the list, *not* the
parens!

--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)

Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)




Re: RFC: [] as the solitary list constructor

2002-10-05 Thread Noah White


On Sunday, October 6, 2002, at 01:50  AM, Brent Dax wrote:

 Parens don't construct lists EVER!  They only group elements
 syntactically.  One common use of parens is to surround a
 comma-separated list, but the *commas* are creating the list, *not* the
 parens!


Following this rule would mean that

  $a = ();  # $a is a list reference with 0 elements

should not be a list reference at all and would appear inconsistent.

-Noah