Re: Arrays, lists, referencing
On Saturday, February 15, 2003, at 08:47 AM, David Storrs wrote:
I can see five possible courses here:
1) We decide that my suggestion is a bad one and do nothing with it.
That's fine; I am not wedded to it, I just thought it was an
interesting idea that I wanted to raise.
2) (4, 1, 2) + 7 returns (9). This is C comma behavior, and I always
found it incredibly non-intuitive. I'd really like to get away
from this, even if it means that this expression is a fatal error
"Can't add scalar to list".
3) (4, 1, 2) + 7 returns (10), by adding 7 to the length of the list.
This makes lists look even more like arrays, and doesn't really add
any new power to the language.
4) (4, 1, 2) + 7 returns (11, 8, 9). This is a convenient shorthand
for the vector syntax, IMO.
5) (4, 1, 2) + 7 returns (14). That is, the list is collapsed into a
datatype matching the "RHS" by iteratively applying the operator in
question to the list elements, and then the item on the RHS of the
operator is applied. I'm not sure this is useful; I'm just
exploring options.
IMHO the only reasonable possibilities are (2) or (3)... the others are
much rarer in practice, and too prone to
accidental-invocation-with-baffling-results.
Agreed, however, that (2) is icky. My worry has been that removing
C-comma behavior would break common constructs, but I haven't been able
to find any that would really break (except obfuscated ones that would
be better written in some other fashion anyway.) Statements like:
foo() or (warn("blah"), next);
work either way, because they don't rely on getting the "scalar value"
of the list.
So, IMO, the only reasonable answer is (3)... that a list in numeric
context returns the length. Thus we have consistency between lists and
arrays:
(1,2,3) + 4 # --> (1,2,3).length + 4 --> 7 (list)
[1,2,3] + 4 # --> [1,2,3].length + 4 --> 7 (array ref)
my @a = (1,2,3); #
@a + 4# --> @a.length + 4 --> 7 (array var)
*@a + 4 # --> (*@a).length + 4 --> 7 (list)
(@a,@a) + 4 # --> 3 + 3 + 4 --> 10 (list)
Alternatively, we could say that using a list in numeric context is a
syntax error. This is fine w/ me as well, but pointedly *doesn't*
match the array behavior... and would mean the second to last line
would also be a syntax error.
I think the consistency of behavior probably means (3) wins.
MikeL
Re: Arrays, lists, referencing
Michael Lazzaro wrote: > So, IMO, the only reasonable answer is (3)... that a list in numeric > context returns the length. Thus we have consistency between lists > and arrays: > > (1,2,3) + 4 # --> (1,2,3).length + 4 --> 7 (list) > [1,2,3] + 4 # --> [1,2,3].length + 4 --> 7 (array ref) > > my @a = (1,2,3); # > @a + 4# --> @a.length + 4 --> 7 (array var) > *@a + 4 # --> (*@a).length + 4 --> 7 (list) > (@a,@a) + 4 # --> 3 + 3 + 4 --> 10 (list) > > Alternatively, we could say that using a list in numeric context is a > syntax error. This is fine w/ me as well, but pointedly *doesn't* > match the array behavior... I think having them doing different things is reasonable -- they _are_ different. An array is something tangible and as such can have operations on it. A list is something ephemeral, some scalars that happen to be together right now but don't have a collective identity. There can be operations on each of the individual items in a list but having an operation on them as a group seems odd to me. More practically, the length of a list is never interesting: a list by definition must be hardcoded into the program so its length is known at compile time. Indeed it should be known by whoever typed it in! > and would mean the second to last line would also be a syntax error. That seems fine by me. I can't see any reason why somebody would type that rather than the version on the line above. > I think the consistency of behavior probably means (3) wins. Why should different things behave in the same way? More pragmatically, somebody who has code with an explicitly hardcoded list which is used in scalar context has probably made a mistake -- there are so many better ways (to take the above example) of hardcoding the constant 7 into a program! Why would somebody write out each element of a list just to throw away most of the data and reduce it to an integer? In the case where somebody has made an error -- either a typo, or a conceptual error by somebody still learning the language -- it's much more useful to have a compilation error than for the code run but not yield the desired behaviour. Can somebody come up with a realistic example of where having a list be interpreted as its length is genuinely useful and isn't more easily written using some other syntax? Smylers
Re: Arrays, lists, referencing
> > 2) (4, 1, 2) + 7 returns (9). This is C comma behavior, and I always
> >found it incredibly non-intuitive. I'd really like to get away
> >from this, even if it means that this expression is a fatal error
> >"Can't add scalar to list".
[...]
> Agreed, however, that (2) is icky. My worry has been that removing
> C-comma behavior would break common constructs, but I haven't been able
> to find any that would really break (except obfuscated ones that would
> be better written in some other fashion anyway.) Statements like:
> foo() or (warn("blah"), next);
> work either way, because they don't rely on getting the "scalar value"
> of the list.
One thing that the C comma operator promises is that its left operand
(and all side effects) is completely evaluated before work starts on the
right operand. (This may not be strictly true in the Perl interpretation
of the operator; can a Perl5 developer comment?)
I'm pretty sure that for a Perl list, the order of evaluation of
elements isn't guaranteed, meaning that C may evaluate before
C in the above example if it were treated exactly like a list.
(Again, can someone refute or support this?)
That said, I don't know of anything that the C comma operator can do
that you couldn't equivalently do with a Perl5 C statement:
foo() or (do { warn("blah"); next; }); # Yes, it's ugly.
So I too support the notion that comma should always and only be a list
constructor.
--
Debbie Pickett http://www.csse.monash.edu.au/~debbiep [EMAIL PROTECTED]
Chaos, panic, & disorder - my work here is done. - button slogan
Re: Arrays, lists, referencing
On Tue, Feb 18, 2003 at 10:06:29PM -, Smylers wrote: > More practically, the length of a list is never interesting: a list by > definition must be hardcoded into the program so its length is known at > compile time. Indeed it should be known by whoever typed it in! Err, no. Eg in perl 5: $value = (1,2, @ARGV,3,4)[$i] That's a list, and its length is not known at compile time. Dave. -- Nothing ventured, nothing lost.
