> >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 . . .
--
Debbie Pickett http://www.csse.monash.edu.au/~debbiep [EMAIL PROTECTED]
"Oh, she's got it bad." "What? What has she got?" "Isn't it obvious, Daddy?
Ariel's in *love*." - _The Little Mermaid_
