Re: Using lists containing arrays as lvalues
HaloO, Ingo Blechschmidt wrote: But there is a problem with the ordinary assignment form: ($head, @tail) = foo(); If the LHS is an ordinary list (i.e., if we don't use help from the grammar/macros), What is a 'ordinary List' to you? I thought (,) constructs a Lazy list? then the @tail would get flattened before it reached the assignment operator. This is turn would cause the statement not to DWIM: my ($head, @tail) = foo(); # is really my ($head, @tail); ($head, @tail) = foo(); # is really (as @tail is empty) Aren't you making the silent transition here from the Array type to the List type? I would argue that the LHS is a Lazy that stores internal refs to $head and @tail until it is actually iterated. What I don't know is how lvalue iteration is distinguished from rvalue iteration. Then foo is called and the = is dispatched according to the type of the return value. The outcome hinges on that and on the type of ($head, @tail) which could be the 2-Tupel (Item,Array) or if you want 'List of ::X' ::X has to be the LUB of Item and Array, e.g. Object. Now assume foo() returns (1,2,3) which is a List of Int. Now infix:= just iterates the LHS and RHS. LHS is iterated for lvalues, of course. This results in the three assignments: $head= 1; @tail[0] = 2; # lvalue delivered from LHS list @tail[1] = 3; Which is what you expected, or not? For two scalars ($x,$y) = (1,2,3) the above nicely throws a undef assignment exception: $x = 1; $y = 2; undef = 3; # iterator ran out of values ($head, ())= foo(); # is really ($head)= foo(); # is really $head = foo(); # !!! for this I think we need an easier solution... Perhaps flattenning foo instead of adding a slurp, or making yadda yadda in lvalue throw it's arguments away silently: my ($foo, $bar, ...) := foo(); What has become of nullary * for list construction? my ($foo, $bar, *) := foo(); -- $TSa.greeting := HaloO; # mind the echo!
Re: Using lists containing arrays as lvalues
On Sat, Aug 27, 2005 at 08:19:00PM +0200, Ingo Blechschmidt wrote: : But there is a problem with the ordinary assignment form: : : ($head, @tail) = foo(); : : If the LHS is an ordinary list (i.e., if we don't use help from the : grammar/macros), then the @tail would get flattened before it reached : the assignment operator. This is turn would cause the statement not to : DWIM: : : my ($head, @tail) = foo(); # is really : : my ($head, @tail); : ($head, @tail) = foo(); # is really (as @tail is empty) : : ($head, ())= foo(); # is really : : ($head)= foo(); # is really : : $head = foo(); # !!! Yes, a list in lvalue context must propagate lvalueness to its components. You have to do this anyway to know when autovivication is permissible. The fact that you don't know it's an lvalue till you see the = means you can't just propagate the information down via the first pass of recursive descent. This is why Perl 5 makes separate top-down passes on portions of its tree when it has enough context to do that. Perl 6 will not be immune from this necessity... : for this I think we need an easier solution... Perhaps flattenning : foo instead of adding a slurp, or making yadda yadda in lvalue throw : it's arguments away silently: : : my ($foo, $bar, ...) := foo(); : : I like that! :) That could be made to work, but we've claimed for cultural continuity that assignment will work the same in Perl 6 as it was in Perl 5, so it's not the solution for you problem. Larry
Using lists containing arrays as lvalues
Hi, (sorry for me going into implementation details, but, as it's really a language design question, I refrained from sending this to p6c.) While trying to make the following work in PIL2JS... my ($head, @tail) = foo(); it occured to me that this is bogus, or at least hard to implement. Without help from the grammar/macros, this translates to the following in PIL: my ($head, @tail); infix:,($head, @tail) = foo(); infix:, is the sub which create lists, e.g. (1,2,3) is really infix:,(1,2,3). Therefore, infix:, has a signature of ([EMAIL PROTECTED]), but this (of course) causes @tail to be flattened before it reaches infix:,, causing the statement not to DWIM. (This corresponds to (@foo, @bar) in Perl-space, which does not evaluate to a list with two elements, but to a list containing @[EMAIL PROTECTED] elements (think @foo.append(@bar))). I see two possible solutions: 1) Make it work -- we'll use macros, help from the grammar, or some other technique to make it work. 2) We ask people to use the more clear my ($head, [EMAIL PROTECTED]) := foo(); I.e. we use binding's property that the LHS is a subroutine signature. (Note that I do not talk about the LHS being a list of scalars (e.g. ($a, $b, $c) = foo()), this post only speaks about using lists containing @arrays as lvalues). If we generally recommend this solution especially to newbies, it has got the additional property that my ($foo, $bar) := foo(); will fail if foo returns more than two things (instead of silently discarding any additional arguments, i.e. assuming my ($foo, $bar, [EMAIL PROTECTED]) := foo(); Opinions? -- Linux, the choice of a GNU | Row, row, row your bits, gently down the generation on a dual AMD | stream... Athlon!|
Re: Using lists containing arrays as lvalues
On Sat, Aug 27, 2005 at 19:16:55 +0200, Ingo Blechschmidt wrote: my ($head, [EMAIL PROTECTED]) := foo(); if foo returns a list of scalars =2 this is like parameter unpacking: my ($head, [EMAIL PROTECTED]) = *foo(); if foo returns a scalar and an array as a list of two scalars, the second one being a ref to an array: my ($head, @tail) = foo(); I.e. we use binding's property that the LHS is a subroutine signature. (Note that I do not talk about the LHS being a list of scalars (e.g. ($a, $b, $c) = foo()), this post only speaks about using lists containing @arrays as lvalues). BTW, for simplicities sake perhaps there is an MMD on infix:,, one for lvalue context, the other for read only context? discarding any additional arguments, i.e. assuming my ($foo, $bar, [EMAIL PROTECTED]) := foo(); for this I think we need an easier solution... Perhaps flattenning foo instead of adding a slurp, or making yadda yadda in lvalue throw it's arguments away silently: my ($foo, $bar, ...) := foo(); -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: : neeyah! pgpfVkAEM6Cwm.pgp Description: PGP signature
Re: Using lists containing arrays as lvalues
Hi, Yuval Kogman wrote: On Sat, Aug 27, 2005 at 19:16:55 +0200, Ingo Blechschmidt wrote: my ($head, [EMAIL PROTECTED]) := foo(); if foo returns a list of scalars =2 this is like parameter unpacking: my ($head, [EMAIL PROTECTED]) = *foo(); [...] Right, but I wanted to drive at the difficulty of making this work, sorry if I was unclear. ($head, [EMAIL PROTECTED]) := foo(); # (Note: := here, not =) This is not a problem, because :='s LHS is a subroutine signature, which means the necessary magic is already there. But there is a problem with the ordinary assignment form: ($head, @tail) = foo(); If the LHS is an ordinary list (i.e., if we don't use help from the grammar/macros), then the @tail would get flattened before it reached the assignment operator. This is turn would cause the statement not to DWIM: my ($head, @tail) = foo(); # is really my ($head, @tail); ($head, @tail) = foo(); # is really (as @tail is empty) ($head, ())= foo(); # is really ($head)= foo(); # is really $head = foo(); # !!! for this I think we need an easier solution... Perhaps flattenning foo instead of adding a slurp, or making yadda yadda in lvalue throw it's arguments away silently: my ($foo, $bar, ...) := foo(); I like that! :) --Ingo -- Linux, the choice of a GNU | self-reference, n. - See self-reference generation on a dual AMD | Athlon!|
Lazy Lists + Mutable Arrays + Garbage Collection
Hi,
I've been wondering how to lazy lists will work.
The answer Correctly, don't worry about it, is entirely acceptable...
The intent of this example in S06 seems clear, make @oddsquares
a lazily filled array of squares of odd @nums:
S06/Pipe operators
It [==] binds the (potentially lazy) list from the blunt end
to the slurpy parameter(s) of the subroutine on the sharp end.
[...]
If the operand on the sharp end of a pipe is not a call to a
variadic operation, it must be a variable, in which case the
list value is assigned to the variable. This special case
allows for pure processing chains:
@oddsquares == map { $_**2 } == sort == grep { $_ % 2 } == @nums;
So @oddsquares is like a stream of values derived from @nums. (is it?)
Then presumably I can make a @primesquares stream:
my (@ints, @primesquares);
@ints == 2...;
@primesquares == map { $_**2 } == grep { is_prime($_) } == @ints;
say @primesquares[3];
Can I then treat @primesquares like an array, say by swapping
two elements? How about @ints?
If these arrays can be be mutated then how can they be garbage
collected? All the non-prime @ints could be still hanging around
while either array is in scope.
With cons based lists, past stream values are no longer referred to
so can be reclaimed, but we have random access arrays.
That's about where my wondering stopped.
Brad
I always get nervous when this sig appears randomly...
--
There are times when a person gets carried away and talks on without
thinking too much. But this can be seen by observers when one's mind is
flippant and lacking truth. -- Hagakure http://bereft.net/hagakure/
Re: Lazy Lists + Mutable Arrays + Garbage Collection
With cons based lists, past stream values are no longer referred to so can be reclaimed, but we have random access arrays. That's about where my wondering stopped. It started again. @primesquares.shift would do it Brad
Re: lists and arrays
What is a list reference?
What is an array?
...
What is a list?
Hi Juerd,
There was a thread on this not long ago. I forgot it's name.
Apo 2 said:
[1,2,3]
is syntactic sugar for something like:
scalar(list(1,2,3))
... suggesting that lists could have references taken to them, much like an
array. But then again, the something like gave some wiggle room there.
More recently, it was amended to:
scalar(array(1,2,3))
(Still no spaces after the commas, grr)
As best as I can find there has been no official announcement.
It has been suggested that all hashes, arrays, and objects are essentially
references. This is consistent with other languages where two things are
true at the same time:
1. Arrays and such are passed by reference
1. You don't have to dereference arrays and such before using them
Heh, there's that thread: It's subject was Re: Arrays, lists, referencing (was
Re: Arrays vs. Lists)
Let me quote a message from it. Juerd's original message is quoted below.
I think this was the most coherent, least objected to message before the subject
line really became a lie:
From: [EMAIL PROTECTED] (Michael Lazzaro)
On Tuesday, February 11, 2003, at 04:56 PM, Deborah Ariel Pickett
wrote:
But is it OK for a list to be silently promoted to an array when used
as an array? So that all of the following would work, and not just
50%
of them?
(1..10).map {...}
[1..10].map {...}
And somehow related to all this . . .
snip
I think some of this is in A2, but not all of it.
Here are some of the answers from my own notes. These behaviors have
all been confirmed on-list by the design team:
An @array in list context returns a list of its elements
An @array in scalar context returns a reference to itself (NOTE1)
An @array in numeric (scalar) context returns the number of elements
An @array in string (scalar) context returns a join of its elements
An $arrayref in list context returns an arrayref (NOTE2)
An $arrayref in scalar context returns an arrayref
An $arrayref in numeric (scalar) context returns ??? (NOTE3)
An $arrayref in string (scalar) context returns ???
Note that that's pretty consistent with how it works now.
(NOTE1): This is the big change. It's what allows us to treat arrays
as objects, and call methods on them like @array.length. I don't think
anyone will argue that's not a good thing.
(NOTE2): Note that this is a non-change. If we changed it so that an
arrayref flattened itself in array context, you could never have
complex data structures, because [[1,2],[3,4]] would always be the same
as [1,2,3,4].
(NOTE3): I have not been able to find explicitly confirmed behaviors
for these two. It has been implied that they return $arrayref.length
and $arrayref.string (or whatever those methods are called). Maybe.
On 0, Juerd [EMAIL PROTECTED] wrote:
Hi,
I'm lost. I read some Perl 6 related things and think I missed an
important announcement.
What is a list reference?
It is as if lists and arrays are the same thing in Perl 6, but other
documents use the words as they are used in Perl 5.
So I guess my actual questions are:
What is an array?
What is a list?
Regards,
Juerd
lists and arrays
Hi, I'm lost. I read some Perl 6 related things and think I missed an important announcement. What is a list reference? It is as if lists and arrays are the same thing in Perl 6, but other documents use the words as they are used in Perl 5. So I guess my actual questions are: What is an array? What is a list? Regards, Juerd
