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

--- Michael Lazzaro <mlazz...@cognitivity.com> wrote:

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

On 2003-02-07 at 11:13:07, Austin Hastings wrote:

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.r...@cnn.com
Atlanta, GA 30348      USA   | +1 404 827 4754

On 2003-02-07 at 14:26:42, Mark J. Reed wrote:
Forgot the parens on the right side, there:

        ($a, $b, $c) = (1,2,3);

         [$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.

--
Mark REED                    | CNN Internet Technology
1 CNN Center Rm SW0831G      | mark.r...@cnn.com
Atlanta, GA 30348      USA   | +1 404 827 4754

--- "Mark J. Reed" <mark.r...@turner.com> wrote:

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.

But could you do it the other way (function instead of method)?

pop (1,2,3) => ?

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

On 2003-02-07 at 12:18:21, Austin Hastings wrote:

Nope.  At least, not in Perl 5:

        Type of arg 1 to pop must be array (not list)

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

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

--
Mark REED                    | CNN Internet Technology
1 CNN Center Rm SW0831G      | mark.r...@cnn.com
Atlanta, GA 30348      USA   | +1 404 827 4754

  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

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

  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.

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

news:04336C89-3AEE-11D7-B6E4-00050245244A@cognitivity.com...

quibble: that's an "ordered bag", isn't it?  ;)

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.

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

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

  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.

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

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.

Not quite: ($a, $b, $c) = 1..3;

Z.

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

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

  AT> On Fri, Feb 07, 2003 at 06:38:36PM -0500, Uri Guttman wrote:
  >> >>>>> "ML" == Michael Lazzaro <mlazz...@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. :)

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

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 debb...@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_

Like what?

I don't understand the difference here.  Could you elaborate?

Where s/parser/compiler/, and s/interpretter/runtime engine/?  I
do believe that's accurate.

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

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

See above.

What joy I'll have explaining that one to my students . . .

--
Debbie Pickett http://www.csse.monash.edu.au/~debbiep debb...@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_

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

Actually, I think they'll be more separated.  In fact, the compiler will
just be an extension to the runtime-engine.

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

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

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.

Better you than me. :-)

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

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?

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

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?

Groan.  Yeah.  I feel your pain.  :-|

MikeL

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.

I'd agree.

I think that's a pretty good one.

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.

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.

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