Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Arrays vs. Lists

53 views
Skip to first unread message

Michael Lazzaro

unread,
Feb 7, 2003, 1:52:41 PM2/7/03
to perl6-l...@perl.org

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

unread,
Feb 7, 2003, 2:13:07 PM2/7/03
to Michael Lazzaro, perl6-l...@perl.org

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

unread,
Feb 7, 2003, 2:26:42 PM2/7/03
to perl6-l...@perl.org
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;

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

unread,
Feb 7, 2003, 2:30:47 PM2/7/03
to perl6-l...@perl.org
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:
>
> ($a, $b, $c) = 1,2,3;
Forgot the parens on the right side, there:

($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

unread,
Feb 7, 2003, 3:18:21 PM2/7/03
to Mark J. Reed, perl6-l...@perl.org

--- "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

unread,
Feb 7, 2003, 4:31:37 PM2/7/03
to perl6-l...@perl.org

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) => ?
Nope. At least, not in Perl 5:

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

unread,
Feb 7, 2003, 5:07:59 PM2/7/03
to Mark J. Reed, perl6-l...@perl.org
>>>>> "MJR" == Mark J Reed <mark...@turner.com> writes:

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

unread,
Feb 7, 2003, 5:46:37 PM2/7/03
to perl6-l...@perl.org

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

unread,
Feb 7, 2003, 6:38:36 PM2/7/03
to Michael Lazzaro, perl6-l...@perl.org
>>>>> "ML" == Michael Lazzaro <mlaz...@cognitivity.com> writes:

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

unread,
Feb 7, 2003, 6:57:41 PM2/7/03
to perl6-l...@perl.org
"Michael Lazzaro" <mlaz...@cognitivity.com> wrote in message
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

unread,
Feb 7, 2003, 7:14:32 PM2/7/03
to Uri Guttman, perl6-l...@perl.org

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

unread,
Feb 7, 2003, 2:55:52 PM2/7/03
to Mark J. Reed, perl6-l...@perl.org
On Fri, Feb 07, 2003 at 02:30:47PM -0500, Mark J. Reed wrote:
> 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

unread,
Feb 7, 2003, 7:24:55 PM2/7/03
to Michael Lazzaro, perl6-l...@perl.org
>>>>> "ML" == Michael Lazzaro <mlaz...@cognitivity.com> writes:

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

unread,
Feb 7, 2003, 8:25:14 PM2/7/03
to Uri Guttman, Michael Lazzaro, perl6-l...@perl.org
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.

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

unread,
Feb 7, 2003, 8:55:17 PM2/7/03
to mlaz...@cognitivity.com, perl6-l...@perl.org
> Date: Fri, 7 Feb 2003 14:46:37 -0800
> 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

unread,
Feb 7, 2003, 9:04:33 PM2/7/03
to Uri Guttman, perl6-l...@perl.org

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

unread,
Feb 7, 2003, 11:05:05 PM2/7/03
to Adam Turoff, Michael Lazzaro, perl6-l...@perl.org
>>>>> "AT" == Adam Turoff <zi...@panix.com> writes:

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

unread,
Feb 9, 2003, 8:28:34 PM2/9/03
to Michael Lazzaro, perl6-l...@perl.org

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

unread,
Feb 10, 2003, 1:13:40 AM2/10/03
to Deborah Ariel Pickett, perl6-l...@perl.org
Deborah Ariel Pickett 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?"
>>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

unread,
Feb 10, 2003, 7:15:13 PM2/10/03
to Joseph F. Ryan, perl6-l...@perl.org
> >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, 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

unread,
Feb 10, 2003, 8:56:03 PM2/10/03
to deb...@mail.csse.monash.edu.au, ryan...@osu.edu, perl6-l...@perl.org
> From: Deborah Ariel Pickett <deb...@mail.csse.monash.edu.au>
> 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

unread,
Feb 10, 2003, 9:26:45 PM2/10/03
to Deborah Ariel Pickett, perl6-l...@perl.org
Deborah Ariel Pickett wrote:

>>>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

unread,
Feb 11, 2003, 1:34:57 PM2/11/03
to Luke Palmer, deb...@mail.csse.monash.edu.au, ryan...@osu.edu, perl6-l...@perl.org
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).

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

unread,
Feb 11, 2003, 1:47:16 PM2/11/03
to Joseph F. Ryan, Deborah Ariel Pickett, perl6-l...@perl.org

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

unread,
Feb 11, 2003, 2:28:23 PM2/11/03
to mlaz...@cognitivity.com, deb...@mail.csse.monash.edu.au, ryan...@osu.edu, perl6-l...@perl.org
> 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)
>
> 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

unread,
Feb 11, 2003, 4:23:12 PM2/11/03
to perl6-l...@perl.org
>>>>> "Michael" == Michael Lazzaro <mlaz...@cognitivity.com> writes:

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

unread,
Feb 11, 2003, 5:12:52 PM2/11/03
to Michael Lazzaro, Luke Palmer, deb...@mail.csse.monash.edu.au, perl6-l...@perl.org
Michael Lazzaro wrote:

> 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

unread,
Feb 11, 2003, 5:44:08 PM2/11/03
to perl6-l...@perl.org

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

unread,
Feb 11, 2003, 5:58:57 PM2/11/03
to perl6-l...@perl.org

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. :)

Uri Guttman

unread,
Feb 11, 2003, 6:18:59 PM2/11/03
to Joseph F. Ryan, Michael Lazzaro, Luke Palmer, deb...@mail.csse.monash.edu.au, perl6-l...@perl.org
>>>>> "JFR" == Joseph F Ryan <ryan...@osu.edu> writes:

>> (@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

unread,
Feb 11, 2003, 7:52:36 PM2/11/03
to perl6-l...@perl.org

"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

unread,
Feb 11, 2003, 7:55:53 PM2/11/03
to perl6-l...@perl.org
"Michael Lazzaro" <mlaz...@cognitivity.com> wrote in message
news:3E2235CA-3DF1-11D7...@cognitivity.com...

> 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

unread,
Feb 11, 2003, 8:18:50 PM2/11/03
to Dave Whipp, perl6-l...@perl.org
Dave Whipp:
# > 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

unread,
Feb 11, 2003, 7:56:36 PM2/11/03
to perl6-l...@perl.org
> 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 . . .

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

unread,
Feb 12, 2003, 10:38:41 AM2/12/03
to perl6-l...@perl.org
That may be true in Perl6, but my example was in Perl5 - to demonstrate
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

unread,
Feb 12, 2003, 11:07:45 AM2/12/03
to Mark J. Reed, perl6-l...@perl.org
Mark J. Reed wrote:

>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

unread,
Feb 12, 2003, 11:36:25 AM2/12/03
to perl6-l...@perl.org
On 2003-02-12 at 11:07:45, Joseph F. Ryan wrote:
> 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.
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

unread,
Feb 12, 2003, 1:41:14 PM2/12/03
to Deborah Ariel Pickett, perl6-l...@perl.org

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

unread,
Feb 12, 2003, 3:22:38 PM2/12/03
to deb...@mail.csse.monash.edu.au, ryan...@osu.edu, perl6-l...@perl.org

--

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

unread,
Feb 12, 2003, 6:29:29 PM2/12/03
to Michael Lazzaro, perl6-l...@perl.org
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);

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

unread,
Feb 12, 2003, 8:14:17 PM2/12/03
to perl6-l...@perl.org

--

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

unread,
Feb 12, 2003, 8:26:25 PM2/12/03
to perl6-l...@perl.org, pu...@angelfire.com

--

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

unread,
Feb 12, 2003, 8:50:44 PM2/12/03
to Michael Lazzaro, perl6-l...@perl.org
> 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.

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?

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.

"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

unread,
Feb 13, 2003, 4:02:18 PM2/13/03
to pu...@angelfire.com, perl6-l...@perl.org
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.
>
>-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

unread,
Feb 13, 2003, 4:03:41 PM2/13/03
to pu...@angelfire.com, perl6-l...@perl.org
Erik Steven Harrison wrote:

You're completely right. See my last message :-)


Joseph F. Ryan
ryan...@osu.edu