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

I would treat it just the same as a literal hashref build with
{ => } because this should be what the dispatch system sees anyway.

sub assign { my $href = { a => 1, b => 2}; %h = $href }

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

Reply via email to