Arrays vs. Lists
Michael Lazzaro
I'm trying, and failing, to accurately and definitively answer the
question "what's the difference between an array and a list in Perl6?"
If someone can come up with a simple but accurate definition, it would
be helpful.
MikeL
Austin Hastings
How's this?
============
A number is a literal (e.g., 3) that can be used as the initializer for
a scalar.
A string is a literal (e.g., "Hello, world") that can be used as the
initializer for a scalar.
A list is a literal (e.g., '(3, "Hello, world")') that can be used as
the initializer for an array.
With one exception, places in perl that require "a scalar" can be given
a literal number or string. Likewise, places in perl that require "an
array" can be given a list. The exception is lvalues -- you can't say 3
= "Hello, world"; -- the left-hand side of an assignment operation
requires an assignable thing, not a literal.
So the difference between a list and an array is one of assignability -
a list can be indexed, examined, copied, iterated over using for, etc.
But in order to make changes you have to have an array -- a container
for a list. Because arrays can do all the things above, plus shift,
pop, append, delete, etc.
==========?
=Austin
Mark J. Reed
> --- Michael Lazzaro <mlaz...@cognitivity.com> wrote:
> > I'm trying, and failing, to accurately and definitively answer the
> > question "what's the difference between an array and a list in
> > Perl6?"
>
> ============
>
> the initializer for an array.
>
> exception is lvalues -- you can't say 3 = "Hello, world"; -- the
> left-hand side of an assignment operation requires an assignable
> thing, not a literal. So the difference between a list and an array
Not really, though. A list can be an lvalue, provided it is a list
of lvalues:
($a, $b, $c) = 1,2,3;
Although this may reasonably be regarded as a special case; you
certainly can't pop a list:
(1,2,3).pop => error
But there's also the case of anonymous arrays, constructed through
reference via [ . . . ]. These are pop'able:
[1,2,3].pop => 3
But they certainly aren't lvalues:
[$a,$b,$c] = 1,2,3 => error
Unless some magic autoconversion happens.
--
Mark REED | CNN Internet Technology
1 CNN Center Rm SW0831G | mark...@cnn.com
Atlanta, GA 30348 USA | +1 404 827 4754
Mark J. Reed
> Not really, though. A list can be an lvalue, provided it is a list
> of lvalues:
>
> ($a, $b, $c) = 1,2,3;
($a, $b, $c) = (1,2,3);
> But they certainly aren't lvalues:
>
> [$a,$b,$c] = 1,2,3; => error
[$a, $b, $c] = (1,2,3) => still an error
Just to flesh it out:
[$a, $b, $c] = [1,2,3] => still an error
($a, $b, $c) = [1,2,3] => not an error; $a is [1,2,3],
$b and $c undef.
Austin Hastings
--- "Mark J. Reed" <mark...@turner.com> wrote:
> On 2003-02-07 at 11:13:07, Austin Hastings wrote:
> > --- Michael Lazzaro <mlaz...@cognitivity.com> wrote:
> > > I'm trying, and failing, to accurately and definitively answer
> the
> > > question "what's the difference between an array and a list in
> > > Perl6?"
> >
> > How's this?
> > ============
> >
> > A list is a literal (e.g., '(3, "Hello, world")') that can be used
> as
> > the initializer for an array.
> >
> > [...] places in perl that require "an array" can be given a list.
> The
> > exception is lvalues -- you can't say 3 = "Hello, world"; -- the
> > left-hand side of an assignment operation requires an assignable
> > thing, not a literal. So the difference between a list and an
> array
> > is one of assignability.
> Not really, though. A list can be an lvalue, provided it is a list
> of lvalues:
>
> ($a, $b, $c) = 1,2,3;
Hmm. You're kind of weaseling there because that's "DWIM magic" for 3
lines of code, but I don't know how to get there.
> Although this may reasonably be regarded as a special case; you
> certainly can't pop a list:
>
> (1,2,3).pop => error
But could you do it the other way (function instead of method)?
pop (1,2,3) => ?
> But there's also the case of anonymous arrays, constructed through
> reference via [ . . . ]. These are pop'able:
>
> [1,2,3].pop => 3
>
> But they certainly aren't lvalues:
>
> [$a,$b,$c] = 1,2,3 => error
Actually, they're literal array references, not arrays.
I'm unsure how the mechanics are going to act in p6, since we're hiding
the -> on refs. But in my heart of (c coding) hearts, it's a pointer.
=Austin
Mark J. Reed
On 2003-02-07 at 12:18:21, Austin Hastings wrote:
> > Although this may reasonably be regarded as a special case; you
> > certainly can't pop a list:
> >
> > (1,2,3).pop => error
>
> But could you do it the other way (function instead of method)?
> pop (1,2,3) => ?
Type of arg 1 to pop must be array (not list)
> > But there's also the case of anonymous arrays, constructed through
> > reference via [ . . . ]. These are pop'able:
> >
> > [1,2,3].pop => 3
> >
> > But they certainly aren't lvalues:
> >
> > [$a,$b,$c] = 1,2,3 => error
>
> Actually, they're literal array references, not arrays.
You can't have an array reference without an array; the reference has
to refer to something. :) The referred-to-array in this case has no name,
hence "anonymous arrays, constructed through reference".
> I'm unsure how the mechanics are going to act in p6, since we're hiding
> the -> on refs. But in my heart of (c coding) hearts, it's a pointer.
A reference is fundamentally a pointer, but that doesn't help. My point
was that if you're talking about lists vs. arrays, you have at least
three different syntaxes to distinguish:
(1,2,3)
@arrayName
[1,2,3]
These all do different things, and autoconversion just adds to the
confusion - for instance, @arrayName is normally an array, but in
certain contexts it will be automatically turned into a reference
($aRef = @arrayName) or flattened into a list (print @arrayName).
Uri Guttman
MJR> A reference is fundamentally a pointer, but that doesn't help. My point
MJR> was that if you're talking about lists vs. arrays, you have at least
MJR> three different syntaxes to distinguish:
MJR> (1,2,3)
MJR> @arrayName
MJR> [1,2,3]
one simple explanation still works i think. arrays are allocated and
lists are on the stack. so arrays can have references to them but lists
can't. this works with both lvalue and rvalue. a list of lvalues is on
the stack and can be assigned to. you can't push/pop/splice a list on the
stack. you can take slices from a list on the stack.
the whole notion is that lists are always temporary and arrays can be as
permanent as you want (an array ref going quickly out of scope is very
temporary). lists can't live beyond the current expression but arrays can.
can anyone see any changes in perl6 to invalidate that separation of
lists and arrays?
uri
--
Uri Guttman ------ u...@stemsystems.com -------- http://www.stemsystems.com
----- Stem and Perl Development, Systems Architecture, Design and Coding ----
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
Damian Conway Perl Classes - January 2003 -- http://www.stemsystems.com/class
Michael Lazzaro
On Friday, February 7, 2003, at 02:07 PM, Uri Guttman wrote:
> the whole notion is that lists are always temporary and arrays can be
> as
> permanent as you want (an array ref going quickly out of scope is very
> temporary). lists can't live beyond the current expression but arrays
> can.
Along those lines, the closest I've been able to come so far to a
usable two-sentence definition is:
-- A list is an ordered set of scalar values.
-- An array is an object that stores a list.
But I'm not sure that holds water.
MikeL
Uri Guttman
ML> On Friday, February 7, 2003, at 02:07 PM, Uri Guttman wrote:
>> the whole notion is that lists are always temporary and arrays can
>> be as
>> permanent as you want (an array ref going quickly out of scope is very
>> temporary). lists can't live beyond the current expression but
>> arrays can.
ML> Along those lines, the closest I've been able to come so far to a
ML> usable two-sentence definition is:
ML> -- A list is an ordered set of scalar values.
ML> -- An array is an object that stores a list.
but you can't derive the rules about allowing push/pop/splice/slice from
that pair of defintions.
you can simplify my pair to:
a list is temporary ordered set of scalar values that lives only in a
single expression
an array is an ordered set of scalar values that is allocated and can
live between expressions.
note that i said expression and not statement. you can't have the same
list in two parts of an expression while you can with an array (ref or
plain). that implies you can't change a list since it only exists once.
another (and shorter pair) is this:
(note that this is from the whole list point of view, not its elements)
lists are read only
arrays are read/write
that allows slices on lists but not push/pop/splice. the lvalueness of
their elements doesn't matter.
the two sets of pairs above can be combined for clarity:
(again these are from the whole list/array point of view)
a list lives in a single place in a single expression and can't be
modified.
an array can live in multiple places in multiple expressions and can be
changed
the single place makes it impossible to take a ref to a list. the
multiple places for an array implies references are possible. the array
can be changed since it has state that will store the change. a list has
no such state as it will die when the expression is done.
Dave Whipp
news:04336C89-3AEE-11D7...@cognitivity.com...
> Along those lines, the closest I've been able to come so far to a
> usable two-sentence definition is:
>
> -- A list is an ordered set of scalar values.
quibble: that's an "ordered bag", isn't it? ;)
> -- An array is an object that stores a list.
My phrasing of the distinction is that a list is a lexical entity,
whilst an array is a variable.
Anonymous array constructors are just special syntax for
passing a list to an array (or Array) constructor.
Michael Lazzaro
On Friday, February 7, 2003, at 03:38 PM, Uri Guttman wrote:
> but you can't derive the rules about allowing push/pop/splice/slice
> from
> that pair of defintions.
Is there any syntactic reason why both of the following cannot be
allowed?
(1,2,3).pop
[1,2,3].pop
I don't know that one is any more/less useful than the other, and it
would seem a list could be silently promoted to an array where it is
used as an array. For example,
\(1,2,3)
returns an array reference...
MikeL
Stéphane Payrard
> On 2003-02-07 at 14:26:42, Mark J. Reed wrote:
> > Not really, though. A list can be an lvalue, provided it is a list
> > of lvalues:
Note that to avoid the burden of writing an explicit slice, 'undef' is
considered as a lvalue in such a context. I see no reason for that
behavior to change in perl6:
($a, undef, $b) = (1, 2, 3); # equivalent to ($a,$b) = (1, 3)
Note this is only true of undef. You can't stick any literal in its splace.
($a,1,$b) = qw(1,2,3)
Can't modify constant item in list assignment at (eval 5)[/usr/lib/perl5/5.8.0/perl5db.pl:17] line 2, at EOF
--
stef
Uri Guttman
ML> On Friday, February 7, 2003, at 03:38 PM, Uri Guttman wrote:
>> but you can't derive the rules about allowing push/pop/splice/slice
>> from
>> that pair of defintions.
ML> Is there any syntactic reason why both of the following cannot be
ML> allowed?
ML> (1,2,3).pop
that is no different than saying (3). as the list can't be modified nor
a ref taken, the pop is illegal.
ML> [1,2,3].pop
ML> I don't know that one is any more/less useful than the other, and it
ML> would seem a list could be silently promoted to an array where it is
ML> used as an array. For example,
ML> \(1,2,3)
ML> returns an array reference...
in perl5 it returns a list of refs ( \1, \2, \3 ). i dunno the perl6
semantics. it could be the same as [ 1, 2, 3 ] which means it is not a
list but sugar for a new anon array and more like:
do{ \my @foo = ( 1, 2, 3 ) }
but we only need [] for all that.
Adam Turoff
> >>>>> "ML" == Michael Lazzaro <mlaz...@cognitivity.com> writes:
> ML> Along those lines, the closest I've been able to come so far to a
> ML> usable two-sentence definition is:
>
> ML> -- A list is an ordered set of scalar values.
> ML> -- An array is an object that stores a list.
>
> but you can't derive the rules about allowing push/pop/splice/slice from
> that pair of defintions.
1) A list is an ordered grouping of scalar values.
2) An array is an object that stores a list.
3) Assignment and splices can be performed on both lists and arrays.
4) Operators like push/pop/splice/shift/unshift operate only on arrays.
> lists are read only
Not quite: ($a, $b, $c) = 1..3;
Z.
Luke Palmer
> From: Michael Lazzaro <mlaz...@cognitivity.com>
Rather,
-- An array is a variable.
-- A list is a value.
It's just a special kind of value, that distributes certain operators
over its elements. It's still a value.
The discrepancy about Array's methods is simple. Can you C<chop> a
string literal? That's why you can't C<pop> a list.
Luke
Michael Lazzaro
On Friday, February 7, 2003, at 04:24 PM, Uri Guttman wrote:
> ML> \(1,2,3)
>
> ML> returns an array reference...
>
> in perl5 it returns a list of refs ( \1, \2, \3 ). i dunno the perl6
> semantics. it could be the same as [ 1, 2, 3 ] which means it is not a
Sorry, I was misremembering a thread. I remember (vaguely) now...
can't do what I suggested because it's something like \($x) should
never be a list ref, which means we would have to treat parens
differently depending on how many things are inside them, etc, which
pointedly won't work.
If someone remembers when that damn thread happened, or better still
remembers the outcome (if any), drop me a pointer?
MikeL
Uri Guttman
AT> On Fri, Feb 07, 2003 at 06:38:36PM -0500, Uri Guttman wrote:
>> >>>>> "ML" == Michael Lazzaro <mlaz...@cognitivity.com> writes:
ML> Along those lines, the closest I've been able to come so far to a
ML> usable two-sentence definition is:
>>
ML> -- A list is an ordered set of scalar values.
ML> -- An array is an object that stores a list.
>>
>> but you can't derive the rules about allowing push/pop/splice/slice from
>> that pair of defintions.
AT> 1) A list is an ordered grouping of scalar values.
AT> 2) An array is an object that stores a list.
AT> 3) Assignment and splices can be performed on both lists and arrays.
you can't assign to a list. you can assign to lvalues in a list. the
list doesn't change. it is a list of lvalues before and after the
assignment.
AT> 4) Operators like push/pop/splice/shift/unshift operate only on arrays.
>> lists are read only
AT> Not quite: ($a, $b, $c) = 1..3;
that list is still unmodified, same size, no elements are changed. the
elements are lvalues which have their values changed, but the list
itself is still read only.
only my two definitions are needed, not 4. simpler is better. :)
Deborah Ariel Pickett
While I like the glib "Arrays are variables that hold lists" explanation
that worked so well in Perl5, I think that Perl6 is introducing some
changes to this that make this less true. For instance, the switch
statement has different rules for lists and arrays. So these don't
necessarily do exactly the same thing in Perl6:
# Please excuse syntax errors here, but you know what I mean
given (1,2,3)
{
when $x: ....
and
@a = (1, 2, 3);
given @a
{
when $x: ...
Would there be any truth in this distinction:
- lists are ordered sets/bags/etc seen by the Perl parser
- arrays are ordered sets/bags/etc seen by the Perl interpreter
?
--
Debbie Pickett http://www.csse.monash.edu.au/~debbiep deb...@csse.monash.edu.au
"Oh, she's got it bad." "What? What has she got?" "Isn't it obvious, Daddy?
Ariel's in *love*." - _The Little Mermaid_
Joseph F. Ryan
>>I'm trying, and failing, to accurately and definitively answer the
>>question "what's the difference between an array and a list in Perl6?"
>>If someone can come up with a simple but accurate definition, it would
>>be helpful.
>>
>>
>
>While I like the glib "Arrays are variables that hold lists" explanation
>that worked so well in Perl5, I think that Perl6 is introducing some
>changes to this that make this less true.
>
Like what?
>For instance, the switch
>statement has different rules for lists and arrays. So these don't
>necessarily do exactly the same thing in Perl6:
>
> # Please excuse syntax errors here, but you know what I mean
> given (1,2,3)
> {
> when $x: ....
>
>and
>
> @a = (1, 2, 3);
> given @a
> {
> when $x: ...
>
I don't understand the difference here. Could you elaborate?
>Would there be any truth in this distinction:
>- lists are ordered sets/bags/etc seen by the Perl parser
>- arrays are ordered sets/bags/etc seen by the Perl interpreter
>?
>
Where s/parser/compiler/, and s/interpretter/runtime engine/? I
do believe that's accurate.
Joseph F. Ryan
ryan...@osu.edu
Deborah Ariel Pickett
> >that worked so well in Perl5, I think that Perl6 is introducing some
> >changes to this that make this less true.
> Like what?
Well, like the builtin switch statement, which was what I was trying to
show in my bad example below.
What I meant was: In Perl5, pretty much anywhere you have a list, you
can write an array variable instead, and get much the same behaviour:
@a = (1, 2, 3);
func(@a);
func(1,2,3);
The exceptions appear to be builtin operators like C<push>,
functions that have Perl5-prototypes, and using lists/arrays as lvalues.
But all of those are caught by the Perl5 parser, and treated specially.
Everywhere else, naming an array automatically expands to a list
containing the array's contents. It's pretty much a universal, and
something which Perl programmers hold dear.
In Perl6, where there seems to be even more of a blur between
compile-time and runtime, I don't think it's always going to be possible
(i.e., easy) to know where naming an array or providing an actual list
would produce the same effect. The switch statement was my example.
Apocalypse 4 has a table (page 2 of the perl.com version) which bears
this out. Lists have their own entries on this table, separate from
arrays. So it's conceivable that a switch statement that switches on a
list and a switch statement that switches on an array containing the
same list produces different results.
Perhaps this just adds the switch statement to the set of Perl
constructs that require special compiler attention, like lvalues and
builtin operators.
(This suggests to me that it won't be possible to implement the switch
statement as a pure Perl6 function - as people were trying to do with
C<if> - without greater-than-usual assistance from the Perl6 compiler.)
It also appears that we'll now be able to pass multiple arrays to
functions without the taking-references shenanigans that you have to go
through in Perl5. So there's another example where lists and arrays
appear to be going their separate ways, with lists almost being their
own data type, in a manner of speaking. I dare say that we'll have to
wait till Apocalypse 6 for the full story here.
(Just going off on a tangent: Is it true that an array slice such as
@array[4..8]
is syntactically equivalent to this list
(@array[4], @array[5], @array[6], @array[7], @array[8])
? Are array slices always lists in Perl6?)
> >For instance, the switch
> >statement has different rules for lists and arrays. So these don't
> >necessarily do exactly the same thing in Perl6:
> >
> > # Please excuse syntax errors here, but you know what I mean
> > given (1,2,3)
> > {
> > when $x: ....
> >
> >and
> >
> > @a = (1, 2, 3);
> > given @a
> > {
> > when $x: ...
> >
>
> I don't understand the difference here. Could you elaborate?
See above.
> >Would there be any truth in this distinction:
> >- lists are ordered sets/bags/etc seen by the Perl parser
> >- arrays are ordered sets/bags/etc seen by the Perl interpreter
> >?
> >
>
> Where s/parser/compiler/, and s/interpretter/runtime engine/? I
> do believe that's accurate.
What joy I'll have explaining that one to my students . . .
Luke Palmer
> Date: Tue, 11 Feb 2003 11:15:13 +1100 (EST)
>
> In Perl6, where there seems to be even more of a blur between
> compile-time and runtime, I don't think it's always going to be possible
> (i.e., easy) to know where naming an array or providing an actual list
> would produce the same effect. The switch statement was my example.
> Apocalypse 4 has a table (page 2 of the perl.com version) which bears
> this out. Lists have their own entries on this table, separate from
> arrays. So it's conceivable that a switch statement that switches on a
> list and a switch statement that switches on an array containing the
> same list produces different results.
In these terms, I'd like to refer you to Apocalypse 2, under RFC 009.
I belive this is one (perhaps the only :) thing that hasn't changed
about Perl 6 sice A2. Particularly:
... If composite variables are thought of as scalar references,
then the names @foo and %foo are really scalar variables unless
explicitly dereferenced. That means that when you mention them in
a scalar context, you get the equivalent of Perl 5's \@foo and
\%foo. This simplifies the prototyping system greatly, in that an
operator like push no longer needs to specify some kind of special
reference context for its first argument -- it can merely specify
a scalar context, and that's good enough to assume the reference
generation on its first argument....
Indeed, this supports the distinction, which I will reiterate:
- Arrays are variables.
- Lists are values.
Arrays are things that know about lists. They know how to get a
particular element out of a list. They know how to *flatten
themselves, interpolating themselves into the surrounding list. They
know how to map, grep, sort, splice themselves. They know how to turn
themselves into a scalar. Lists don't know how to do these things.
Just like, for example, scalars. A scalar can hold a number. A
scalar knows how to increment itself, but a number sure doesn't.
I'm formulating new, wild ideas here... Another post coming in a
minute. I hope I clarified the array/list thing at least a little
bit.
Luke
Joseph F. Ryan
>>>While I like the glib "Arrays are variables that hold lists" explanation
>>>that worked so well in Perl5, I think that Perl6 is introducing some
>>>changes to this that make this less true.
>>>
>>>
>>Like what?
>>
>>
>
>Well, like the builtin switch statement, which was what I was trying to
>show in my bad example below.
>
>What I meant was: In Perl5, pretty much anywhere you have a list, you
>can write an array variable instead, and get much the same behaviour:
>
> @a = (1, 2, 3);
> func(@a);
> func(1,2,3);
>
>The exceptions appear to be builtin operators like C<push>,
>functions that have Perl5-prototypes, and using lists/arrays as lvalues.
>But all of those are caught by the Perl5 parser, and treated specially.
>Everywhere else, naming an array automatically expands to a list
>containing the array's contents. It's pretty much a universal, and
>something which Perl programmers hold dear.
>
>In Perl6, where there seems to be even more of a blur between
>compile-time and runtime,
>
Actually, I think they'll be more separated. In fact, the compiler will
just be an extension to the runtime-engine.
>I don't think it's always going to be possible
>(i.e., easy) to know where naming an array or providing an actual list
>would produce the same effect. The switch statement was my example.
>Apocalypse 4 has a table (page 2 of the perl.com version) which bears
>this out. Lists have their own entries on this table, separate from
>arrays. So it's conceivable that a switch statement that switches on a
>list and a switch statement that switches on an array containing the
>same list produces different results.
>
I see what you mean now; C<given> topic-alizes what it is, well, given.
This would cause it to work differently for variables and "other."
>Perhaps this just adds the switch statement to the set of Perl
>constructs that require special compiler attention, like lvalues and
>builtin operators.
>
I think you might be right; however, it would be nice if this wasn't the
case, as then user-defined functions could act similarly. (kinda like
how perl5-prototypes allow user-defined functions to act like perl5-
bultins, without the yeecccchh of perl5-prototypes.)
>(This suggests to me that it won't be possible to implement the switch
>statement as a pure Perl6 function - as people were trying to do with
>C<if> - without greater-than-usual assistance from the Perl6 compiler.)
>
>It also appears that we'll now be able to pass multiple arrays to
>functions without the taking-references shenanigans that you have to go
>through in Perl5. So there's another example where lists and arrays
>appear to be going their separate ways, with lists almost being their
>own data type, in a manner of speaking. I dare say that we'll have to
>wait till Apocalypse 6 for the full story here.
>
>(Just going off on a tangent: Is it true that an array slice such as
> @array[4..8]
>is syntactically equivalent to this list
> (@array[4], @array[5], @array[6], @array[7], @array[8])
>? Are array slices always lists in Perl6?)
>
I think so, unless its possible to do crazy things like reference part
of an array. Maybe @array[4..8] is a list, and \@array[4..8] acts like
an array. Or maybe \@array[4..8] is actually ( \@array[4], \@array[5],
\@array[6], \@array[7], \@array[8]), like it is in perl 5. If it keeps
that behaivor, then @array[4..8] is always a list.
>>>Would there be any truth in this distinction:
>>>- lists are ordered sets/bags/etc seen by the Perl parser
>>>- arrays are ordered sets/bags/etc seen by the Perl interpreter
>>>?
>>>
>>>
>>>
>>Where s/parser/compiler/, and s/interpretter/runtime engine/? I
>>do believe that's accurate.
>>
>>
>
>What joy I'll have explaining that one to my students . . .
>
Better you than me. :-)
Joseph F. Ryan
ryan...@osu.edu
Michael Lazzaro
> Indeed, this supports the distinction, which I will reiterate:
>
> - Arrays are variables.
> - Lists are values.
My hesitation about the 'arrays are variables' part is that Damian
corrected me on a similar thing when I was writing about scalars. A
variable is more like "a name of a container for a value", e.g. there's
three parts to it:
- the name (what it's called in the namespace)
- the container (a specific container implementation)
- the value (what's inside it)
So I don't know that arrays are variables, so much as arrays are
containers, if we want to get pedantic about it (which I don't, but...
documentation... sigh).
Just to clarify... in P6, is this an array reference, or a list
reference?
[1,2,3]
What about this?
\@array
I'd say both of them are array references, but there's no variable
associated with the first one -- it's just an anonymous container. So
I'd rewrite the definition to:
- Lists are an ordered collection of scalar values
- Arrays are containers that store lists
(Coupled with Uri's explanations, of course... it's the 'container'
part that allows read/write, as opposed to simply read.) Yes/no?
> Arrays are things that know about lists. They know how to get a
> particular element out of a list. They know how to *flatten
> themselves, interpolating themselves into the surrounding list. They
> know how to map, grep, sort, splice themselves. They know how to turn
> themselves into a scalar. Lists don't know how to do these things.
But is it OK for a list to be silently promoted to an array when used
as an array? So that all of the following would work, and not just 50%
of them?
(1..10).map {...}
[1..10].map {...}
(@a,@b,@c).pop
[@a,@b,@c].pop
MikeL
Michael Lazzaro
On Monday, February 10, 2003, at 06:26 PM, Joseph F. Ryan wrote:
> Deborah Ariel Pickett wrote:
>> (Just going off on a tangent: Is it true that an array slice such as
>> @array[4..8]
>> is syntactically equivalent to this list
>> (@array[4], @array[5], @array[6], @array[7], @array[8])
>> ? Are array slices always lists in Perl6?)
> I think so, unless its possible to do crazy things like reference part
> of an array. Maybe @array[4..8] is a list, and \@array[4..8] acts like
> an array. Or maybe \@array[4..8] is actually ( \@array[4], \@array[5],
> \@array[6], \@array[7], \@array[8]), like it is in perl 5. If it keeps
> that behaivor, then @array[4..8] is always a list.
What is the utility of the perl5 behavior:
\($a,$b,$c)
meaning
(\$a, \$b, \$c)
Do people really do that? I must say, given that it looks *so
obviously* like it instead means [$a,$b,$c], I wonder if attempting to
take a reference to a list should be a compile-time error.
Note that this is still OK:
\($a) # same as \$a
because as previously discussed, it's the commas making the list, not
the parens. But \($a,$b,$c) seems like a bug waiting to happen. I
don't use it. Can someone give an example of an actual, proper, use?
>> What joy I'll have explaining that one to my students . . .
Groan. Yeah. I feel your pain. :-|
MikeL
Luke Palmer
> From: Michael Lazzaro <mlaz...@cognitivity.com>
>
> > Indeed, this supports the distinction, which I will reiterate:
> >
> > - Arrays are variables.
> > - Lists are values.
>
> My hesitation about the 'arrays are variables' part is that Damian
> corrected me on a similar thing when I was writing about scalars. A
> variable is more like "a name of a container for a value", e.g. there's
> three parts to it:
>
> - the name (what it's called in the namespace)
> - the container (a specific container implementation)
> - the value (what's inside it)
>
> So I don't know that arrays are variables, so much as arrays are
> containers, if we want to get pedantic about it (which I don't, but...
> documentation... sigh).
Well, that doesn't assume the definition of the variable includes a
namespace entry. So, yes, I suppose container would be better. The
thing the namespace entry points to, but not the value.
> Just to clarify... in P6, is this an array reference, or a list
> reference?
>
> [1,2,3]
>
> What about this?
>
> \@array
>
> I'd say both of them are array references, but there's no variable
> associated with the first one
I'd agree.
> -- it's just an anonymous container. So I'd rewrite the definition
> to:
>
> - Lists are an ordered collection of scalar values
> - Arrays are containers that store lists
I think that's a pretty good one.
> (Coupled with Uri's explanations, of course... it's the 'container'
> part that allows read/write, as opposed to simply read.) Yes/no?
Yes, from my perspective, the container is the one that knows
read/write. Basically, the only you can't modify lists is that they
have no operations defined that can modify them. Arrays on the other
hand, do.
>
> > Arrays are things that know about lists. They know how to get a
> > particular element out of a list. They know how to *flatten
> > themselves, interpolating themselves into the surrounding list. They
> > know how to map, grep, sort, splice themselves. They know how to turn
> > themselves into a scalar. Lists don't know how to do these things.
>
> But is it OK for a list to be silently promoted to an array when used
> as an array? So that all of the following would work, and not just 50%
> of them?
>
> (1..10).map {...}
> [1..10].map {...}
I don't really know here. I'm not sure whether this should work....
I think if lists don't have the C<map> method, that shouldn't work.
> (@a,@b,@c).pop
> [@a,@b,@c].pop
Why would you suppose the former to work? Or do you mean that to mean
(@a.pop,@b.pop,@c.pop)? Can lists have methods?
This clear distinction that I once had in my mind is getting blurrier
and blurrier. :(
Luke
Randal L. Schwartz
Michael> Do people really do that? I must say, given that it looks *so
Michael> obviously* like it instead means [$a,$b,$c], I wonder if attempting to
Michael> take a reference to a list should be a compile-time error.
Michael> Note that this is still OK:
Michael> \($a) # same as \$a
Michael> because as previously discussed, it's the commas making the list, not
Michael> the parens. But \($a,$b,$c) seems like a bug waiting to happen. I
Michael> don't use it. Can someone give an example of an actual, proper, use?
It was to make "pass by reference" easier, before prototypes if I recall:
myfunc \($a, @b, %c);
which means the same as if we had said:
sub myfunc (\$ \@ \%);
myfunc($a, @b, %c);
Except that the prototyped version mandates the specific types.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<mer...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Joseph F. Ryan
> On Monday, February 10, 2003, at 05:56 PM, Luke Palmer wrote:
>
>> Indeed, this supports the distinction, which I will reiterate:
>>
>> - Arrays are variables.
>> - Lists are values.
>
>
> My hesitation about the 'arrays are variables' part is that Damian
> corrected me on a similar thing when I was writing about scalars. A
> variable is more like "a name of a container for a value", e.g.
> there's three parts to it:
>
> - the name (what it's called in the namespace)
> - the container (a specific container implementation)
> - the value (what's inside it)
>
> So I don't know that arrays are variables, so much as arrays are
> containers, if we want to get pedantic about it (which I don't, but...
> documentation... sigh).
They're definately variables. The container is a PerlArray,
which is a distinctly different object compared to a
PerlUndef.
> Just to clarify... in P6, is this an array reference, or a list
> reference?
>
> [1,2,3]
I'd say it is an array reference.
> What about this?
>
> \@array
>
> I'd say both of them are array references, but there's no variable
> associated with the first one -- it's just an anonymous container
There should be a variable attached, but just no name
attached to the variable.
> So I'd rewrite the definition to:
>
> - Lists are an ordered collection of scalar values
> - Arrays are containers that store lists
>
> (Coupled with Uri's explanations, of course... it's the 'container'
> part that allows read/write, as opposed to simply read.) Yes/no?
Maybe :-)
>> Arrays are things that know about lists. They know how to get a
>> particular element out of a list. They know how to *flatten
>> themselves, interpolating themselves into the surrounding list. They
>> know how to map, grep, sort, splice themselves. They know how to turn
>> themselves into a scalar. Lists don't know how to do these things.
>
>
> But is it OK for a list to be silently promoted to an array when used
> as an array
But this would mean that an implicit anonymous array would need
to be created, which isn't always possible in the middle of a
statement. So, that would mean the compiler would need to be
smart enough to figure out when this will happen, and then
create the anonymous array beforehand, and then somehow
alias the list contents to the array. Thats a heck of a lot
of magic going on there.
> So that all of the following would work, and not just 50% of them?
>
> (1..10).map {...}
I think this should be an error. What object is the method
getting called on?
Is forcing the functional syntax on lists really that horrible?
>
> [1..10].map {...
I think this *should* work, although I'm not sure *how*.
> (@a,@b,@c).pop
This doesn't make any sense, since pop modifies the pop-ee.
What do you expect should happen here?
>
> [@a,@b,@c].pop
Same as above.
Joseph F. Ryan
ryan...@osu.edu
Mark J. Reed
On 2003-02-11 at 17:12:52, Joseph F. Ryan wrote:
> > (@a,@b,@c).pop
>
> This doesn't make any sense, since pop modifies the pop-ee.
> What do you expect should happen here?
>
>
> >
> > [@a,@b,@c].pop
>
>
> Same as above.
Except that the Perl5 equivalent, ugly as the syntax may be, works fine:
pop @{[@a,@b,@c]}
It creates an anonymous array, then removes the last element, leaving two
elements in the array - which is irrelevant since the array is
then discarded completely.
I don't see any reason to change this behavior for Perl6.
Mark J. Reed
On 2003-02-11 at 17:44:08, Mark J. Reed wrote:
> pop @{[@a,@b,@c]}
>
> It creates an anonymous array, then removes the last element, leaving two
> elements in the array - which is irrelevant since the array is
> then discarded completely.
array - it depends on how many elements were in @a, @b, and @c to
start with. One less than that. :)
Uri Guttman
>> (@a,@b,@c).pop
JFR> This doesn't make any sense, since pop modifies the pop-ee.
JFR> What do you expect should happen here?
>> [@a,@b,@c].pop
JFR> Same as above.
there is a subtle distinction in those two. the first should be a syntax
error. the second isn't an error but isn't needed. you could just
as easily do ( @a, @b, @c )[-1].
and the equivilent works in perl5. dumb, but it works.
perl -le 'print pop( @{[qw(a b c)]} )'
c
and i haven't seen anything in perl6 that drastically changes the
semantics of lists and arrays from perl5. so the current definitions we
have been tossing about should suffice.
minor variation:
an array (anon or named) is a container that holds a list. the
array container itself can be modified. containers can stay
alive as long as you want.
a list is a ordered bag of values. it is alive
only where it is created in the current expression. the list
cannot be modified.
Dave Whipp
"Mark J. Reed" <mark...@turner.com> wrote in message
news:20030211225...@charm.turner.com...
>
> On 2003-02-11 at 17:44:08, Mark J. Reed wrote:
> > pop @{[@a,@b,@c]}
> >
> > It creates an anonymous array, then removes the last element, leaving
two
> > elements in the array - which is irrelevant since the array is
> > then discarded completely.
> Minor correction: we don't know how many elements are left in the
> array - it depends on how many elements were in @a, @b, and @c to
> start with. One less than that. :)
These days you need the splat operator to flatten lists: so the above starts
out as a list of 3 array-refs, and the pop returns 1 array-ref, leaving 2 in
the anon-array -- which then becomes garbage, to be collected sometime.
Dave Whipp
> What is the utility of the perl5 behavior:
>
> \($a,$b,$c)
>
> meaning
>
> (\$a, \$b, \$c)
>
> Do people really do that? I must say, given that it looks *so
> obviously* like it instead means [$a,$b,$c], I wonder if attempting to
> take a reference to a list should be a compile-time error.
If you make the ListRef an error, can we hyper- the reference operator
to achieve the Perl5 behavior?
Brent Dax
# > Minor correction: we don't know how many elements are left in the
# > array - it depends on how many elements were in @a, @b, and @c to
# > start with. One less than that. :)
#
# These days you need the splat operator to flatten lists: so
My understanding was that arrays would flatten implicity in list
context, and the splat was only to be used in cases like subroutine
calls, when an array would normally ref-ify.
--Brent Dax <bren...@cpan.org>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
>How do you "test" this 'God' to "prove" it is who it says it is?
"If you're God, you know exactly what it would take to convince me. Do
that."
--Marc Fleury on alt.atheism
Deborah Ariel Pickett
> as an array? So that all of the following would work, and not just 50%
> of them?
> (1..10).map {...}
> [1..10].map {...}
And somehow related to all this . . .
Let's assume for the moment that there's still a functional version of
the C<map> operator (I think Larry indicated that it probably wouldn't
be going away, despite <~ and friends). I'm also going to use $_ in the
code block, even though things like $^a exist. Lowest common
denominator and all that.
Let's also assume:
@count = (1, 2, 3, 4, 5);
@smallcount = (2, 3, 4);
$#array works like in Perl5 (if not, you can mentally change my
notation below)
What's the result of these statements in Perl6?
@a = map { $_ + 1 } @count; # my guess: @a = (2, 3, 4, 5, 6)
@a = map { $_ + 1 } @count[0..$#count]; # my guess: @a = (2, 3, 4, 5, 6)
@a = map { $_ + 1 } (1, 2, 3, 4, 5); # my guess: @a = (2, 3, 4, 5, 6)
All fair enough. Now how about these?
@a = map { $_ + 1 } (1, @smallcount, 5); # Three or five elements?
@a = map { $_ + 1 } (1, @smallcount[0..$#smallcount], 5); # Array slices appear to be lists
@a = map { $_ + 1 } \@count; # Map the array or its reference?
@a = map { $_ + 1 } [1, 2, 3, 4, 5]; # one-element list or five-element array?
$ref = @count;
@a = map { $_ + 1 } $ref; # Map the scalar or the array it refers to?
@a = map { $_ + 1 } @count; # Am I sure about this one any more, given the one above?
There's a slippery slope here that needs propping up.
It's things like this that make me worry a great deal about implicit
dereferencing, something which is going to be happening a lot more in
Perl6 than in Perl5.
Where's the list of rules that state:
- when implicit referencing happens
- when implicit dereferencing happens
- when arrays are flattened into lists, and
- how to stop this from being the default, and
- how to make it happen when it isn't the default
- how arrays of pairs, lists of pairs (i.e., "hash literals")
and hashes are related, and when one can be substituted for
another (and when one is implicitly converted to another)
?
I think some of this is in A2, but not all of it.
I'm prepared to summarize the outcome of this discussion if we actually
arrive at anything definite.
Mark J. Reed
that the equivalent of [@a,@b,@c].pop currently works, despite the
previous poster's statement that it doesn't make sense.
But I didn't think it was true in Perl6 either - [@a,@b,@c] supplies
list context, so each of the arrays should be automatically flattened.
Joseph F. Ryan
>On 2003-02-11 at 17:12:52, Joseph F. Ryan wrote:
>
>
>>> (@a,@b,@c).pop
>>>
>>>
>>This doesn't make any sense, since pop modifies the pop-ee.
>>What do you expect should happen here?
>>
>>
>>
>>
>>> [@a,@b,@c].pop
>>>
>>>
>>Same as above.
>>
>>
>Except that the Perl5 equivalent, ugly as the syntax may be, works fine:
>
> pop @{[@a,@b,@c]}
>
>It creates an anonymous array, then removes the last element, leaving two
>elements in the array - which is irrelevant since the array is
>then discarded completely.
>
>I don't see any reason to change this behavior for Perl6.
>
Apologies; when I meant "same as above", I meant "same answer that I gave
for:
>>>> [1..10].map {...
>>>I think this *should* work, although I'm not sure *how*.
Meaning that "I think this should be possible, but I'm not
sure if that syntax is correct, because it would mean that
the arrayrefs would need to be their own class to allow
a method to be called on it, and this class would need to be
a wrapper around the real array class".
Re-reading my original message, I can see the reason for
the confusion. In fact, I don't even know what I was thinking
when I thought people would make that connection that I wanted,
as it doesn't even make sense to me now :-)
Hmm... now that I think more about it, making array references
their own class and wrapping it around the real array
class would make it pretty easy to cause all of the "auto
dereferencing when necessary" behaivor that is causing
so many problems, since auto-dereferencing wouldn't have to
happen, it would only seem that way.
Does this sound feasible?
Joseph F. Ryan
ryan...@osu.edu
Mark J. Reed
> Meaning that "I think this should be possible, but I'm not
> sure if that syntax is correct, because it would mean that
> the arrayrefs would need to be their own class to allow
No, they wouldn't, unless I'm missing something. All methods are
called via references, right? So [@a,@b,@c].pop automatically
invokes Array#pop with the invocant as the anonymous array. In fact,
the only reason @foo.pop works is because @foo automatically
"referencizes" in scalar context.
Michael Lazzaro
On Tuesday, February 11, 2003, at 04:56 PM, Deborah Ariel Pickett
wrote:
>> But is it OK for a list to be silently promoted to an array when used
>> as an array? So that all of the following would work, and not just
>> 50%
>> of them?
>> (1..10).map {...}
>> [1..10].map {...}
>
> And somehow related to all this . . .
<snip>
> I think some of this is in A2, but not all of it.
Here are some of the answers from my own notes. These behaviors have
all been confirmed on-list by the design team:
An @array in list context returns a list of its elements
An @array in scalar context returns a reference to itself (NOTE1)
An @array in numeric (scalar) context returns the number of elements
An @array in string (scalar) context returns a join of its elements
An $arrayref in list context returns an arrayref (NOTE2)
An $arrayref in scalar context returns an arrayref
An $arrayref in numeric (scalar) context returns ??? (NOTE3)
An $arrayref in string (scalar) context returns ???
Note that that's pretty consistent with how it works now.
(NOTE1): This is the big change. It's what allows us to treat arrays
as objects, and call methods on them like @array.length. I don't think
anyone will argue that's not a good thing.
(NOTE2): Note that this is a non-change. If we changed it so that an
arrayref flattened itself in array context, you could never have
complex data structures, because [[1,2],[3,4]] would always be the same
as [1,2,3,4].
(NOTE3): I have not been able to find explicitly confirmed behaviors
for these two. It has been implied that they return $arrayref.length
and $arrayref.string (or whatever those methods are called). Maybe.
--- List Flattening ---
The confusing behavior is, of course, that the list
(@a,@b,@c)
is seen as being treated differently in different syntactic contexts.
In the case of:
sub foo(@p1,@p2,@p3);
&foo(@a,@b,@c);
the arrays @a, @b, and @c are NOT flattened, but are passed as @p1,
@p2, and @p3. Likewise, in:
my(@d,@e,@f) := (@a,@b,@c);
the same is true. But in ALL other circumstances, like
my(@d,@e,@f) = (@a,@b,@c);
an array in list context simply returns it's elements, such that @d =
(@a,@b,@c), @e=(), @f=(). So what's the deal?
My own two-sentence explanation for why this is is that in the first
two examples, C<sub> and C<:=>, you're binding one variable to another,
NOT dealing with the array-ness of those variables at all. E.G.
@a := @b
makes @a refer to the same array object as @b refers to, whereas
@a = @b
simply says to copy all elements _contained within_ @b into @a. So
it's not that arrays are behaving differently in different situations,
because they're NOT... the same rules always apply. It's just that
C<sub> and C<:=> are specific, binding-style operations... they do the
same thing for scalar variables, too.
There, how convincing did that sound?
MikeL
Erik Steven Harrison
--
On Tue, 11 Feb 2003 12:28:23
Luke Palmer wrote:
>> Date: Tue, 11 Feb 2003 10:34:57 -0800
>> From: Michael Lazzaro <mlaz...@cognitivity.com>
>>
>> On Monday, February 10, 2003, at 05:56 PM, Luke Palmer wrote:
>> > Indeed, this supports the distinction, which I will reiterate:
>> >
>> > - Arrays are variables.
>> > - Lists are values.
>>
>> My hesitation about the 'arrays are variables' part is that Damian
>> corrected me on a similar thing when I was writing about scalars. A
>> variable is more like "a name of a container for a value", e.g. there's
>> three parts to it:
>>
>> - the name (what it's called in the namespace)
>> - the container (a specific container implementation)
>> - the value (what's inside it)
>>
Maybe I'm confused about why there is
confusion. An array is an object (in fact
all containers are objects, or
implementations thereoff). We can call
methods on it, and dispatch functions
differently based on it's type - which is
why we can treat lists and arrays
differently.
A list is not a object - it is a value,
immutable. It is the data that the array
object wraps around.
The name @array names arrays which Perl can
autovivify. The '@' is part of it's name. If
Perl sees a name begining with @ is hasn't
seen before is creates the array object
automatically. So
@array = (1,2,3,4);
really means
@array := Array.new (1,2,3,4)
or possibly (treating = as an overloaded
operator on the type Array)
(@array := Array.new) = (1,2,3,4)
the commas being operators which construct
the list value.
Or am I confused?
-Erik
>> So I don't know that arrays are variables, so much as arrays are
>> containers, if we want to get pedantic about it (which I don't, but...
>> documentation... sigh).
>
>Well, that doesn't assume the definition of the variable includes a
>namespace entry. So, yes, I suppose container would be better. The
>thing the namespace entry points to, but not the value.
>
>> Just to clarify... in P6, is this an array reference, or a list
>> reference?
>>
>> [1,2,3]
>>
>> What about this?
>>
>> \@array
>>
>> I'd say both of them are array references, but there's no variable
>> associated with the first one
>
>I'd agree.
>
>> -- it's just an anonymous container. So I'd rewrite the definition
>> to:
>>
>> - Lists are an ordered collection of scalar values
>> - Arrays are containers that store lists
>
>I think that's a pretty good one.
>
>> (Coupled with Uri's explanations, of course... it's the 'container'
>> part that allows read/write, as opposed to simply read.) Yes/no?
>
>Yes, from my perspective, the container is the one that knows
>read/write. Basically, the only you can't modify lists is that they
>have no operations defined that can modify them. Arrays on the other
>hand, do.
>
>>
>> > Arrays are things that know about lists. They know how to get a
>> > particular element out of a list. They know how to *flatten
>> > themselves, interpolating themselves into the surrounding list. They
>> > know how to map, grep, sort, splice themselves. They know how to turn
>> > themselves into a scalar. Lists don't know how to do these things.
>>
>> But is it OK for a list to be silently promoted to an array when used
>> as an array? So that all of the following would work, and not just 50%
>> of them?
>>
>> (1..10).map {...}
>> [1..10].map {...}
>
>I don't really know here. I'm not sure whether this should work....
>I think if lists don't have the C<map> method, that shouldn't work.
>
>> (@a,@b,@c).pop
>> [@a,@b,@c].pop
>
>Why would you suppose the former to work? Or do you mean that to mean
>(@a.pop,@b.pop,@c.pop)? Can lists have methods?
>
>This clear distinction that I once had in my mind is getting blurrier
>and blurrier. :(
>
>Luke
>
____________________________________________________________
Get 25MB of email storage with Lycos Mail Plus!
Sign up today -- http://www.mail.lycos.com/brandPage.shtml?pageId=plus
Joseph F. Ryan
A I<literal> is a piece of data.
A I<scalar> is a variable that holds a literal.
A I<list> is a sequence of literals and scalars.
An I<array> is a variable that holds a list.
is the "Rvalue-assign list", which takes the form of:
($r1, $r2, $r3) = (1, 2, 3);
Well, what if an "Rvalue-assign list" is simply decoupled from
a normal "data list." The confusion would end. The concepts
themselves are separate, so why shouldn't the names be? "data
lists" become "The One True List Type", and "Rvalue-assign lists"
become something like "Rvalue sequences" (or a catchier name).
Peace would reign on earth, or at least p6-lang and p6-doc.
(I hope I'm not missing something obvious here, at any rate :)
Joseph F. Ryan
ryan.311@osu
Erik Steven Harrison
--
On Wed, 12 Feb 2003 18:29:29
Joseph F. Ryan wrote:
>As near as I can tell, the only problem with the nice flow of:
>
> A I<literal> is a piece of data.
> A I<scalar> is a variable that holds a literal.
>
> A I<list> is a sequence of literals and scalars.
> An I<array> is a variable that holds a list.
>
>is the "Rvalue-assign list", which takes the form of:
>
>($r1, $r2, $r3) = (1, 2, 3);
I don't see a problem here. The list on the right is still just
value, unmodifiable. It is a list of rvalues. When you use a variable
on the right hand side it is a rvalue. Similarly, a list of variables
doesn't flatten to it's values - it is the list itself that it is
immutable. It's individual members still retain asignibility in
rvalue context.
-Erik
>
>Well, what if an "Rvalue-assign list" is simply decoupled from
>a normal "data list." The confusion would end. The concepts
>themselves are separate, so why shouldn't the names be? "data
>lists" become "The One True List Type", and "Rvalue-assign lists"
>become something like "Rvalue sequences" (or a catchier name).
>Peace would reign on earth, or at least p6-lang and p6-doc.
>
>(I hope I'm not missing something obvious here, at any rate :)
>
>
>Joseph F. Ryan
>ryan.311@osu
>
>
Erik Steven Harrison
--
On Wed, 12 Feb 2003 17:14:17
Erik Steven Harrison wrote:
>
>--
>
>On Wed, 12 Feb 2003 18:29:29
> Joseph F. Ryan wrote:
>>As near as I can tell, the only problem with the nice flow of:
>>
>> A I<literal> is a piece of data.
>> A I<scalar> is a variable that holds a literal.
>>
>> A I<list> is a sequence of literals and scalars.
>> An I<array> is a variable that holds a list.
>>
>>is the "Rvalue-assign list", which takes the form of:
>>
>>($r1, $r2, $r3) = (1, 2, 3);
>
>I don't see a problem here. The list on the right is still just
>value, unmodifiable. It is a list of rvalues. When you use a variable
>on the right hand side it is a rvalue. Similarly, a list of variables
>doesn't flatten to it's values - it is the list itself that it is
>immutable. It's individual members still retain asignibility in
>rvalue context.
Okay, pardon me for replying to myself, but that was _really_ badly
worded. An example
foreach ($foo, $bar, $baz) {
.zoomdingle;
}
The objects in the list retain full status qua objects even though
they are in a list, which is why we can call methods on them.
Similarly, the fact that a scalar variable acts as a value on the
lefthand side and a rvalue on the right hand side is retained even
though it is in a list. It is the list itself which is immutable.
Python programmers will grasp this real fast - it's just a tuple.
-Erik
Deborah Ariel Pickett
> all been confirmed on-list by the design team:
>
> An @array in list context returns a list of its elements
> An @array in scalar context returns a reference to itself (NOTE1)
> An @array in numeric (scalar) context returns the number of elements
> An @array in string (scalar) context returns a join of its elements
>
> An $arrayref in list context returns an arrayref (NOTE2)
> An $arrayref in scalar context returns an arrayref
> An $arrayref in numeric (scalar) context returns ??? (NOTE3)
> An $arrayref in string (scalar) context returns ???
>
> Note that that's pretty consistent with how it works now.
>
> (NOTE1): This is the big change. It's what allows us to treat arrays
> as objects, and call methods on them like @array.length. I don't think
> anyone will argue that's not a good thing.
>
> (NOTE2): Note that this is a non-change. If we changed it so that an
> arrayref flattened itself in array context, you could never have
> complex data structures, because [[1,2],[3,4]] would always be the same
> as [1,2,3,4].
>
> (NOTE3): I have not been able to find explicitly confirmed behaviors
> for these two. It has been implied that they return $arrayref.length
> and $arrayref.string (or whatever those methods are called). Maybe.
A %hash in list context returns a list of its pairs (NOTE4)
A %hash in scalar context returns a reference to itself (NOTE1)
A %hash in numeric (scalar) context returns (?)
A %hash in string (scalar) context returns (?)
A $hashref in list context returns a hashref (NOTE2)
A $hashref in scalar context returns a hashref
A $hashref in numeric (scalar) context returns (?)
A $hashref in string (scalar) context returns (?)
(NOTE4): Or is it a flattened list of key-values?
And how would it extend to the finer-grained contexts we're getting in
Perl6 (integer numeric scalar context, hashref context, ...)? Our
complete list of contexts now is quite a hierarchy.
> --- List Flattening ---
> My own two-sentence explanation for why this is is that in the first
> two examples, C<sub> and C<:=>, you're binding one variable to another,
> NOT dealing with the array-ness of those variables at all. E.G.
[...]
> There, how convincing did that sound?
Pretty convincing. In fact, it sounds like this "binding" mode is
nothing more than another facet of context (i.e., difference in meaning
imposed by surrounding code). Sort of like this:
An @array in nonbinding list context returns a list of its elements.
An @array in binding list context returns the symbol table reference for
itself
An @array in nonbinding scalar context returns a reference to itself.
An @array in binding scalar context returns the symbol table reference for
itself
Would that fly? If so, I'd expect the new generic want() operator to be
able to detect it.
--
Debbie Pickett http://www.csse.monash.edu.au/~debbiep deb...@csse.monash.edu.au
"Games people play, you take it or you leave it, things that they say just don't
make it right. If I'm telling you the truth right now, do you believe it? Games
people play in the middle of the night." - _Games People Play_, APP
Joseph F. Ryan
>
>--
>
>On Wed, 12 Feb 2003 18:29:29
> Joseph F. Ryan wrote:
>
>
>>As near as I can tell, the only problem with the nice flow of:
>>
>>A I<literal> is a piece of data.
>>A I<scalar> is a variable that holds a literal.
>>
>>A I<list> is a sequence of literals and scalars.
>>An I<array> is a variable that holds a list.
>>
>>is the "Rvalue-assign list", which takes the form of:
>>
>>($r1, $r2, $r3) = (1, 2, 3);
>>
>>
>
>I don't see a problem here. The list on the right is still just
>value, unmodifiable. It is a list of rvalues. When you use a variable
>on the right hand side it is a rvalue. Similarly, a list of variables
>doesn't flatten to it's values - it is the list itself that it is
>immutable. It's individual members still retain asignibility in
>rvalue context.
>
>-Erik
>
>
Ah, I'm a compete fool. I meant Lvalue, not Rvalue. If you could do
a mental s:e/Rvalue/Lvalue on that last message, I would appreciate it.
Joseph F. Ryan
ryan...@osu.edu
Joseph F. Ryan
You're completely right. See my last message :-)
Joseph F. Ryan
ryan...@osu.edu
Erik Steven Harrison
Michael Lazzaro
On Wednesday, February 12, 2003, at 05:50 PM, Deborah Ariel Pickett
wrote:
> All right, I'm prepared to buy that. Now how would it extend to
> hashes?
>
> A %hash in list context returns a list of its pairs (NOTE4)
> A %hash in scalar context returns a reference to itself (NOTE1)
> A %hash in numeric (scalar) context returns (?)
> A %hash in string (scalar) context returns (?)
>
> A $hashref in list context returns a hashref (NOTE2)
> A $hashref in scalar context returns a hashref
> A $hashref in numeric (scalar) context returns (?)
> A $hashref in string (scalar) context returns (?)
>
> (NOTE4): Or is it a flattened list of key-values?
As far as NOTE4, I don't think they've decided yet. At least, I can't
seem to find confirmation of it.
One possibility for the (?) part is of course that numeric context
returns the number of keys, and that string context returns a
pretty-printed list of key => value pairs. That would seem the most
obvious answer, but it might not be the right one. We have to get that
verified too.
> And how would it extend to the finer-grained contexts we're getting in
> Perl6 (integer numeric scalar context, hashref context, ...)? Our
> complete list of contexts now is quite a hierarchy.
Yeah, I'm waiting eagerly for A6 to talk about that, but it shouldn't
be too hard. Certainly, context seems to be a simple tree. So 'want'
can return true for multiple things...
my int $i = foo();
...
# now inside foo:
want scalar; # true
want numeric; # true
want int; # true
want str; # false
I've been told with great consistency that there's not really going to
be complete, typedef-style contexts... e.g., you'll be able to tell
"hash" context, but you won't be able to tell the difference between
"hash of ints" and "hash of strs" context. Which is a shame, IMO,
since multimethods could benefit from as much info as possible, but
we'll see what they come up with.
> An @array in nonbinding list context returns a list of its elements.
> An @array in binding list context returns the symbol table reference
> for
> itself
> An @array in nonbinding scalar context returns a reference to itself.
> An @array in binding scalar context returns the symbol table reference
> for
> itself
>
> Would that fly? If so, I'd expect the new generic want() operator to
> be
> able to detect it.
Huh, I never really thought of it that way, but I suppose it would have
to be something like that. So you can overload the binding operator
C<:=>...
MikeL
David Storrs
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?
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?
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] => $_});
4) Also spiffy would be if we could make lists auto-hyper their
elements:
@a = (1, 2, 3) + 7;
# same as @a = (1, 2, 3) >>+<< 7;
# might need to be @a = (1, 2, 3).+ 7;
Ok, I will now sit back and listen to reasons why this is a bad
idea. :>
--Dks
Luke Palmer
> From: David Storrs <dst...@dstorrs.com>
>
> 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.
> 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.
Also, don't worry about implementation. That's p6i's job.
> 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.
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.
Luke
Smylers
> 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.
What about making that a fatal error? If it doesn't do anything
sensible -- and if all the suggested outcomes it _could_ have can each
be achieved in more sensible ways -- then why should it do anything at
all?
Perl 6 sounds like it's going to be complicated enough already, so I'm
strongly in us limiting new features to those that come about through a
desire for particular functionality rather than a desire to use up some
'spare' syntax ...
Smylers
Smylers
> ... I'm strongly in us limiting new features to those that come about
Um, try "I'm strongly in favour of limiting" etc.
> through a desire for particular functionality rather than a desire to
> use up some 'spare' syntax ...
Sorry about that.
Smylers
David Storrs
> > Date: Fri, 14 Feb 2003 12:38:59 -0800
> > From: David Storrs <dst...@dstorrs.com>
> >
> > 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
Michael Lazzaro
On Saturday, February 15, 2003, at 08:47 AM, David Storrs wrote:
> 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.
IMHO the only reasonable possibilities are (2) or (3)... the others are
much rarer in practice, and too prone to
accidental-invocation-with-baffling-results.
Agreed, however, that (2) is icky. My worry has been that removing
C-comma behavior would break common constructs, but I haven't been able
to find any that would really break (except obfuscated ones that would
be better written in some other fashion anyway.) Statements like:
foo() or (warn("blah"), next);
work either way, because they don't rely on getting the "scalar value"
of the list.
So, IMO, the only reasonable answer is (3)... that a list in numeric
context returns the length. Thus we have consistency between lists and
arrays:
(1,2,3) + 4 # --> (1,2,3).length + 4 --> 7 (list)
[1,2,3] + 4 # --> [1,2,3].length + 4 --> 7 (array ref)
my @a = (1,2,3); #
@a + 4 # --> @a.length + 4 --> 7 (array var)
*@a + 4 # --> (*@a).length + 4 --> 7 (list)
(@a,@a) + 4 # --> 3 + 3 + 4 --> 10 (list)
Alternatively, we could say that using a list in numeric context is a
syntax error. This is fine w/ me as well, but pointedly *doesn't*
match the array behavior... and would mean the second to last line
would also be a syntax error.
I think the consistency of behavior probably means (3) wins.
MikeL
Smylers
> So, IMO, the only reasonable answer is (3)... that a list in numeric
> context returns the length. Thus we have consistency between lists
> and arrays:
>
> (1,2,3) + 4 # --> (1,2,3).length + 4 --> 7 (list)
> [1,2,3] + 4 # --> [1,2,3].length + 4 --> 7 (array ref)
>
> my @a = (1,2,3); #
> @a + 4 # --> @a.length + 4 --> 7 (array var)
> *@a + 4 # --> (*@a).length + 4 --> 7 (list)
> (@a,@a) + 4 # --> 3 + 3 + 4 --> 10 (list)
>
> Alternatively, we could say that using a list in numeric context is a
> syntax error. This is fine w/ me as well, but pointedly *doesn't*
> match the array behavior...
I think having them doing different things is reasonable -- they _are_
different. An array is something tangible and as such can have
operations on it. A list is something ephemeral, some scalars that
happen to be together right now but don't have a collective identity.
There can be operations on each of the individual items in a list but
having an operation on them as a group seems odd to me.
More practically, the length of a list is never interesting: a list by
definition must be hardcoded into the program so its length is known at
compile time. Indeed it should be known by whoever typed it in!
> and would mean the second to last line would also be a syntax error.
That seems fine by me. I can't see any reason why somebody would type
that rather than the version on the line above.
> I think the consistency of behavior probably means (3) wins.
Why should different things behave in the same way?
More pragmatically, somebody who has code with an explicitly hardcoded
list which is used in scalar context has probably made a mistake --
there are so many better ways (to take the above example) of hardcoding
the constant 7 into a program! Why would somebody write out each
element of a list just to throw away most of the data and reduce it to
an integer?
In the case where somebody has made an error -- either a typo, or a
conceptual error by somebody still learning the language -- it's much
more useful to have a compilation error than for the code run but not
yield the desired behaviour.
Can somebody come up with a realistic example of where having a list be
interpreted as its length is genuinely useful and isn't more easily
written using some other syntax?
Smylers
Deborah Ariel Pickett
> > 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".
> Agreed, however, that (2) is icky. My worry has been that removing
> C-comma behavior would break common constructs, but I haven't been able
> to find any that would really break (except obfuscated ones that would
> be better written in some other fashion anyway.) Statements like:
> foo() or (warn("blah"), next);
> work either way, because they don't rely on getting the "scalar value"
> of the list.
One thing that the C comma operator promises is that its left operand
(and all side effects) is completely evaluated before work starts on the
right operand. (This may not be strictly true in the Perl interpretation
of the operator; can a Perl5 developer comment?)
I'm pretty sure that for a Perl list, the order of evaluation of
elements isn't guaranteed, meaning that C<next> may evaluate before
C<warn> in the above example if it were treated exactly like a list.
(Again, can someone refute or support this?)
That said, I don't know of anything that the C comma operator can do
that you couldn't equivalently do with a Perl5 C<do> statement:
foo() or (do { warn("blah"); next; }); # Yes, it's ugly.
So I too support the notion that comma should always and only be a list
constructor.
--
Debbie Pickett http://www.csse.monash.edu.au/~debbiep deb...@csse.monash.edu.au
Chaos, panic, & disorder - my work here is done. - button slogan
Dave Mitchell
> More practically, the length of a list is never interesting: a list by
> definition must be hardcoded into the program so its length is known at
> compile time. Indeed it should be known by whoever typed it in!
Err, no. Eg in perl 5:
$value = (1,2, @ARGV,3,4)[$i]
That's a list, and its length is not known at compile time.
Dave.
--
Nothing ventured, nothing lost.
David Storrs
> That said, I don't know of anything that the C comma operator can do
> that you couldn't equivalently do with a Perl5 C<do> statement:
>
> foo() or (do { warn("blah"); next; }); # Yes, it's ugly.
Or just a Boolean:
foo() or (warn("blah") && next; );
--Dks
Stephen McCamant
writes:
DP> One thing that the C comma operator promises is that its left
DP> operand (and all side effects) is completely evaluated before work
DP> starts on the right operand. (This may not be strictly true in
DP> the Perl interpretation of the operator; can a Perl5 developer
DP> comment?)
It's a matter of some controversy exactly what "promises" with regards
to order of operation Perl5 provides. Unlike C, there's no separate
standard describing what Perl should do: just an implementation, and
some documentation.
As a matter of implementation, I believe both scalar and list comma
operators have always evaluated their arguments from left to right.
(This also applies to the comma separating sub arguments, if you count
that separately from list comma).
As for documentation, both the POD and the Camel book use language
that strongly suggests left-to-right evaluation for the scalar comma
("it evaluates its left argument, throws that value away, then
evaluates its right argument and returns that value") as well as
referring to it as "just like" the C comma. By contrast, they don't
say anything directly about the evaluation order of the list comma.
On the other hand, there is the following example from perldata (I
can't find it in the Camel, but I can't grep the Camel):
# A "reverse comma operator".
return (pop(@foo),pop(@foo))[0];
which only makes sense if list comma is guaranteed to evaluate left to
right.
DP> I'm pretty sure that for a Perl list, the order of evaluation of
DP> elements isn't guaranteed, meaning that C<next> may evaluate
DP> before C<warn> in the above example if it were treated exactly
DP> like a list. (Again, can someone refute or support this?)
[The example again is 'foo() or (warn("blah"), next);']
Note that neither argument to "or" can be a list, so that comma isn't
a list comma. It's actually in a void context there, so it's a scalar
comma. (The rule "void context is a kind of scalar context" seems
rather arbitrary in the abstract, and the reasons for it are at least
partially historical, but it does seem to me to give the right answer
here).
-- Stephen
Smylers
> On Tue, Feb 18, 2003 at 10:06:29PM -0000, Smylers wrote:
>
> > More practically, the length of a list is never interesting: a list
> > by definition must be hardcoded into the program so its length is
> > known at compile time.
>
> Err, no. Eg in perl 5:
>
> $value = (1,2, @ARGV,3,4)[$i]
>
> That's a list, and its length is not known at compile time.
Ooops, yes. I was overstating the case that a list's length must be
known at compile time. But I'd still maintain that the length isn't
interesting. In your example you are picking out a particular element,
which is reasonable and I've got no objection with that.
What I don't understand is why a list in numeric context should yield
its length, and that still applies to your example. There's no
advantage in doing:
$length = 1 + (1, 2, @ARGV, 3, 4);
over the much more straightforward:
$length = 5 + @ARGV;
Smylers
Luke Palmer
> That said, I don't know of anything that the C comma operator can do
> that you couldn't equivalently do with a Perl5 C<do> statement:
>
> foo() or (do { warn("blah"); next; }); # Yes, it's ugly.
Well, gee, it's not that ugly:
foo or do { warn "blah"; next };
Stripping off all unneeded parentheses. C<do> is a little redundant:
foo or { warn "blah"; next }();
And what if, something like m//, closures based whether they evaluate
on context. i.e. they I<would> evaluate in void context. Then we
have completely redundantized the C comma:
foo or { warn "blah"; next };
loop ({ $i=0; $j=20 }; $i <= 10 < $j; { $i++; $j-- }) {...}
When it wouldn't evaluate because of context, there's still C<do> and
() to do the trick.
Assuming you can do control flow from within a closure. Hmm... that
makes me cringe a bit. Oh, look, you can do it in Perl 5, though.
But I think all of us already agreed that the C comma is not
needed.
Luke
Martin D Kealey
> What is the utility of the perl5 behavior:
>
> \($a,$b,$c)
>
> meaning
>
> (\$a, \$b, \$c)
>
> Do people really do that? ... Can someone give an example of an actual,
> proper, use?
Yes, I've used it like this:
for (\($a,$b,$c)) {
$$_++;
}
to be sure that it works on all versions, since
for ($a,$b,$c) {
$_++;
}
works differently on different versions. (Actually, I don't have an
old-enough version on hand to check just when that was, so it must have been
5.004 or before.)
This change didn't start to bite me until P5.6.0, when "values %HASH" became
an Lvalue too, whereupon
for ( values %HASH ) {
s/^prefix//;
...
}
... do something else with %HASH
stopped working.
So, I would urge making as many things as possible Lvalues (and magical
references) right from the start of P6, just so as we don't break things by
making them so later.
-Martin
--
Help Microsoft stamp out software piracy: give Linux to a friend today...
Martin D Kealey
I would like to chip in in favour of the "list is value, array is container"
side of the argument. However I think that needs clarifying.
A reference is a value; the thing it refers to is a container.
An anonymous container is a container with no references from any symbol
table. It can lose its anonymity by creating such a reference.
A list is an ordered set of references to (normally anonymous) containers.
An array is a container that contains a list. When created, an array
contains the empty list. The operations push, pop, shift, unshift, extend,
truncate and element auto-vivify replace the value in the array with another
value similar to the old one. Assignment replaces the value in the array
with an entirely new value.
Operations on individual elements of an array do not affect the value of the
array, just the values in the containers that the array's list members refer
to.
Possible definition:
Except for "obvious" arrays and hashes (those involving "@" or "%" in the
expression), anything evaluated inside a list in R-value context is itself
in reference context. Named arrays and hashes are in
flatten-to-reference-to-member context. Anything evaluated inside a list in
Lvalue context is itself in reference context. Assignment to a list
deferences successive elements of each side. Passing a list as parameters
dereferences each element unless the prototype says otherwise.
Almost all of these containers are either elidable at compile time, or will
be needed "soon" anyway -- eg, as elements in the formal parameter list; so
there's no practical cost to this definition.
On a related topic...
I like to be able to program in a "pure functional" mode as much as
possible, mainly because it's the easiest to prove correctness, but also
because it also offers the greatest scope for compile-time optimisation.
What I would like is for the language to enable as many compile-time
optimisations as possible, by making the optimisation-friendly choices the
shorter easy-to-type defaults.
One of those, rather inobviously, is choosing pass-by-value rather than
pass-by-reference. And rather deeper pass-by-value than the sort of list
I've talked about above: a list would be a set of actual values, not a set
of references to containers containing values. And we could extend this
to things other than arrays/lists.
It's important to understand that I'm talking about the semantics of the
language, not the implementation. The point is that the implementation is
still free to pass by reference when it can be sure that the receiving
function won't fiddle with it. That can be guaranteed if you can see (or
infer) all the way down to the leaf function calls at compile time. (This
gets complicated at trust boundaries, but we can work on that.)
One of the things I found most irksome moving from C++ to Java was that Java
took away both "pass object by value" AND "pass object by const reference".
Couple that with some rather bad choice of "value" vs "container" in the
standard class library, and the result was that one had no way to be sure
that an object wouldn't get modified once you handed a it over as a
parameter or referent to some random method.
Since then languages such as ECMAscript have copied that behaviour, and it
seems that P6 is looking more and more like a clone of that language ... and
that worries me.
I would like to argue in favour of "pass by value" to be the default in the
absence of some explicit prototype, because it allows greater type-safety,
and because the opposite default interacts badly with out-of-order execution
such as parallelism, and bars some optimisations that can be applied to
closures. (We do want Perl to run fast on parallel hardware, don't we?)
The relationship to the array/list thing is this: that it's not just
pass-by-value to functions and methods, it's about implicit R-valueness in
any context that doesn't absolutely require L-valueness.
All this is orthogonal to the concept of "object": in C++ "an object" can be
used to implement either a value (such as "string") or a container (such as
"vector"); it would be nice to be able to do this in P6 too.
-Martin
PS: sorry for the long post...
Nicholas Clark
> I would like to argue in favour of "pass by value" to be the default in the
> absence of some explicit prototype, because it allows greater type-safety,
> and because the opposite default interacts badly with out-of-order execution
> such as parallelism, and bars some optimisations that can be applied to
> closures. (We do want Perl to run fast on parallel hardware, don't we?)
Based on what I remember of reading apocalpyses 1 to 5 and messages on this
list, perl6 intends to pass by value by default.
> PS: sorry for the long post...
No need to apologise. Thanks for the informative, well thought out and well
reasoned post.
Nicholas Clark
Luke Palmer
> > I would like to argue in favour of "pass by value" to be the
> > default in the absence of some explicit prototype, because it
> > allows greater type-safety, and because the opposite default
> > interacts badly with out-of-order execution such as parallelism,
> > and bars some optimisations that can be applied to closures. (We
> > do want Perl to run fast on parallel hardware, don't we?)
>
> Based on what I remember of reading apocalpyses 1 to 5 and messages
> on this list, perl6 intends to pass by value by default.
No, default is constant reference, from Apocalypse 4, under RFC 89.
Well, it's constant reference for I<declared> parameters. When you
don't give a parameter list, @_ is bound to the argument list with
mutable reference elements, to make it as much like Perl 5 as
possible. But you shouldn't use that form anyway, because it's
archaic and ugly.
And I don't see how making parameters passed by constant reference is
slow. If you're writing very close to "pure functional" like you say,
you shouldn't be modifying your parameters anyway. And constant
reference may have a few consequences with threading that are absent
with by-value if you're not aware of the semantics, but it is a much,
much better default for single threaded programs. I suspect 90% of
Perl 6 programs will be single threaded.
If you want to modify a parameter in place, you declare with C<is rw>.
If you want to pass by-value, there might be a property for that, but
I think this was recommended:
sub foo($bar_) {
my $bar = $bar_; # Copy, not bind
# ... with $bar
}
Luke
Allison Randal
> If you want to modify a parameter in place, you declare with C<is rw>.
> If you want to pass by-value, there might be a property for that, but
> I think this was recommended:
>
> sub foo($bar_) {
> my $bar = $bar_; # Copy, not bind
> # ... with $bar
> }
In the design meetings early this month we added C<is copy> for true
pass-by-value.
sub foo($bar is copy) {
...
}
There's a nice explanation of it in A6, which will be coming out fairly
soon now.
Allison
Simon Cozens
> In the design meetings early this month we added C<is copy> for true
> pass-by-value.
Can someone please compile a list of all the "is foo" properties that
have been suggested/accepted as being pre-defined by the language?
I can't keep track of them all.
--
So what if I have a fertile brain? Fertilizer happens.
-- Larry Wall in <2000021219...@kiev.wall.org>
Paul Johnson
Yes, I've never found anything explicitly defining the order of
evaluation of the comma operator in list context, but as you suggest
there are examples from the perl documentation, the core, its tests and,
of course, CPAN which all make use of the left to right ordering.
For example,
select((select(OUTPUT_HANDLE), $| = 1)[0]);
which is (was?) a fairly common idiom, is documented, used in core
modules and tested. I suspect that a lot would break if the order of
evaluation changed. And I think it would be sensible for Perl 6 to
define such an order.
--
Paul Johnson - pa...@pjcj.net
http://www.pjcj.net
Larry Wall
: I suspect that a lot would break if the order of
: evaluation changed. And I think it would be sensible for Perl 6 to
: define such an order.
Certainly. The fact that Perl 5 doesn't define it is merely an
oversight, brought on no doubt by a lack of oversight. But as
you point out it can deduced by observation of all the various
implementations of Perl. :-)
Larry