Re: (1,(2,3),4)[2]
On Wed, May 25, 2005 at 07:07:02PM -0400, Uri Guttman wrote: : the only advantage in the above case is the different prececences of = : and == which allows dropping of parens with the latter. i don't : consider that so important a win as to be used often. and they are at : equal huffman levels as the =() is matched in length by ==. There's also the fact that == can bind a lazy list, since we've said (if I recall correctly) that == actually does binding rather than assignment, possibly even to the extent that my $b == foo(); declares $b to be an iterator rather than an array ref. Larry
Re: (1,(2,3),4)[2]
On Tue, May 31, 2005 at 03:42:42PM -0700, Larry Wall wrote: : On Wed, May 25, 2005 at 07:07:02PM -0400, Uri Guttman wrote: : : the only advantage in the above case is the different prececences of = : : and == which allows dropping of parens with the latter. i don't : : consider that so important a win as to be used often. and they are at : : equal huffman levels as the =() is matched in length by ==. : : There's also the fact that == can bind a lazy list, since we've said : (if I recall correctly) that == actually does binding rather than : assignment, possibly even to the extent that : : my $b == foo(); : : declares $b to be an iterator rather than an array ref. Though that would seem to imply that *$x slurpy parameters should work that way too, and that's not how they work right now... Larry
Re: (1,(2,3),4)[2]
Markus Laire wrote:
@m[0;1] is a multidim deref, referencing the 4.
Referencing the 2, I hope?
Doh!
Yes, the 2.
Really?
I consider this puzzling indicative that the (,) vs. [,] distinction
in Perl6 falls into the same category as e.g. starting the capture
variables at $1.
@m here has _single_ array-ref so
@m[0] returns that single array-ref - [[1,2],[3,4]]
@m[0;1] then returns array-ref [3,4]
@m[0;0] would return [1,2]
@m[0;0;1] would return 2
Yea, that's the---in my eyes unfortunate---preservation of
reference level depending on the left side of assignment.
Or stated the other way round, the auto-referencing when
the lhs is a $ variable. BTW, are lvalue subs handled the
same as $ vars here?
Could the ones who know it, enlighten me *why* it has to be so?
What does it buy the newbie, average, expert Perl6 programmer?
The answer that's how Perl5 did it is a good default, but
never hindered @Larry to change things.
Here are some speculations from me:
1) On one hand @a shall be a single handle to an array but
always writing a total slice, or flattener when you want
to replace the array as a whole is considered cumbersome
or redundant. Thus @a = 1 is basically a shortcut for
@a[] = 1 or [EMAIL PROTECTED] = 1. Note that for keeping some of the
existing values one has to use a non-total index/slice
like @a[42] = 1.
Question: With @a = (0,1,2,3,4,5), what does @a[2..4] = 7 mean?
@a == (0,1,7,5)? @a == (0,1,7,7,7,5)? I think it's the former,
and the latter actually is written @a[2..4] »=« 7.
How about: @a[1] = @b? Is that storing a ref to @b in @a at
position 1? Then @a[1] = 23 puts the 23 into @b at position 0?
So to get it back one has to use @a[1][0]?
2) Since a distinction between (,) and [,] for arrays and
( = , = ) and { = , = } for hashes is /syntactically/ possible
it is used to separate values from refs. But context spills
over from the lhs, though. I wouldn't unify these directly but
through the following typing:
(,) -- Eager (but not flattening nested Lazy stuff)
.. -- Lazy
= -- Pair
( = , = ) -- Eager of Pair
[] -- Array (this actually doesn't need the comma op)
{} -- Hash (actually Code, but evaluated immediately if
recognizeable at compile time)
3) The example in 1) might actually be wrong if @a = 1 sets
the size of the array. I see a tendency in perlkind to
have special cases like it's a number assigned to an array,
so the size changes. The assignment is smutten with these
special meanings because an imperative language is built
around it. E.g. ($x,$y) = (1,2) falls in this category as
well. In a purer setting it could be required to write
($x,$y) »=« (1,2) as it is for ($x,$y) »+« (1,2). Hmm,
then this is ultra-pure: @a[] »=« (1,2,3). Note that when @a
always denotes a single handle @a »=« (1,2,3) could be expanded
to (@a = 1, @a = 2, @a = 3) not (@a[0] = 1, @a[1] = 2, @a[2] = 3).
4) I guess not many want @a = \1 to be valid. But why not?
prefix:{'\'}:( Any $x : -- Ref of $x.type ) could build
an anonymous Ref of Int and then that is assigned to the
array on the left making it two-dimensional because of the
reference. Thus getting back the 1 needs one of the following
forms: @a[0][0], @a[0][], [EMAIL PROTECTED] or [EMAIL PROTECTED] The first
three forms
assume that postcircumfix:[ ] is supported by the Ref type.
I'm still arguing in favor of a---possibly strictly compiler enforced---
least upper bound typing of plain sigil expressions:
-- Code
$ -- Item (if that is the name now)
@ -- Array
% -- Hash
The strict type enforcement would prevent things like
@foo = sub (Int $x) { return $x * $x }
say @foo(13); # prints 169
OTOH without it, going almost sigilless would just be
my foo = 3;
my bar = HaloO;
if foo 2 { say bar }
my array is Array;
array[12] = 17;
My line of thought might actually be easier to understand if
you treat = as a normally dispatched infix operator without any
special significance. The two operators ::= and := are *not*
dispatched. They are macros or a direct part of the grammar.
::= is mostly syntactic sugar for a BEGIN block and := is basically
compiled to the engine level destructive assignment operation.
But this view might also be completely wrong.
Regards,
--
TSa (Thomas Sandlaß)
Re: (1,(2,3),4)[2]
Juerd wrote:
From S02: Array and hash variable names in scalar context
automatically produce references.
Since [...] produces a scalar arrayref, we end up with an arrayref one
both sides of the =.
No.
There is no scalar context on the LHS of the assignment operator.
And, assigning to a reference is impossible, as a reference is a VALUE,
not a VARIABLE (container).
This argumentation breaks down as soon as you regard infix:{'='} as
an operator like many others. How do you derive context for the lhs
and rhs of infix:{'+'} or infix:{'*~*'}? From its invocant part of
the signature? With the sigil giving the default overrideable with the
'is context' param trait? Or does only the slurpy indicator * enforce
list context?
But then there might be a little bootstrapping problem with MMD if
both contexts are defined. How does one dispatch an Array then?
Junctively flattened and unflattened?
And another oddity is that the compiler has potentially to go back
and re-compile some code with invocations of ops if it later sees more
overloaded definitions of these ops that have other context traits in
their signature. It's much easier to just compile to MMD code and leave
the rest to the runtime dispatch. But this requires a self-contained
definition of the meaning of @a and [] as described by Rod.
--
TSa (Thomas Sandlaß)
Re: (1,(2,3),4)[2]
Juerd wrote:
And, assigning to a reference is impossible, as a reference is a VALUE,
not a VARIABLE (container).
What should hinder infix:{'='}:(Ref, Int: -- Int) to exist and be
usefull at least if the Ref is known to something that derefs it
and then finds the new referee? On the Perl6 language level references
are a means to share values. Don't mix that with the implementation
level references---which should be called pointers---that allow an
efficient implementation of handling heavyweight data.
--
TSa (Thomas Sandlaß)
Re: (1,(2,3),4)[2]
TSa (Thomas Sandlaß) skribis 2005-05-27 16:22 (+0200):
This argumentation breaks down as soon as you regard infix:{'='} as
an operator like many others.
Which we don't, making this discussion much easier for everyone.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: (1,(2,3),4)[2]
TSa (Thomas Sandlaß) skribis 2005-05-27 15:44 (+0200): Could the ones who know it, enlighten me *why* it has to be so? What does it buy the newbie, average, expert Perl6 programmer? The answer that's how Perl5 did it is a good default, but never hindered @Larry to change things. Because the alternative is to drop context. If we drop context, we have to use an array where we now use a list. And list automatically becomes an alias for array in our jargon. Also, arrays will then probably no longer have any referenceless version, and always be objects and thus references. Then we lose the point for having different sigils, and everything gets a dollar sign. The end result is very different from Perl, and can no longer be thought of even as derrived from Perl, in my opinion. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: (1,(2,3),4)[2]
HaloO Juerd, you wrote: Because the alternative is to drop context. ... Then we lose the point for having different sigils, and everything gets a dollar sign. Isn't the strong type system adequate compensation? Especially when the sigils denote the level below which you can't go in untypedness or unspecificity? The two new list types Eager and Lazy nicely fit the jargon term. Actually you could e.g. apply them to complete files and view them as a list of lines if that suites a certain task. OTOH, some classes might like to travel in variables with the @ and % sigil. E.g. my @data is DatabaseTable; my %tree is StructuredDocument; -- TSa (Thomas Sandlaß)
Re: (1,(2,3),4)[2]
Rod Adams wrote:
TSa (Thomas Sandlaß) wrote:
You mean @a = [[1,2,3]]? Which is quite what you need for multi
dimensional arrays anyway @m = [[1,2],[3,4]] and here you use
of course @m[0][1] to pull out the 2. I'm not sure if this automatically
makes the array multi-dimensional to the type system though. That is
if @m[0,1] returns 2 as well or if it returns the list (1,2) or whatever.
Is @m[0..3] valid and what does it return? And what's the type of that
return value(s)? I can imagine many things ranging from a two element
array of refs to two element arrays up to a flattened list of 4 values.
@m[0,1] is an array slice of two elements, in this case two arrayrefs
[1,2], and [3,4].
@m[0;1] is a multidim deref, referencing the 4.
@m[0..3] is valid, returning arrayref x 2, undef x 2.
I think you got these wrong. With @m = ([1,2],[3,4]) these would be
true, but with @m = [[1,2],[3,4]] we have an additional reference there.
Here @m has single array-ref, not 2 array-refs.
pugs gives this:
pugs my @m = [[1,2],[3,4]]
({ref:Array})
pugs @m[0,1]
({ref:Array}, undef)
pugs @m[0..3]
({ref:Array}, undef, undef, undef)
# @m[0;1] form doesn't work in r3723
and
pugs my @m = ([1,2],[3,4])
({ref:Array}, {ref:Array})
pugs @m[0,1]
({ref:Array}, {ref:Array})
pugs @m[0..3]
({ref:Array}, {ref:Array}, undef, undef)
--
Markus Laire
Re: (1,(2,3),4)[2]
Rod Adams wrote:
Austin Hastings wrote:
--- Rod Adams [EMAIL PROTECTED] wrote:
TSa (Thomas Sandlaß) wrote:
@m = [[1,2],[3,4]]
@m[0;1] is a multidim deref, referencing the 4.
Referencing the 2, I hope?
Doh!
Yes, the 2.
Really?
@m here has _single_ array-ref so
@m[0] returns that single array-ref - [[1,2],[3,4]]
@m[0;1] then returns array-ref [3,4]
@m[0;0] would return [1,2]
@m[0;0;1] would return 2
Double-checking with pugs: (multi-dim with ; doesn't work yet)
pugs my @m = [[1,2],[3,4]]
({ref:Array})
pugs @m[0]
({ref:Array}, {ref:Array})
pugs @m[0][1]
(3, 4)
pugs @m[0][0]
(1, 2)
pugs @m[0][0][1]
2
@m = [[1,2],[3,4]] IS NOT same as @m = ([1,2],[3,4])
pugs my @m = ([1,2],[3,4])
({ref:Array}, {ref:Array})
pugs @m[0]
(1, 2)
pugs @m[0][1]
2
--
Markus Laire
Re: (1,(2,3),4)[2]
Markus Laire wrote: Rod Adams wrote: TSa (Thomas Sandlaß) wrote: You mean @a = [[1,2,3]]? Which is quite what you need for multi dimensional arrays anyway @m = [[1,2],[3,4]] and here you use of course @m[0][1] to pull out the 2. I'm not sure if this automatically makes the array multi-dimensional to the type system though. That is if @m[0,1] returns 2 as well or if it returns the list (1,2) or whatever. Is @m[0..3] valid and what does it return? And what's the type of that return value(s)? I can imagine many things ranging from a two element array of refs to two element arrays up to a flattened list of 4 values. @m[0,1] is an array slice of two elements, in this case two arrayrefs [1,2], and [3,4]. @m[0;1] is a multidim deref, referencing the 4. @m[0..3] is valid, returning arrayref x 2, undef x 2. I think you got these wrong. With @m = ([1,2],[3,4]) these would be true, but with @m = [[1,2],[3,4]] we have an additional reference there. From S02: Array and hash variable names in scalar context automatically produce references. Since [...] produces a scalar arrayref, we end up with an arrayref one both sides of the =. Now, I see two ways it could shake down from here: 1) the lhs ref acquires the value of the rhs ref. 2) both sides perform one level of dereferencing, and the list of elements from the rhs is copied over to the lhs. Having one one side dereference and not the other makes no sense at all. Either way, I see the following as all being semantically equivalent: @m = ([1,2],[3,4]); @m = [[1,2],[3,4]]; @m = (1,2; 3,4); @m = [1,2; 3,4]; @m = list([1,2],[3,4]); @m = (); @m[0]=[1,2]; @m[1]=[3,4]; @m[] = ([1,2],[3,4]); @m == [1,2], [3,4]; @m == (1,2; 3,4); If I understand Juerd correctly, the logical extension would be to have @m = 5; be the same as: @m = list(5); Thus saying that a lhs @ forces list context on the rhs, where I think having the rhs dictate context on the rhs makes a lot more sense. Basically, I'm disagreeing with some of what Juerd has said. -- Rod Adams
Re: (1,(2,3),4)[2]
Rod Adams skribis 2005-05-26 4:15 (-0500): From S02: Array and hash variable names in scalar context automatically produce references. Since [...] produces a scalar arrayref, we end up with an arrayref one both sides of the =. No. There is no scalar context on the LHS of the assignment operator. And, assigning to a reference is impossible, as a reference is a VALUE, not a VARIABLE (container). Assigning to a reference thus makes no sense in the same way that assigning a new value to the number 42 makes no sense. It is possible with some tricks, but you really shouldn't ever want to do this. If I understand Juerd correctly, the logical extension would be to have @m = 5; be the same as: @m = list(5); The RHS of an array assignment is in list context. list is an operator that does nothing more than force list context. In this case, it is entirely redundant. But, of course, valid. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: (1,(2,3),4)[2]
Is giving = a higher precedence than , still considered A Good Thing? I'm not familiar with the reasoning behind the current situation, but I'm struggling to come up with any good reasons for keeping it. Consider the alternative: my $a, $b = 1, 2; # $b should contain 2, not 1 I read this as (my $a), ($b=1), 2; The comma separates clauses in English (and other languages). Why should it not be so in Perl? If you need parens, then use them. I believe it was Larry who said When in doubt, parenthesize. At the very least, people can bounce on them with % in vi.
Re: (1,(2,3),4)[2]
Juerd wrote: Rod Adams skribis 2005-05-26 4:15 (-0500): From S02: Array and hash variable names in scalar context automatically produce references. Since [...] produces a scalar arrayref, we end up with an arrayref one both sides of the =. No. There is no scalar context on the LHS of the assignment operator. And, assigning to a reference is impossible, as a reference is a VALUE, not a VARIABLE (container). Assigning to a reference thus makes no sense in the same way that assigning a new value to the number 42 makes no sense. It is possible with some tricks, but you really shouldn't ever want to do this. You're right. It was late, and my brain missed a few details. I saw arrayref = arrayref, and C took over. If I understand Juerd correctly, the logical extension would be to have @m = 5; be the same as: @m = list(5); The RHS of an array assignment is in list context. list is an operator that does nothing more than force list context. In this case, it is entirely redundant. But, of course, valid. Of course it works that way. Why else would there be a want() function? -- Rod Adams
Re: (1,(2,3),4)[2]
Juerd wrote:
An array in scalar context evaluates to a reference to itself.
A hash in scalar context evaluates to a reference to itself.
An array in list context evaluates to a list of its elements.
A hash in list context evaluates to a list of its elements (as pairs).
Array context is a scalar context.
I have understand what you mean and how you---and other p6l'er---
derive [EMAIL PROTECTED] == 1 from @a = [1,2,3]. But allow me to regard this
as slightly inconsistent, asymmetric or some such.
Isn't hash context missing in the list above? How does
%a = ( a = 1, b = 2, c = 3 ) # @a = (1,2,3)
compare with
%b = { a = 1, b = 2, c = 3 } # @b = [1,2,3]
Does that mean
3 == +%a == +%b
== +{ a = 1, b = 2, c = c }
== +( a = 1, b = 2, c = c )
holds and the access of the hash works as expected:
%aa == 1 == %ba # and @a[0] == 1, but @b[0][0] == 1
What would actually be the equivalent syntax to @b?
Is it %ba or %%ba or even (*%b)a?
It will hardly be %b{undef}a, though.
--
TSa (Thomas Sandlaß)
Re: (1,(2,3),4)[2]
TSa (Thomas Sandlaß) skribis 2005-05-25 10:47 (+0200):
I have understand what you mean and how you---and other p6l'er---
derive [EMAIL PROTECTED] == 1 from @a = [1,2,3]. But allow me to regard this
as slightly inconsistent, asymmetric or some such.
If you STILL don't understand that it has nothing to do with
inconsistency or asymmetry, then please allow me to at this point give
up and stop trying to explain.
() do not construct lists, inside () is an expression, () does not
provide context. [] constructs arrays, inside [] is an expression that
is a list, [] does provide list context.
() and [] are as alike as [] and {} or and (), or ** and ++.
Your expectation, not the language, is wrong.
Isn't hash context missing in the list above? How does
%a = ( a = 1, b = 2, c = 3 ) # @a = (1,2,3)
HASH = THREE PAIRS
compare with
%b = { a = 1, b = 2, c = 3 } # @b = [1,2,3]
HASH = ONE SCALAR
That probably does roughly the same as:
%b;
%b{ { a = 1, b = 2, c = 3 } } = undef;
Hopefully with a warning complaining about the odd number of elements in
the list.
3 == +%a == +%b
No.
%aa == 1 == %ba
No, there is no %b{'a'}, only a $b{ $a_certain_hashref }.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: (1,(2,3),4)[2]
Juerd wrote:
If you STILL don't understand that it has nothing to do with
inconsistency or asymmetry, then please allow me to at this point give
up and stop trying to explain.
I would bewail that, because your explainations are very clear.
And it might appear different but I'm just trying to understand
things. Obviously I'm quite bad at it. So keep on helping a pity
old man.
() and [] are as alike as [] and {} or and (), or ** and ++.
Ohh, that is interessting. I look at them beeing all basically
the same thing: syntax draped around operations that are lexically
dispatched according to the types of the values involved. In other
words my primary interest is in the type system of Perl6 in particular
and all languages running on Parrot in general.
Your expectation, not the language, is wrong.
I have no expectations, and I'm not judging right or wrong.
But passive observation isn't enough either. So I'm asking
questions as well. I hope this is usefull to this list or
at least not considered as pestering.
%a = ( a = 1, b = 2, c = 3 ) # @a = (1,2,3)
HASH = THREE PAIRS
I look at it as infix:{'='}:( Hash, List of Pair : -- Ref of Hash )
and then try to understand how it behaves. BTW, I'm neither sure
of the type of the second invocant parameter nor of the return type.
Even the position of the : is contestable.
%b = { a = 1, b = 2, c = 3 } # @b = [1,2,3]
HASH = ONE SCALAR
infix:{'='}:( Hash, Scalar : -- Ref of Hash )
That probably does roughly the same as:
%b;
%b{ { a = 1, b = 2, c = 3 } } = undef;
Here I ask myself: is infix:{'='} dispatching to postfix:{ }?
What then ultimately defines hashiness: the type, the indexing
operator or the sigil? The other two are then derived concepts.
And +[1,2,3] seems to mean prefix:+:(Ref of Array: -- Num)
while +(1,2,3) is prefix:+:(List: -- Num). More interesting
are the infix:, inside. Is that infix:,:(:*Num -- Eager of Num)?
BTW, another mystery to me is which operators are pure code types,
which ones are macro assisted---and to what extent---and which are
pure macros aka syntactic sugar/necessity without a specific
implementation backend.
So, to summarize we could interpret our points of view as
syntax-down and type-up if the upward direction is from
implementation to type to syntax.
--
TSa (Thomas Sandlaß)
Re: (1,(2,3),4)[2]
TSa (Thomas Sandlaß) skribis 2005-05-25 13:53 (+0200):
%a = ( a = 1, b = 2, c = 3 ) # @a = (1,2,3)
HASH = THREE PAIRS
I look at it as infix:{'='}:( Hash, List of Pair : -- Ref of Hash )
and then try to understand how it behaves. BTW, I'm neither sure
of the type of the second invocant parameter nor of the return type.
Even the position of the : is contestable.
If assigning a ref to a hash uses the hashref's elements, then the same
is to be expected for an array. Because this behaviour is unwanted for
arrays (because you then can't assign a single arrayref anymore without
doubling the square brackets, communicating an entirely wrong thing),
hashes have to concede as well, even though %a = $href may not make
sense.
And +[1,2,3] seems to mean prefix:+:(Ref of Array: -- Num)
while +(1,2,3) is prefix:+:(List: -- Num). More interesting
The + forces scalar Num context. So it can probably be written as
something resembling
sub prefix:+ (Num $foo) { $foo }
Prefix + doesn't take a list. If you use comma in scalar context, an
array reference is created. This makes +[] and +() practically equal,
but that doesn't mean [] and () are always exchangeable, or even that
they have anything to do with eachother. In +[], the [] make the
arrayref, while in +(), the comma does that. If you have +() without
comma, you don't have an arrayref, because () only groups.
are the infix:, inside
I recall having read something about , being listfix, not infix. The
same would be true for Y and | and and ^.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: (1,(2,3),4)[2]
Juerd wrote:
If assigning a ref to a hash uses the hashref's elements, then the same
is to be expected for an array.
Same feeling here. But I would let the array concede.
Because this behaviour is unwanted for
arrays (because you then can't assign a single arrayref anymore without
doubling the square brackets, communicating an entirely wrong thing),
You mean @a = [[1,2,3]]? Which is quite what you need for multi
dimensional arrays anyway @m = [[1,2],[3,4]] and here you use
of course @m[0][1] to pull out the 2. I'm not sure if this automatically
makes the array multi-dimensional to the type system though. That is
if @m[0,1] returns 2 as well or if it returns the list (1,2) or whatever.
Is @m[0..3] valid and what does it return? And what's the type of that
return value(s)? I can imagine many things ranging from a two element
array of refs to two element arrays up to a flattened list of 4 values.
hashes have to concede as well, even though %a = $href may not make
sense.
I would treat it just the same as a literal hashref build with
{ = } because this should be what the dispatch system sees anyway.
E.g.
%h;
sub assign { my $href = { a = 1, b = 2}; %h = $href }
assign;
should be the same as
%h = { a = 1, b = 2 };
I recall having read something about , being listfix, not infix. The
same would be true for Y and | and and ^.
I can't find that in the archives. But it is a nice abbreviation for
infix:, ( ... ) is assoc(list). Could/should the same be done
as chainfix, leftfix and rightfix? Or asterfix, idfix, truebafix, ... :))
This last joke might work for Germans only.
--
TSa (Thomas Sandlaß)
Re: (1,(2,3),4)[2]
[1,2,3] is not an array or a list. It is a reference to an anonymous array.
It is not 3 values; it¹s 1 value, which happens to point to a list of size
3. If you assign that to an array via something like @a = [1,2,3], I would
expect at least a warning and possibly a compile-time error.
If it does work, it probably gets translated into @a = ([1,2,3]), which
creates an array of size 1 whose first (and only) element is a reference to
an array of size 3. That would give this result:
[EMAIL PROTECTED] == 1;
@a[0] == [1,2,3];
@a[1] == undef;
@a[0][0] == 1;
@a[0][1] == 2;
@a[0][2] == 3;
I¹m not sure about +(@a[0]), but I¹m guessing it would == 3.
On 2005-05-25 04:47, TSa (Thomas Sandlaß) [EMAIL PROTECTED]
wrote:
Juerd wrote:
An array in scalar context evaluates to a reference to itself.
A hash in scalar context evaluates to a reference to itself.
An array in list context evaluates to a list of its elements.
A hash in list context evaluates to a list of its elements (as pairs).
Array context is a scalar context.
I have understand what you mean and how you---and other p6l'er---
derive [EMAIL PROTECTED] == 1 from @a = [1,2,3]. But allow me to regard this
as slightly inconsistent, asymmetric or some such.
Isn't hash context missing in the list above? How does
%a = ( a = 1, b = 2, c = 3 ) # @a = (1,2,3)
compare with
%b = { a = 1, b = 2, c = 3 } # @b = [1,2,3]
Does that mean
3 == +%a == +%b
== +{ a = 1, b = 2, c = c }
== +( a = 1, b = 2, c = c )
holds and the access of the hash works as expected:
%aa == 1 == %ba # and @a[0] == 1, but @b[0][0] == 1
What would actually be the equivalent syntax to @b?
Is it %ba or %%ba or even (*%b)a?
It will hardly be %b{undef}a, though.
Re: (1,(2,3),4)[2]
TSa (Thomas Sandlaß) wrote: You mean @a = [[1,2,3]]? Which is quite what you need for multi dimensional arrays anyway @m = [[1,2],[3,4]] and here you use of course @m[0][1] to pull out the 2. I'm not sure if this automatically makes the array multi-dimensional to the type system though. That is if @m[0,1] returns 2 as well or if it returns the list (1,2) or whatever. Is @m[0..3] valid and what does it return? And what's the type of that return value(s)? I can imagine many things ranging from a two element array of refs to two element arrays up to a flattened list of 4 values. @m[0,1] is an array slice of two elements, in this case two arrayrefs [1,2], and [3,4]. @m[0;1] is a multidim deref, referencing the 4. @m[0..3] is valid, returning arrayref x 2, undef x 2. Personally, I strongly believe that assigning an arrayref to an array should dereference the arrayref, and send that to the array. Otherwise, you get silly things like: $a = [1,2,3]; @a = $a; say [EMAIL PROTECTED]; # 1 I would prefer to not have people be forced to write that as @a = $a[];. I don't see the big problem with having to double up the brackets to assign an arrayref to an array element. -- Rod Adams
Re: (1,(2,3),4)[2]
--- Rod Adams [EMAIL PROTECTED] wrote: TSa (Thomas Sandlaß) wrote: You mean @a = [[1,2,3]]? Which is quite what you need for multi dimensional arrays anyway @m = [[1,2],[3,4]] and here you use of course @m[0][1] to pull out the 2. I'm not sure if this automatically makes the array multi-dimensional to the type system though. That is if @m[0,1] returns 2 as well or if it returns the list (1,2) or whatever. Is @m[0..3] valid and what does it return? And what's the type of that return value(s)? I can imagine many things ranging from a two element array of refs to two element arrays up to a flattened list of 4 values. @m[0,1] is an array slice of two elements, in this case two arrayrefs [1,2], and [3,4]. @m[0;1] is a multidim deref, referencing the 4. Referencing the 2, I hope? -- Rod Adams =Austin
Re: (1,(2,3),4)[2]
Austin Hastings wrote: --- Rod Adams [EMAIL PROTECTED] wrote: TSa (Thomas Sandlaß) wrote: You mean @a = [[1,2,3]]? Which is quite what you need for multi dimensional arrays anyway @m = [[1,2],[3,4]] and here you use of course @m[0][1] to pull out the 2. I'm not sure if this automatically makes the array multi-dimensional to the type system though. That is if @m[0,1] returns 2 as well or if it returns the list (1,2) or whatever. Is @m[0..3] valid and what does it return? And what's the type of that return value(s)? I can imagine many things ranging from a two element array of refs to two element arrays up to a flattened list of 4 values. @m[0,1] is an array slice of two elements, in this case two arrayrefs [1,2], and [3,4]. @m[0;1] is a multidim deref, referencing the 4. Referencing the 2, I hope? Doh! Yes, the 2. -- Rod Adams
Re: (1,(2,3),4)[2]
Mark Reed skribis 2005-05-25 10:49 (-0400):
[1,2,3] is not an array or a list. It is a reference to an anonymous array.
It is not 3 values; it¹s 1 value, which happens to point to a list of size
Just for accuracy: it points to an array, which is still not a list in
our jargon.
3. If you assign that to an array via something like @a = [1,2,3], I would
expect at least a warning and possibly a compile-time error.
If it does work, it probably gets translated into @a = ([1,2,3]), which
That's not a translation. Parens, when not postfix, serve only one
purpose: group to defeat precedence. $foo and ($foo) are always the same
thing, regardless of the $foo.
I¹m not sure about +(@a[0]), but I¹m guessing it would == 3.
Because parens only group, and [0] here has tighter precedence than the
prefix + anyway, +(@a[0]) and [EMAIL PROTECTED] are exactly the same.
Because @a[0] is a reference to an array, that array is @{ @a[0] }. [EMAIL
PROTECTED]
@a[0] } is also the same as [EMAIL PROTECTED]
The numeric value of an array reference is the same as that of its
array.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: (1,(2,3),4)[2]
On 2005-05-25 13:54, Juerd [EMAIL PROTECTED] wrote: 3. If you assign that to an array via something like @a = [1,2,3], I would expect at least a warning and possibly a compile-time error. If it does work, it probably gets translated into @a = ([1,2,3]), which That's not a translation. Parens, when not postfix, serve only one purpose: group to defeat precedence. $foo and ($foo) are always the same thing, regardless of the $foo. So, you could then do this to make an array of size 3 in Perl6? @a = 1,2,3;
Re: (1,(2,3),4)[2]
Mark Reed skribis 2005-05-25 14:09 (-0400): That's not a translation. Parens, when not postfix, serve only one purpose: group to defeat precedence. $foo and ($foo) are always the same thing, regardless of the $foo. So, you could then do this to make an array of size 3 in Perl6? @a = 1,2,3; You could, if you changed the precedence of , to be tighter than =. However, by default, = has higher precedence than ,, so that you need parens to override this decision: @a = (1,2,3); Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: (1,(2,3),4)[2]
Juerd wrote: Mark Reed skribis 2005-05-25 14:09 (-0400): That's not a translation. Parens, when not postfix, serve only one purpose: group to defeat precedence. $foo and ($foo) are always the same thing, regardless of the $foo. So, you could then do this to make an array of size 3 in Perl6? @a = 1,2,3; You could, if you changed the precedence of , to be tighter than =. However, by default, = has higher precedence than ,, so that you need parens to override this decision: @a = (1,2,3); Or use @a == 1,2,3; -- Rod Adams
Re: (1,(2,3),4)[2]
On Wed, May 25, 2005 at 01:38:27PM -0500, Rod Adams wrote: Or use @a == 1,2,3; I would just like to say that I like this idiom immensely. my @foo == 1, 2, 3; reads extremely well to me, especially since I've always disliked the usage of '=' as an operator with side effects. (I'm strange like that.) -- wolverian signature.asc Description: Digital signature
Re: (1,(2,3),4)[2]
w == wolverian [EMAIL PROTECTED] writes: w On Wed, May 25, 2005 at 01:38:27PM -0500, Rod Adams wrote: Or use @a == 1,2,3; w I would just like to say that I like this idiom immensely. w my @foo == 1, 2, 3; w reads extremely well to me, especially since I've always disliked the w usage of '=' as an operator with side effects. (I'm strange like that.) please don't use == for simple assignments as it will confuse too many newbies and auch. it (and its sister ==) are for pipelining ops like map/grep and for forcing assignment to the slurpy array arg of funcs (hey, i think i said that correctly! :). = is still fine for basic assignment and everyone will understand it immediately. the only advantage in the above case is the different prececences of = and == which allows dropping of parens with the latter. i don't consider that so important a win as to be used often. and they are at equal huffman levels as the =() is matched in length by ==. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: (1,(2,3),4)[2]
On Wed, May 25, 2005 at 07:07:02PM -0400, Uri Guttman wrote: please don't use == for simple assignments as it will confuse too many newbies and auch. it (and its sister ==) are for pipelining ops like map/grep and for forcing assignment to the slurpy array arg of funcs (hey, i think i said that correctly! :). = is still fine for basic assignment and everyone will understand it immediately. I thought the op is visually so obvious it wouldn't need any explanation, even for newbies. Too bad what I _think_ is often not what actually _is_. -- wolverian signature.asc Description: Digital signature
Re: (1,(2,3),4)[2]
w == wolverian [EMAIL PROTECTED] writes: w On Wed, May 25, 2005 at 07:07:02PM -0400, Uri Guttman wrote: please don't use == for simple assignments as it will confuse too many newbies and auch. it (and its sister ==) are for pipelining ops like map/grep and for forcing assignment to the slurpy array arg of funcs (hey, i think i said that correctly! :). = is still fine for basic assignment and everyone will understand it immediately. w I thought the op is visually so obvious it wouldn't need any w explanation, even for newbies. w Too bad what I _think_ is often not what actually _is_. well, = has massive history on its side and almost all commonly used languages use it for assignment (pascal is NOT common anymore, thankfully and lisp isn't common enough :). so there is zero learning curve for that. you do need to learn about perl's precedences which need () for assigning a list. but == may seem obvious to you and for sure to anyone here but imagining what newbies would make of it boggles me. if there is a way to misunderstand it and abuse it, it will happen. :) so consider it just a style rule that i would encourage. damian should add it to his P6BP book when it comes out next christmas. :) uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: (1,(2,3),4)[2]
On 5/26/05, Juerd [EMAIL PROTECTED] wrote: You could, if you changed the precedence of , to be tighter than =. However, by default, = has higher precedence than ,, so that you need parens to override this decision: @a = (1,2,3); Is giving = a higher precedence than , still considered A Good Thing? I'm not familiar with the reasoning behind the current situation, but I'm struggling to come up with any good reasons for keeping it. Consider the alternative: my $a, $b = 1, 2; # $b should contain 2, not 1 my @foo = 3, 4, 5; # @foo should contain (3, 4, 5), not (list 3) What justification for the status quo could be so compelling that we feel the need to prevent both of these from doing the 'natural' thing? Stuart
Re: (1,(2,3),4)[2]
On 5/26/05, Stuart Cook [EMAIL PROTECTED] wrote: my $a, $b = 1, 2; # $b should contain 2, not 1 my @foo = 3, 4, 5; # @foo should contain (3, 4, 5), not (list 3) What justification for the status quo could be so compelling that we feel the need to prevent both of these from doing the 'natural' thing? (Scanning through the the history of this thread, I noticed the link to Larry's comment about the precedence of = and ,. I personally would still prefer them to be changed, but I guess it's not a big deal, as long as we have warnings to catch obvious-but-wrong code like my suggestions. When in doubt, use parens...)
Re: (1,(2,3),4)[2]
Juerd wrote: Parens and square brackets are very different things. I know. The parens relevant here are the ones for precedence overrides. And Comma is pretty low, so it almost always needs parens around it to form lists. In particular it is below = and friends. The above is more commonly written as my @b = ([1,2,[3,4]); Assuming you meant @b = ([1,2,[3,4]]) what do the parens accomplish here? Would it even need to be @b = (,[1,2,[3,4]]) to have the list contructing comma? Does the following hold: @a = (1,2,3); @b = @a; [EMAIL PROTECTED] == 1? My pivot question here is if +[1,2,[3,4]] == +(1,2,[3,4]) == 3 and why then is @a = [1,2,[3,4]]; [EMAIL PROTECTED] == 1 but $a = [1,2,[3,4]]; +$a == 3. And yes, I know that it is the case in Perl5. Perl6 has automatic deref and ref---or pretends to do so for people like you and Perl5 legacy. Otherwise $a = @b in Perl6 weren't the equivalent of Perl5's $a = [EMAIL PROTECTED] There are no Hash or Array registers in Parrot after all. On the engine level strings and PMCs are referential in nature but this shouldn't bother the Perl6 programmer. Or putting the question different: does prefix:+:(Any $x) get a different thing for its $x when called with @array = (1,2,3) or a literal [1,2,3]? BTW, how does @a = one two three compare to $a = one two three? Is [EMAIL PROTECTED] == 3? Is $a[1] == 'two'? Having arrayrefs flatten in list context, or having [] to be able mean I don't think they shall flatten. I'm just saying that it might be nice to let variables with the @ sigil just absorb them as they are. something other than constructing an arrayref, is a change that requires the very fundaments of Perl to change very heavily, beginning by eliminating lists entirely, and using only arrays. Larry only recently said something to that effect in http://groups-beta.google.com/group/perl.perl6.language/msg/6c306a1b0b885b5a To summarize in my words: 1) no List type or class 2) Eager and Lazy sounds more like closures, iterators, generators or whatever 3) And Array having a slot for each sounds to me like two private, scalar attributes that behave like $:eager = [1,2,3] which undeniably gives +$:eager == 3 These are mistakes many Perl 5 beginners make, especially those coming from Python. But this is the Perl6 language list, not a Perl5 beginners list. And I see a lot of things changed from Perl5 to Perl6, including referential semantics. Until now you haven't convinced me of the advantages of the old-style Perl5 references. What do they buy us? -- TSa (Thomas Sandlaß)
Re: (1,(2,3),4)[2]
TSa (Thomas Sandlaß) skribis 2005-05-19 21:06 (+0200):
The above is more commonly written as
my @b = ([1,2,[3,4]);
Assuming you meant @b = ([1,2,[3,4]]) what do the parens accomplish
here?
Thanks for the correction. That is indeed what I meant.
The parens do absolutely nothing, except indicate to a less skilled
reader that the [] aren't enclosing @b's future elements.
Would it even need to be @b = (,[1,2,[3,4]]) to have the list
contructing comma?
A single scalar in list context acts as a single item list, so a
specific list constructor is not needed.
Does the following hold: @a = (1,2,3); @b = @a; [EMAIL PROTECTED] == 1?
No.
@a = (1,2,3);
The array @a now contains 3 elements: 1, 2 and 3.
@b = @a;
@a is in list context. An array in list context, evaluates to a list of
its elements. Three elements are assigned to @b. Assignment copies the
values.
[EMAIL PROTECTED] == 1;
This expression is false. @b is in Num context. An array in numeric
context evaluates to its number of arguments. The number of arguments of
@b is 3, because it was just assigned three elements.
Do note that @a[0] == @b[0], but they are different variables:
assignment copies.
My pivot question here is if +[1,2,[3,4]] == +(1,2,[3,4]) == 3 and
That is: +[ LIST ] == +(ITEM, ITEM, ITEM). The comma in scalar context
makes generates an anonymous array and returns a reference to that.
Effectively, this makes () apparently equal to [] in this statement.
why then is @a = [1,2,[3,4]]; [EMAIL PROTECTED] == 1 but $a = [1,2,[3,4]];
+$a == 3.
Because @a contains one element and @$a contains three elements. $a is
not an array, it is a reference to an array, just like @a[0].
[EMAIL PROTECTED] is 3, just like [EMAIL PROTECTED] (shortened as +$a).
Perl6 has automatic deref and ref
An array in scalar context evaluates to a reference to itself.
A hash in scalar context evaluates to a reference to itself.
An array in list context evaluates to a list of its elements.
A hash in list context evaluates to a list of its elements (as pairs).
Array context is a scalar context.
A subroutine argument with the @ sigil represents an array that is
passed by reference. It can be accessed directly, without explicit
dereferencing.
A subroutine argument with the % sigil represents a hash that is
passed by reference. It can be accessed directly, without explicit
dereferencing.
sub ($bar) { the array is @$bar } # non-array allowed in call
sub (Array $bar) { the array is @$bar }
sub (@bar) { the array is @bar }
$anyofthose.(@array) is the same as $anyofthose.([EMAIL PROTECTED])
sub ([EMAIL PROTECTED]) { arguments are in list context, @bar has
aliases }
$thatthing.(@array) # passes the elements, not @array itself
$thatthing.([EMAIL PROTECTED]) # passes a reference to @array into @bar[0]
$thatthing.(15) # passes 15 into @bar[0]
Otherwise $a = @b in Perl6 weren't the equivalent of Perl5's $a = [EMAIL
PROTECTED]
I hate the term automatic referencing because it sounds much more
magical than it actually is.
In Perl 5, @array in scalar context returned the number of elements.
In Perl 6, @array in scalar context returns a reference.
In Perl 6, you can further specify scalar context:
* In Num context, @array returns its number of elements.
* In Str context, @array returns its elements joined on whitespace.
* In Bool context, @array returns true iff it has elements.
* In Array context, @array returns a reference.
* In Scalar context, @array returns a reference.
BTW, how does @a = one two three compare to $a = one two three?
@a is an array, $a is a reference to another. The elements of the arrays
are equal, but not the same.
Is [EMAIL PROTECTED] == 3?
Yes.
Is $a[1] == 'two'?
Yes. Do note that this is really @$a[1] or $a.[1].
this is the Perl6 language list, not a Perl5 beginners list.
Thank you for this reassurance.
And I see a lot of things changed from Perl5 to Perl6, including
referential semantics.
They haven't changed as much as you think. In fact, only how arrays and
hashes behave in scalar context has really changed.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: (1,(2,3),4)[2]
Juerd wrote: my @b = [1,2,[3,4]]; is([EMAIL PROTECTED], 1, 'Array length, nested [], outer []s'); Isn't that a bit inconvenient? To get e.g. 2 out of @b one has to write @b[0][1] while for $b a $b[1] suffices. And @x = @b maintains this superficial level of indirection? Does @x = @b[] remove one level? How does that compare to @x[] = @b? Thus my @b = (1,2,[3,4]); is equivalent to my $b = [1,2,[3,4]]; which in turn is equivalent to my $b = (1,2,[3,4]); and $b = @b blows away one level of indirection? Or is it then $b[0][1] == 2 as well? In the end the LHS is needed to calculate +[1,2,[3,4]] == 1|3? The same applies to testcases 7 and 8. All sane! :) Am I insane? -- TSa (Thomas Sandlaß)
Re: (1,(2,3),4)[2]
TSa (Thomas Sandlaß) skribis 2005-05-18 21:54 (+0200): Juerd wrote: my @b = [1,2,[3,4]]; is([EMAIL PROTECTED], 1, 'Array length, nested [], outer []s'); Isn't that a bit inconvenient? To get e.g. 2 out of @b one has to write @b[0][1] while for $b a $b[1] suffices. http://learn.perl.org/library/beginning_perl/ Parens and square brackets are very different things. The above is more commonly written as my @b = ([1,2,[3,4]); Having arrayrefs flatten in list context, or having [] to be able mean something other than constructing an arrayref, is a change that requires the very fundaments of Perl to change very heavily, beginning by eliminating lists entirely, and using only arrays. I believe I said it before, but I'll do it again: Perl is not Python. Just that the two languages are both powerful, and both begin with a P, and in some respects even syntactically look like eachother (hey, that's what we get for loving ASCII), doesn't mean any theory applicable to one automatically makes sense for the other. And @x = @b maintains this superficial level of indirection? ARRAY = LIST is the syntax for assigning to an array. Note that the RHS is list context, not Array context. Does @x = @b[] remove one level? How does that compare No. As far as I know, @b[] and @b are the synonymous. my @b = (1,2,[3,4]); is equivalent to my $b = [1,2,[3,4]]; No, that's not equivalent. $b contains a reference to an array, while @b itself is an array. Hoping the box diagram worked the last time, I'll try again: +-- @b +-- $b(this array has no name; | | it is anonymous) V V +--+ +++--+ | elements | | reference | elements | +--+ |++--+ ARRAY SCALARARRAY which in turn is equivalent to my $b = (1,2,[3,4]); That is only because the comma operator is in scalar context. The parens here merely GROUP, for precedence. my $b = eval 1,2,[3,4] would be exactly the same. Just to show you the parens are NOT constructors of the list. $b = @b No, that assigns a *reference to $b* to @b, without any copying of elements. Am I insane? No, you just STILL can't cope with Perl's notion of names, containers and values, and you don't realise that () and [] are not related, more specifically: that () has absolutely nothing to do with arrays or lists. These are mistakes many Perl 5 beginners make, especially those coming from Python. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: (1,(2,3),4)[2]
On 5/11/05, Autrijus Tang [EMAIL PROTECTED] wrote: In a somewhat related topic: pugs (1,(2,3),4)[2] 4 Because the invocant to .[] assumes a Singular context. Right, but the *inside* of the invocant is still a list, so it's in list context. I think that line should return 3. Luke
Re: (1,(2,3),4)[2]
On Wed, May 11, 2005 at 03:00:15PM -0600, Luke Palmer wrote: On 5/11/05, Autrijus Tang [EMAIL PROTECTED] wrote: In a somewhat related topic: pugs (1,(2,3),4)[2] 4 Because the invocant to .[] assumes a Singular context. Right, but the *inside* of the invocant is still a list, so it's in list context. I think that line should return 3. You're totally right, and I was clearly wahnsinnig. It now returns 3. Thanks, /Autrijus/ pgpkR6nPgs7mm.pgp Description: PGP signature
Re: (1,(2,3),4)[2]
All~ On 5/11/05, Luke Palmer [EMAIL PROTECTED] wrote: On 5/11/05, Autrijus Tang [EMAIL PROTECTED] wrote: In a somewhat related topic: pugs (1,(2,3),4)[2] 4 Because the invocant to .[] assumes a Singular context. Right, but the *inside* of the invocant is still a list, so it's in list context. I think that line should return 3. I am confused as to why exactly this is the case. Are you saying that nested lists like this flatten? That would certainly catch me off guard. Would you mind explaining that to me a little more? Thanks, Matt -- Computer Science is merely the post-Turing Decline of Formal Systems Theory. -???
Re: (1,(2,3),4)[2]
On Wed, 2005-05-11 at 17:48, Matt Fowles wrote: On 5/11/05, Luke Palmer [EMAIL PROTECTED] wrote: On 5/11/05, Autrijus Tang [EMAIL PROTECTED] wrote: In a somewhat related topic: pugs (1,(2,3),4)[2] 4 Because the invocant to .[] assumes a Singular context. Right, but the *inside* of the invocant is still a list, so it's in list context. I think that line should return 3. I am confused as to why exactly this is the case. Are you saying that nested lists like this flatten? That would certainly catch me off guard. Would you mind explaining that to me a little more? I'm confused as well. How does that play with Larry's comment: http://groups-beta.google.com/group/perl.perl6.language/browse_frm/thread/54a1135c012b97bf/d17b4bc5ae7db058?q=list+commarnum=5hl=en#d17b4bc5ae7db058 -- Aaron Sherman [EMAIL PROTECTED] Senior Systems Engineer and Toolsmith It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: (1,(2,3),4)[2]
On Thu, May 12, 2005 at 07:04:48AM +0800, Autrijus Tang wrote: : Please sanity-check. :-) Looks good to me. Though that should perhaps not be confused with sanity. Larry
Re: (1,(2,3),4)[2]
On Wed, May 11, 2005 at 06:24:38PM -0400, Aaron Sherman wrote: : I'm confused as well. How does that play with Larry's comment: : : http://groups-beta.google.com/group/perl.perl6.language/browse_frm/thread/54a1135c012b97bf/d17b4bc5ae7db058?q=list+commarnum=5hl=en#d17b4bc5ae7db058 Well, that approach would also work. I'm just not sure it's what people would expect. It's a little retroactive for .[] to change the context of the expressions in (). These days I think I'd rather have something out front that specifically says you want a list of scalars. Perhaps scalar(1,(2,3),4) should be our list of scalars context, and produce [1,[2,3],4]. Or maybe something else should indicate LoS. Larry
