L-valueness of Arrays vs. Lists
On Tue, 11 Feb 2003, Michael Lazzaro wrote:
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...
Re: Arrays vs lists; A possible solution?
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 Iliteral is a piece of data. A Iscalar is a variable that holds a literal. A Ilist is a sequence of literals and scalars. An Iarray 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 [EMAIL PROTECTED]
Re: Arrays vs lists; A possible solution?
Erik Steven Harrison wrote:
--
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 Iliteral is a piece of data.
A Iscalar is a variable that holds a literal.
A Ilist is a sequence of literals and scalars.
An Iarray 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.
You're completely right. See my last message :-)
Joseph F. Ryan
[EMAIL PROTECTED]
Re: Arrays vs lists; A possible solution?
--
On Thu, 13 Feb 2003 16:03:41
Joseph F. Ryan wrote:
Erik Steven Harrison wrote:
--
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 Iliteral is a piece of data.
A Iscalar is a variable that holds a literal.
A Ilist is a sequence of literals and scalars.
An Iarray 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.
You're completely right. See my last message :-)
I *am*? Mark it on your calender!
-Erik
Joseph F. Ryan
[EMAIL PROTECTED]
Get 25MB of email storage with Lycos Mail Plus!
Sign up today -- http://www.mail.lycos.com/brandPage.shtml?pageId=plus
Re: Arrays vs. Lists
On 2003-02-11 at 16:52:36, Dave Whipp wrote:
Mark J. Reed [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
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.
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.
--
Mark REED| CNN Internet Technology
1 CNN Center Rm SW0831G | [EMAIL PROTECTED]
Atlanta, GA 30348 USA | +1 404 827 4754
Re: Arrays vs. Lists
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
[EMAIL PROTECTED]
Re: Arrays vs. Lists
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. -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
Re: Arrays, lists, referencing (was Re: Arrays vs. Lists)
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, Csub 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
Csub and C:= are specific, binding-style operations... they do the
same thing for scalar variables, too.
There, how convincing did that sound?
MikeL
Re: Arrays vs. Lists
--
On Tue, 11 Feb 2003 12:28:23
Luke Palmer wrote:
Date: Tue, 11 Feb 2003 10:34:57 -0800
From: Michael Lazzaro [EMAIL PROTECTED]
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 Cmap 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
Arrays vs lists; A possible solution?
As near as I can tell, the only problem with the nice flow of: A Iliteral is a piece of data. A Iscalar is a variable that holds a literal. A Ilist is a sequence of literals and scalars. An Iarray 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
Re: Arrays vs lists; A possible solution?
-- 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 Iliteral is a piece of data. A Iscalar is a variable that holds a literal. A Ilist is a sequence of literals and scalars. An Iarray 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 Get 25MB of email storage with Lycos Mail Plus! Sign up today -- http://www.mail.lycos.com/brandPage.shtml?pageId=plus
Re: Arrays vs lists; A possible solution?
--
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 Iliteral is a piece of data.
A Iscalar is a variable that holds a literal.
A Ilist is a sequence of literals and scalars.
An Iarray 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
-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
Get 25MB of email storage with Lycos Mail Plus!
Sign up today -- http://www.mail.lycos.com/brandPage.shtml?pageId=plus
Get 25MB of email storage with Lycos Mail Plus!
Sign up today -- http://www.mail.lycos.com/brandPage.shtml?pageId=plus
Re: Arrays, lists, referencing (was Re: Arrays vs. Lists)
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, Csub 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 [EMAIL PROTECTED] 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
Re: Arrays vs. Lists
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
Re: Arrays vs. Lists
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
RE: Arrays vs. Lists [x-adr]
From: Michael Lazzaro [mailto:[EMAIL PROTECTED]]
Just to clarify... in P6, is this an array reference, or a list
reference?
[1,2,3]
Exactly. It's still up in the air...
Apoc 2, RFC 175:
So it works out that the explicit list composer:
[1,2,3]
is syntactic sugar for something like:
scalar(list(1,2,3));
Depending on whether we continue to make a big
deal of the list/array distinction, that might
actually be spelled:
scalar(array(1,2,3));
What about this?
\@array
hmm. As perl Apoc2, Lists, RFC 175... arrays and hashes return a reference
to themselves in scalar context... I'm not sure what context '\' puts them
in.
I'd guess \@array is a reference to an array reference.
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?
I'd just stick with Uri's explanation. Arrays are allocated. Lists are on
the stack...
It doesn't need improving... The only question is whether it is still
accurate in the _context_ of Perl6 ;)
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
There's only one person who can answer that... and he's not reading ;)
--
Garrett Goebel
IS Development Specialist
ScriptPro Direct: 913.403.5261
5828 Reeds Road Main: 913.384.1008
Mission, KS 66202 Fax: 913.384.2180
www.scriptpro.com [EMAIL PROTECTED]
Re: Arrays vs. Lists [x-adr]
[Recipients trimmed back to just p6-language; the Cc: list was getting a bit large.] On 2003-02-11 at 12:56:45, Garrett Goebel wrote: I'd just stick with Uri's explanation. Arrays are allocated. Lists are on the stack... Nuh-uh. Those are implementation details, not part of the language definition. From the standpoint of the Perl6 language, in the magical world where that language is executed directly with no need of interpreters, compilers, etc., what (if anything) is the distinction between an array and a list? I like the arrays are containers that hold lists explanation, assuming it's valid. Also, I would be very surprised if \@array returned a reference to a reference. I would assume that the \ forces scalar context and therefore interpretation as a reference. So these two statements would be equivalent: $ref = @array; $ref = \@array; As would these: print \@array; print scalar(@array); -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
Re: Arrays vs. Lists [x-adr]
On Tuesday, February 11, 2003, at 10:56 AM, Garrett Goebel wrote: What about this? \@array hmm. As perl Apoc2, Lists, RFC 175... arrays and hashes return a reference to themselves in scalar context... I'm not sure what context '\' puts them in. I'd guess \@array is a reference to an array reference. I understand the logic, but: my $r = @a; # ref to @a my $r = \@a; # ref to ref to @a ??? my @array = (\@a,\@b,\@c); # array of three arrayrefs Boy howdy, I think that would freak people. But making '\' put them in list context would of course be far worse: @array = (\@a); # means @a = ( \@a[0], \@a[1], ... ) ??? So I think '\' just puts things in CRef context, which solves the problem and always does The Right Thing, I think. So the context rules for arrays are: - in scalar numeric context, returns num of elements - in scalar string context, returns join of elements - in scalar ref context, returns a ref - in generic scalar context, returns a ref IMO. MikeL
Re: Arrays vs. Lists
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
[EMAIL PROTECTED]
Re: Arrays vs. Lists
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 REED| CNN Internet Technology
1 CNN Center Rm SW0831G | [EMAIL PROTECTED]
Atlanta, GA 30348 USA | +1 404 827 4754
Re: Arrays vs. Lists
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. :)
--
Mark REED| CNN Internet Technology
1 CNN Center Rm SW0831G | [EMAIL PROTECTED]
Atlanta, GA 30348 USA | +1 404 827 4754
Re: Arrays vs. Lists
JFR == Joseph F Ryan [EMAIL PROTECTED] 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.
uri
--
Uri Guttman -- [EMAIL PROTECTED] 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
Re: Arrays vs. Lists
Michael Lazzaro [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... 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?
RE: Arrays vs. Lists
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 [EMAIL PROTECTED]
@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
Arrays, lists, referencing (was Re: Arrays vs. Lists)
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 Cmap 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.
--
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_
Re: Arrays vs. Lists
Michael == Michael Lazzaro [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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!
RE: Arrays vs. Lists [x-adr]
Uri Guttman wrote: arrays are allocated and lists are on the stack. so arrays can have references to them but lists can't. Apoc 2, RFC 175: scalar(list(1,2,3)); [...] scalar(array(1,2,3)); Which would imply one could take a reference to either. can anyone see any changes in perl6 to invalidate that separation of lists and arrays? Immediately thereafter, Larry left room to imply list may actually be spelled a-r-r-a-y... -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com garrett at scriptpro dot com
Re: Arrays vs. Lists
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 Cpush,
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
Cif - 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_
Re: Arrays vs. Lists
From: Deborah Ariel Pickett [EMAIL PROTECTED] 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
Re: Arrays vs. Lists
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 Cpush, 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; Cgiven 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 yeehh 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 Cif - 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 [EMAIL PROTECTED]
Re: Arrays vs. Lists
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. 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 [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_
Re: Arrays vs. Lists
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
[EMAIL PROTECTED]
Re: Arrays vs. Lists
--- Michael Lazzaro [EMAIL PROTECTED] 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. 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
Re: Arrays vs. Lists
On 2003-02-07 at 11:13:07, Austin Hastings wrote: --- Michael Lazzaro [EMAIL PROTECTED] 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 | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
Re: Arrays vs. Lists
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. -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
Re: Arrays vs. Lists
--- Mark J. Reed [EMAIL PROTECTED] wrote: On 2003-02-07 at 11:13:07, Austin Hastings wrote: --- Michael Lazzaro [EMAIL PROTECTED] 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
Re: Arrays vs. Lists
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). -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
Re: Arrays vs. Lists
MJR == Mark J Reed [EMAIL PROTECTED] 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 -- [EMAIL PROTECTED] 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
Re: Arrays vs. Lists
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
Re: Arrays vs. Lists
ML == Michael Lazzaro [EMAIL PROTECTED] 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. uri -- Uri Guttman -- [EMAIL PROTECTED] 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
Re: Arrays vs. Lists
Michael Lazzaro [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... 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.
Re: Arrays vs. Lists
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
Re: Arrays vs. Lists
ML == Michael Lazzaro [EMAIL PROTECTED] 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.
uri
--
Uri Guttman -- [EMAIL PROTECTED] 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
Re: Arrays vs. Lists
On Fri, Feb 07, 2003 at 06:38:36PM -0500, Uri Guttman wrote: ML == Michael Lazzaro [EMAIL PROTECTED] 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.
Re: Arrays vs. Lists
Date: Fri, 7 Feb 2003 14:46:37 -0800 From: Michael Lazzaro [EMAIL PROTECTED] 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. 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 Cchop a string literal? That's why you can't Cpop a list. Luke
Re: Arrays vs. Lists
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
Re: Arrays vs. Lists
AT == Adam Turoff [EMAIL PROTECTED] writes: AT On Fri, Feb 07, 2003 at 06:38:36PM -0500, Uri Guttman wrote: ML == Michael Lazzaro [EMAIL PROTECTED] 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 -- [EMAIL PROTECTED] 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
