Regex query
Simon Cozens
Well, I've started my Perl 6 programming career already and I've got
stuck. :)
I'm trying to parse a Linux RAID table (/etc/raidtab), which looks a
bit like this:
raiddev /dev/md0
raid-level 5
option value
option value
...
device /dev/sde1
raid-disk 0
device /dev/sdf1
raid-disk 1
device /dev/sdg1
raid-disk 2
...
raiddev /dev/md1
...
Here's the grammar I have so far:
grammar Raidtab;
rule raidtab { <raiddev>+ };
rule comment { <sp*> \# .* |
# Or a blank line
^^ \n };
rule comm_eol { <sp*> <comment>? <sp*> \n };
rule raiddev { <comment>*
<sp>* "raiddev" <sp>+ $name := (/dev/md\d+) <comm_eol>
(<devicelayout> | <option> | <comment>)+ };
rule option { <sp>* $key := (<[a-z]->+) <sp>* $value := (\w+) <comm_eol> };
rule devicelayout { <sp>* device <sp>+ $name := (/dev/\w+) <comm_eol>
<sp>* $type := (raid|spare|parity) -disk <sp>*
$index := (\d+) <comm_eol>
};
What I can't figure out is how to drill down into the returned match
object and get at individual devices. I'd expect to be able to say
something like
$matchobject{raiddev}[0]{devicelayout}[1]{name}
and get "/dev/sdf1". Is that how it works, with multiply-matched rules
being put into arrays, or is it stored differently somehow?
--
3rd Law of Computing:
Anything that can go wr
fortune: Segmentation violation -- Core dumped
Uri Guttman
SC> raiddev /dev/md0
SC> raid-level 5
SC> option value
SC> option value
SC> ...
SC> device /dev/sde1
SC> raid-disk 0
i have some comments/questions as i am trying to learn this myself. i
could be way off base but here goes:
SC> grammar Raidtab;
SC> rule raidtab { <raiddev>+ };
SC> rule comment { <sp*> \# .* |
shouldn't that . be \N so it won't eat the next line or even beyond?
also you have <sp*> here and <sp>* below. i think the latter is correct.
SC> # Or a blank line
SC> ^^ \n };
shouldn't that have a <sp*> inside the blank line?
SC> rule comm_eol { <sp*> <comment>? <sp*> \n };
aren't those <sp*>'s redundant? the first is overlapping with the one at
the beginning of comment. and the second is subsumed by the .* at the
end of comment.
SC> rule raiddev { <comment>*
i think that should be comm_eol as you want to skip all full comment lines.
SC> <sp>* "raiddev" <sp>+ $name := (/dev/md\d+) <comm_eol>
SC> (<devicelayout> | <option> | <comment>)+ };
same as above, comm_eol instead of comment.
SC> rule option { <sp>* $key := (<[a-z]->+) <sp>* $value := (\w+) <comm_eol> };
i think that char class should be <[a-z-]>. <[]> marks a class and the -
needs to be inside it.
the second <sp>* should be <sp>+ as you need whitespace between the
option and value.
SC> rule devicelayout { <sp>* device <sp>+ $name := (/dev/\w+) <comm_eol>
the \w+ after /dev/ needs to be more accepting as i think some devices
could be in subdirs
SC> <sp>* $type := (raid|spare|parity) -disk <sp>*
SC> $index := (\d+) <comm_eol>
SC> };
SC> What I can't figure out is how to drill down into the returned match
SC> object and get at individual devices. I'd expect to be able to say
SC> something like
SC> $matchobject{raiddev}[0]{devicelayout}[1]{name}
SC> and get "/dev/sdf1". Is that how it works, with multiply-matched rules
SC> being put into arrays, or is it stored differently somehow?
that is how i understand it. the grammar automatically build a tree of
the grabs with hash keys being the rule names and multiples (rules with
quantifiers) being arrays.
what about the case where you have a descending set of rules but no
quantifiers. would you just not have the [0] parts when you access it
from the match object?
uri
--
Uri Guttman ------ u...@stemsystems.com -------- http://www.stemsystems.com
----- Stem and Perl Development, Systems Architecture, Design and Coding ----
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
Simon Cozens
> shouldn't that have a <sp*> inside the blank line?
Or <sp>*, yes.
> SC> rule comm_eol { <sp*> <comment>? <sp*> \n };
>
> aren't those <sp*>'s redundant? the first is overlapping with the one at
> the beginning of comment.
But <comment> only matches if there *is* a comment, and there may not
be, so I want to match optional space at the EOL anyway.
> SC> rule raiddev { <comment>*
> i think that should be comm_eol as you want to skip all full comment lines.
I thought the .* (or \N*) would skip the whole line. comm_eol just means
"comment at end of line".
> i think that char class should be <[a-z-]>. <[]> marks a class and the -
> needs to be inside it.
Oops, typo.
> the second <sp>* should be <sp>+ as you need whitespace between the
> option and value.
Yes.
> SC> rule devicelayout { <sp>* device <sp>+ $name := (/dev/\w+) <comm_eol>
> the \w+ after /dev/ needs to be more accepting as i think some devices
> could be in subdirs
No, by stipulation. :) This is Linux, without devfs.
> that is how i understand it. the grammar automatically build a tree of
> the grabs with hash keys being the rule names and multiples (rules with
> quantifiers) being arrays.
Great.
--
You advocate a lot of egg sucking but you're not very forthcoming with the
eggs. - Phil Winterbottom (to ken)
Uri Guttman
SC> rule comm_eol { <sp*> <comment>? <sp*> \n };
>>
>> aren't those <sp*>'s redundant? the first is overlapping with the one at
>> the beginning of comment.
SC> But <comment> only matches if there *is* a comment, and there may not
SC> be, so I want to match optional space at the EOL anyway.
ok, but since comment is optional, if it doesn't match, the two <sp>*
are back to back. is that needed? i just see too many <sp>* and that
could lead to backtracking issues (something i recall from MRE1).
SC> rule raiddev { <comment>*
>> i think that should be comm_eol as you want to skip all full comment lines.
SC> I thought the .* (or \N*) would skip the whole line. comm_eol just means
SC> "comment at end of line".
i figured that was what it meant. but . matches any char now so .* will
eat all the text until it is forced to backtrack. so \N* will stop at
the newline which is what i think you want in comm_eol.
>> that is how i understand it. the grammar automatically build a tree of
>> the grabs with hash keys being the rule names and multiples (rules with
>> quantifiers) being arrays.
SC> Great.
actually i just had another thought. you don't need any of the $foo :=
stuff as the match tree will have it all for you. unless you need a
single var having some grabbed stuff, you might as well let the match
object hold it all. you do want a tree from this parser so the single
vars will do no good. unless they also put stuff into the tree based on
their names. also if you use a scalar to grab something which is in a
quantified outer rule what is put in the var? a ref to a list of the
grabbed things?
Simon Cozens
> actually i just had another thought. you don't need any of the $foo :=
> stuff as the match tree will have it all for you.
Yes, but it's nice to be able to access the captured things by
name. Or should I be saying things like
rule raiddev { <comment>*
<sp>* "raiddev" <sp>+ <name> <comm_eol>
(<devicelayout> | <option> | <comment>)+ };
rule name { /dev/md\d+ }
> their names. also if you use a scalar to grab something which is in a
> quantified outer rule what is put in the var? a ref to a list of the
> grabbed things?
*nod* Something I'd like to know.
--
"Even if you're on the right track, you'll get run over if you just sit there."
-- Will Rogers
Uri Guttman
SC> u...@stemsystems.com (Uri Guttman) writes:
>> actually i just had another thought. you don't need any of the $foo :=
>> stuff as the match tree will have it all for you.
SC> Yes, but it's nice to be able to access the captured things by
SC> name. Or should I be saying things like
SC> rule raiddev { <comment>*
SC> <sp>* "raiddev" <sp>+ <name> <comm_eol>
are the quotes there literals? they aren't in the file format i think.
SC> (<devicelayout> | <option> | <comment>)+ };
SC> rule name { /dev/md\d+ }
yeah, that should grab name in the match object as a hash element of the
raiddev level. or maybe it needs grab markers somewhere? i am not sure
it should be (<name>) in the raiddev rule or (/dev/md\d+) in the name
rule. both could work but give different places where the grab ends up.
Larry Wall
: > their names. also if you use a scalar to grab something which is in a
: > quantified outer rule what is put in the var? a ref to a list of the
: > grabbed things?
:
: *nod* Something I'd like to know.
Yes, in fact any list forced into scalar context will make a ref in Perl 6:
$arrayref = (1,2,3);
Larry
Larry Wall
: Is that "any list" as oppopsed to "any array"? Or is that arrayref in a
: numeric context the length of the array? In other words does this do
: what I think I think it does?
:
: $shouldbe3 = (1,2,3) + 0;
It's 3, though not for the reason a Perl 5 programmer would think.
(In Perl 6 it's the length of the anonymous array, not the last value.)
Larry
Aaron Sherman
Is that "any list" as oppopsed to "any array"? Or is that arrayref in a
numeric context the length of the array? In other words does this do
what I think I think it does?
$shouldbe3 = (1,2,3) + 0;
--
Aaron Sherman <a...@ajs.com>
Aaron Sherman
John Williams
>
> Yes, in fact any list forced into scalar context will make a ref in Perl 6:
>
> $arrayref = (1,2,3);
That would seem to obviate the need for brackets to define array
references. Is there any case where [1,2,3] would be needed instead of
(1,2,3)?
Also, does "any" list include a list of pairs? Because that would look
more like a hash than a list.
$ref = ( one => 1, two => 2, three => 3);
~ John Williams
Larry Wall
: On Fri, 20 Sep 2002, Larry Wall wrote:
: >
: > Yes, in fact any list forced into scalar context will make a ref in Perl 6:
: >
: > $arrayref = (1,2,3);
:
: That would seem to obviate the need for brackets to define array
: references. Is there any case where [1,2,3] would be needed instead of
: (1,2,3)?
Sure, in a list context. [1,2,3] is really short for scalar(1,2,3).
: Also, does "any" list include a list of pairs? Because that would look
: more like a hash than a list.
:
: $ref = ( one => 1, two => 2, three => 3);
Sure. If you really want a hash, use {...}. (Extra rules apply
for parameter lists, though.)
Larry
John Williams
> On Fri, 20 Sep 2002, John Williams wrote:
> : On Fri, 20 Sep 2002, Larry Wall wrote:
> : >
> : > Yes, in fact any list forced into scalar context will make a ref in Perl 6:
> : >
> : > $arrayref = (1,2,3);
> :
> : That would seem to obviate the need for brackets to define array
> : references. Is there any case where [1,2,3] would be needed instead of
> : (1,2,3)?
>
> Sure, in a list context. [1,2,3] is really short for scalar(1,2,3).
I was just thinking that $((1,2,3)) is also the same as [1,2,3],
and shorter than scalar(1,2,3).
~ John Williams
Matt Diephouse
>On Fri, 20 Sep 2002, Larry Wall wrote:
>
>
>>On Fri, 20 Sep 2002, John Williams wrote:
>>: On Fri, 20 Sep 2002, Larry Wall wrote:
>>: >
>>: > Yes, in fact any list forced into scalar context will make a ref in Perl 6:
>>: >
>>: > $arrayref = (1,2,3);
>>:
>>: That would seem to obviate the need for brackets to define array
>>: references. Is there any case where [1,2,3] would be needed instead of
>>: (1,2,3)?
>>
>>Sure, in a list context. [1,2,3] is really short for scalar(1,2,3).
>>
>>
>
>I was just thinking that $((1,2,3)) is also the same as [1,2,3],
>and shorter than scalar(1,2,3).
>
I wonder if you can't just use $(1, 2, 3) to the same effect. Also, I
wonder if you can do this:
my @LoL = ( ("1a", "2a"),
("1b", "2b"),
("1c", "2c") );
If you can, the only case where I could see [1, 2, 3] being necessary is
in a sub call where the parameters are wrapped in parentheses.
md |- matt diephouse
Luke Palmer
> >and shorter than scalar(1,2,3).
> >
> I wonder if you can't just use $(1, 2, 3) to the same effect.
I think you can. I was under the impression that the C comma was dying,
so that would have to make a list or err.
> Also, I
> wonder if you can do this:
> my @LoL = ( ("1a", "2a"),
> ("1b", "2b"),
> ("1c", "2c") );
>
Yeah, I think to get Perl5 behavioueaur :), you do this:
my @flatL = ( *("1a", "2a"), *("1b", "2b") );
Does this do the same thing?
my @flatL = *( ("1a", "2a"), ("1b", "2b") );
(Heh, I just got a fun thought:)
my $traversal_time = 2***@list;
> If you can, the only case where I could see [1, 2, 3] being necessary is
> in a sub call where the parameters are wrapped in parentheses.
Not even then, if $(1, 2, 3) is allowed. If so, it might be possible to
find another use for [...]. I like that syntax, but if we need a
balanced delimiter to do something else, that could be it...
Of course, the parallel [...] to @foo[...] goes nicely with
{...} to %foo{...}, so it will probably stay.
Luke
Luke Palmer
> According to Luke Palmer:
> > I think to get Perl5 behavioueaur :), you do this:
> >
> > my @flatL = ( *("1a", "2a"), *("1b", "2b") );
>
> Geez, I hope not, because that would imply that in
>
> my @v = ( &func() );
>
> that &func is called in a scalar context.
What? No it wouldn't. I was talking about Perl5 behavioueaur in the
exampeaule. In that *(blah blah) flattens lists, not provides scalar
context or whatever you were saying.
my @v = $( &func() );
Would provide scalar context. But then assign it to a list...
Luke
Chip Salzenberg
> I think to get Perl5 behavioueaur :), you do this:
>
> my @flatL = ( *("1a", "2a"), *("1b", "2b") );
Geez, I hope not, because that would imply that in
my @v = ( &func() );
that &func is called in a scalar context.
--
Chip Salzenberg - a.k.a. - <ch...@pobox.com>
"It furthers one to have somewhere to go."
David Whipp
> : $shouldbe3 = (1,2,3) + 0;
>
> It's 3, though not for the reason a Perl 5 programmer would think.
> (In Perl 6 it's the length of the anonymous array, not the
> last value.)
This kind of clever magic always makes me nervous:
it introduces subtle bug potentials.
(7,8,9) == 3 # true
(7,8) == 2 # true
(7) == 1 # false
() == 0 # true?
As someone who regularly writes code generators -- and even as
someone who occasionally edits code without thinking straight,
I am certain that I will, on occasion, introduce bugs through
this mechanism. If the [] list-ref composers are to remain,
there seems no good reason to add a redundant behaviour to
parentheses. Or am I missing something?
Dave.
Chip Salzenberg
> (7,8,9) == 3 # true
> (7,8) == 2 # true
> (7) == 1 # false
> () == 0 # true?
Hell, yes, why didn't I think of that? This is exactly the same
problem that afflicts Python's tuple syntax!
Larry, I strongly suggest that making () act in any way like []
is a VERY BAD IDEA.
John Williams
> Larry wrote:
> > : $shouldbe3 = (1,2,3) + 0;
> >
> > It's 3, though not for the reason a Perl 5 programmer would think.
> > (In Perl 6 it's the length of the anonymous array, not the
> > last value.)
>
> This kind of clever magic always makes me nervous:
> it introduces subtle bug potentials.
>
> (7,8,9) == 3 # true
> (7,8) == 2 # true
> (7) == 1 # false
> () == 0 # true?
I believe the last two cases should be:
(7,) == 1
(,) == 0
Because its the perl6 comma that creates the list, not the parenthesis.
~ John Williams
Tanton Gibbs
> > it introduces subtle bug potentials.
> >
> > (7,8,9) == 3 # true
> > (7,8) == 2 # true
> > (7) == 1 # false
> > () == 0 # true?
>
> I believe the last two cases should be:
>
> (7,) == 1
> (,) == 0
>
> Because its the perl6 comma that creates the list, not the parenthesis.
>
> ~ John Williams
If this is the case, then can you also have:
(,7)
What is its length?
Tanton
Chip Salzenberg
> I believe the last two cases should be:
> (7,) == 1
> (,) == 0
Gack! It's Python's tuple syntax! Run away! Run away!
Seriously, having actually programmed Python for money (no smiley --
it was NOT fun), I can say that this syntactical hack would be a
horrible choice for borrowing from Python. Heck, I'd rather Perl take
Python's "import" than this abomination of punctuation.
John Williams
> > I believe the last two cases should be:
> >
> > (7,) == 1
> > (,) == 0
> >
> > Because its the perl6 comma that creates the list, not the parenthesis.
> >
> > ~ John Williams
>
> If this is the case, then can you also have:
>
> (,7)
>
> What is its length?
Hmm, it's a syntax error in perl5. Maybe () is still the empty list in
perl6, since it's not ambiguously something else. But I cannot tell
whether (7) is list context or numeric context, so it seems like the
listifying comma is needed to disambiguate, especially if it's next to a
numeric comparison operator.
~ John Williams
Jonathan Scott Duff
> On Fri, 20 Sep 2002, Tanton Gibbs wrote:
> > If this is the case, then can you also have:
> >
> > (,7)
> >
> > What is its length?
>
> Hmm, it's a syntax error in perl5.
I'd advocate it continuing to be a syntax error in perl 6.
> Maybe () is still the empty list in perl6, since it's not ambiguously
> something else.
Sounds good to me..
> But I cannot tell whether (7) is list context or numeric context,
Nope, you can't tell without the surrounding context:
(7) + 0; # numeric
$a = (7); # list
(7) == 1; # boolean (same as (7).length == 1)
> so it seems like the listifying comma is needed to disambiguate,
> especially if it's next to a numeric comparison operator.
I don't think so.
-Scott
--
Jonathan Scott Duff
du...@cbi.tamucc.edu
Jonathan Scott Duff
> Larry wrote:
> > : $shouldbe3 = (1,2,3) + 0;
> >
> > It's 3, though not for the reason a Perl 5 programmer would think.
> > (In Perl 6 it's the length of the anonymous array, not the
> > last value.)
>
> This kind of clever magic always makes me nervous:
> it introduces subtle bug potentials.
>
> (7,8,9) == 3 # true
> (7,8) == 2 # true
> (7) == 1 # false
Why is this one false? I'd expect it to be true just as the others.
> () == 0 # true?
Same here.
> . If the [] list-ref composers are to remain,
> there seems no good reason to add a redundant behaviour to
> parentheses. Or am I missing something?
I tend to agree with you here though. We could both be missing
something :-)
Jonathan Scott Duff
> According to John Williams:
> > I believe the last two cases should be:
> > (7,) == 1
> > (,) == 0
>
> Gack! It's Python's tuple syntax! Run away! Run away!
>
> Seriously, having actually programmed Python for money (no smiley --
> it was NOT fun), I can say that this syntactical hack would be a
> horrible choice for borrowing from Python.
I would be surprised if the entire Perl community didn't unanimously
agree with you. I know this is one of the pythonisms that bugs me the
most.
Tanton Gibbs
> > it introduces subtle bug potentials.
> >
> > (7,8,9) == 3 # true
> > (7,8) == 2 # true
> > (7) == 1 # false
>
> Why is this one false? I'd expect it to be true just as the others.
(7) == 7
why? Otherwise, we couldn't use parens for mathematical expressions
(3 + 4) == 7 -- the mathematical way
(3 + 4) == 1 -- the length of the list ... BAD!
Tanton
John Williams
> > But I cannot tell whether (7) is list context or numeric context,
>
> Nope, you can't tell without the surrounding context:
>
> (7) + 0; # numeric
> $a = (7); # list
> (7) == 1; # boolean (same as (7).length == 1)
No, that last one is clearly numeric context. == operates on numbers and
returns boolean. I can't tell whether (7).length is asking for the length
of 7 or the length of a list, but I would be badly surprised if
(3+4).pow(2) returned 1 instead of 49.
~ John Williams
Smylers
> my @v = $( &func() );
>
> Would provide scalar context. But then assign it to a list...
In the course of reading that I developed a concern about memory usage
when trying to find the size of arrays. As I understand it the Perl 5
syntax for discovering the number of elements in a list will still work:
$num = @massive;
C<$num> becomes a reference to C<@massive>, but in a numeric context it
will evaluate to the number of elements in that array.
Suppose C<@massive> had 10_000 strings in it, and it goes out of scope
but C<$num> stays in scope or its value is returned from a function. If
C<$num> is just going to be used as a number then only the 10_000 needs
to be stored in it, and the data in C<@massive> can be freed.
But because C<$num> _might_ be used as an array ref, the data has to be
kept around, which is wasteful.
Does that matter? This example is fairly contrived, and anybody
actually concerned about this can always use:
$num = @massive.length;
So perhaps this isn't a problem.
Smylers
Smylers
> (7) == 7
>
> why? Otherwise, we couldn't use parens for mathematical expressions
<Evil> But as Luke Palmer pointed about above, this syntax would make
square brackets redundant, so we could now use those unambiguously for
overriding mathematical precedence ... </Evil>
(Sorry about that.)
I had been intending posting that purely as a joke, but the more I think
about it the more I wonder whether there could be something in this. As
Luke also pointed out square brackets for arrays make sense because they
are also used for array indices.
So if the difference between lists with parens and anon arrays with
square brackets is going away, it may make sense to standardize on the
latter rather than the former. In other words, lists now use square
brackets.
That frees up parens for overriding precedence:
> (3 + 4) == 7 -- the mathematical way
> (3 + 4) == 1 -- the length of the list ... BAD!
(3 + 4) == 7
[3 + 4] == 1
I haven't thought this through properly, so there's a high chance it
won't work.
Function params with square brackets would look really odd, so they've
have to count as 'precedence' rather than 'list' (which is largely true:
Perl allows parens to be omitted from sub calls if the precedence is OK
even when the params are a list).
Assigning a list to an array would look like this:
my @odd = [1, 3, 5, 7];
So the (comparatively rare) case of wanting to have an array contain an
anonymous array reference in its first element and nothing else would
require an extra set of brackets:
my @foo = [[1, 3, 5, 7]];
That isn't too bad: the doubled brackets provide a visual clue that
there's two dimensions in the array.
This still seems a bit far-fetched to me, but I don't yet like it less
than the other options ...
Smylers
Jonathan Scott Duff
> On Fri, 20 Sep 2002, Jonathan Scott Duff wrote:
> > > But I cannot tell whether (7) is list context or numeric context,
> >
> > Nope, you can't tell without the surrounding context:
> >
> > (7) + 0; # numeric
> > $a = (7); # list
> > (7) == 1; # boolean (same as (7).length == 1)
>
> No, that last one is clearly numeric context. == operates on numbers and
> returns boolean.
Oh, you're right. Arrays (and lists I presume by Larry's previous
posts) return the number of elements when used in a numeric context.
> I can't tell whether (7).length is asking for the length
> of 7 or the length of a list, but I would be badly surprised if
> (3+4).pow(2) returned 1 instead of 49.
So, you expect 7.pow(2) to work? I'd expect it to be an error (this
isn't python after all).
John Williams
> > I can't tell whether (7).length is asking for the length
> > of 7 or the length of a list, but I would be badly surprised if
> > (3+4).pow(2) returned 1 instead of 49.
>
> So, you expect 7.pow(2) to work? I'd expect it to be an error (this
> isn't python after all).
Larry said in Apocalypse 2 that things should act like objects if we ask
them to, but I suppose the details will wait until Apocalypse 10-12.
Maybe 7.operator:**(2) would be more correct.
Anyway, (7) or (3+4) should yield a number, not a list, because otherwise
every math expression will break. Consider:
$a = (7); $b = ( $x + $y );
Both () are in scalar context, not list or numeric. You can easily make
it a list with (7,) or [7] but you could only make it a number with
numeric(7) (if the numeric() counterpart to scalar() exists). +(7) could
still be the length of a list.
Of course there are non-numeric contexts too, such as ("a"). Would it be
fair to say that parenthesis should not alter the context when used in
expressions?
~ John Williams
John Williams
>
> Does that matter? This example is fairly contrived, and anybody
> actually concerned about this can always use:
>
> $num = @massive.length;
>
> So perhaps this isn't a problem.
$num = +@massive;
would also set $num to the length, not the ref.
~ John Williams
Jonathan Scott Duff
> On Sat, 21 Sep 2002, Jonathan Scott Duff wrote:
> > > I can't tell whether (7).length is asking for the length
> > > of 7 or the length of a list, but I would be badly surprised if
> > > (3+4).pow(2) returned 1 instead of 49.
> >
> > So, you expect 7.pow(2) to work? I'd expect it to be an error (this
> > isn't python after all).
>
> Larry said in Apocalypse 2 that things should act like objects if we ask
> them to, but I suppose the details will wait until Apocalypse 10-12.
> Maybe 7.operator:**(2) would be more correct.
>
> Anyway, (7) or (3+4) should yield a number, not a list, because otherwise
> every math expression will break. Consider:
People keep saying that and I think "tyranny of the OR" (See "Built
to Last" by James Collins and Jerry Porras)
Why can't perl be smart enough to figure out what we mean? Something
along these lines:
(7) # list context
(3+4) # numeric context (there's a numeric operator in there)
(3+4,5) # list context (comma trumps the numeric op)
Okay, I admit it mayn't be the best idea in the world, but I'm
following this line of discussion in case it leads anywhere
interesting. And if nothing else, I'm giving real good reasons for
why *not* to do this :-)
Oh, and if they want "(3+4)" in list context, they can be explicit
"list(3+4)" This strikes me as an edge case far on the fringe
of what people normally do though.
> $a = (7); $b = ( $x + $y );
>
> Both () are in scalar context, not list or numeric. You can easily make
> it a list with (7,) or [7] but you could only make it a number with
(7,) is an abomination. It's one of python's misfeatures that annoys
me the most.
> numeric(7) (if the numeric() counterpart to scalar() exists).
It seems to me that numeric() would only be useful on one element
lists (indeed, most of this discussion only applies to one element
lists). If that's the case, it's real easy for me to tell the
programmer "Don't do that" if they're putting parens around their
single element lists.
> +(7) could still be the length of a list.
If we keep () as synonym to [], then that's what I'd expect it to be.
> Of course there are non-numeric contexts too, such as ("a"). Would it
> be fair to say that parenthesis should not alter the context when used
> in expressions?
Looks like a single element list from where I sit right now i-)
Luke Palmer
> Luke Palmer wrote:
>
> > my @v = $( &func() );
> >
> > Would provide scalar context. But then assign it to a list...
>
> In the course of reading that I developed a concern about memory usage
> when trying to find the size of arrays. As I understand it the Perl 5
> syntax for discovering the number of elements in a list will still work:
>
> $num = @massive;
>
> C<$num> becomes a reference to C<@massive>, but in a numeric context it
> will evaluate to the number of elements in that array.
No. C<$num> becomes a reference to C<@massive>. If it was I<assigned> in
numeric context, it will hold the number of elements.
$num = @massive; # $num is a reference
$num = +@massive; # $num is 10_000
I think C<$num> does evaluate to the number of elements if you use it in
numeric context (in the first one), but in the second, it doesn't hold
that reference. This solves your problem.
> Suppose C<@massive> had 10_000 strings in it, and it goes out of scope
> but C<$num> stays in scope or its value is returned from a function. If
> C<$num> is just going to be used as a number then only the 10_000 needs
> to be stored in it, and the data in C<@massive> can be freed.
>
> But because C<$num> _might_ be used as an array ref, the data has to be
> kept around, which is wasteful.
The programmer should know whether it would or wouldn't, so he could put +
or not.
> Does that matter? This example is fairly contrived, and anybody
> actually concerned about this can always use:
>
> $num = @massive.length;
>
> So perhaps this isn't a problem.
>
> Smylers
Luke
Markus Laire
> > On Sat, 21 Sep 2002, Jonathan Scott Duff wrote:
> >
> > Anyway, (7) or (3+4) should yield a number, not a list, because
> > otherwise every math expression will break.
>
> along these lines:
> (7) # list context
> (3+4) # numeric context (there's a numeric operator in there)
> (3+4,5) # list context (comma trumps the numeric op)
It would be a total nightmare to try to DWIM in this case, especially
with userdefined operators or more complex expressions.
There are 101 reasons why parens shouldn't make lists and how it can
make mathematical expressions do something totally unexpected.
Consider changing a program where you have many mathematical
expressions.
$x = $y / (($a + $b) * $c - $d);
If you later find out that $b or $d can be left out, I expect to be
able to just remove it without need to check if any parentheses now
contains only one value, and then to remove parens also.
Also machine-generated expressions would have to be double-checked
for any single values in parentheses. Latest Perl-Golf tournament
'Infix to RPN' used testcases like
(18*16*16*5-1+12+15+18*1-8+6/7-6-2-(19)*(17))+8+((9/14))
This is valid mathematical expression in perl5 but would do something
totally different in perl6 because of those 'one-element lists'
--
Markus Laire 'malaire' <markus...@nic.fi>
Luke Palmer
> > On Sat, Sep 21, 2002 at 11:36:49AM -0600, John Williams wrote:
> > > On Sat, 21 Sep 2002, Jonathan Scott Duff wrote:
> > >
> > > Anyway, (7) or (3+4) should yield a number, not a list, because
> > > otherwise every math expression will break.
> >
> > Why can't perl be smart enough to figure out what we mean? Something
> > along these lines:
> > (7) # list context
> > (3+4) # numeric context (there's a numeric operator in there)
> > (3+4,5) # list context (comma trumps the numeric op)
>
> It would be a total nightmare to try to DWIM in this case, especially
> with userdefined operators or more complex expressions.
>
>
> There are 101 reasons why parens shouldn't make lists and how it can
> make mathematical expressions do something totally unexpected.
>
> Consider changing a program where you have many mathematical
> expressions.
>
> $x = $y / (($a + $b) * $c - $d);
>
> If you later find out that $b or $d can be left out, I expect to be
> able to just remove it without need to check if any parentheses now
> contains only one value, and then to remove parens also.
You know, the idea that square brackets are the only things that can make
lists is starting to really appeal to me. Similar for squiggles and
hashes. I don't know how many times in my early Perl5 days I did this:
%colors = {
red => 'ff0000',
green => '00ff00',
... };
By looking at it, it seems to make perfect sense. I don't even know what
it does, but it wasn't WIM. How can a hash have only one element?
Since we now have an explicit flattening operator (unary *), there's no
need to differentiate between a "real" list and a reference to one. We
could extend it to sub calls:
print["foo ", "bar"];
But that would look like Mathematica, which would be creepy. It would be
good to keep parens in sub calls (and declarations), but the details on
how that unifies are wrinkly. Of course, they were never ironed anyway:
print "foo ", "bar";
So parens really do provide grouping, not list constructing. Thus, this
can stay:
print("foo ", "bar");
It also provides a really nice visual clue: If and only if you see [],
there's a list creeping around. Before, the "and only if" could not be
included.
Sure, it's not clean yet, but I presume it could be. Objections?
Suggestions? Obsessions?
Luke
Matt Diephouse
>On Sun, 22 Sep 2002, Markus Laire wrote:
>You know, the idea that square brackets are the only things that can make
>lists is starting to really appeal to me. Similar for squiggles and
>
<snip>
>So parens really do provide grouping, not list constructing. Thus, this
>can stay:
>
> print("foo ", "bar");
>
>It also provides a really nice visual clue: If and only if you see [],
>there's a list creeping around. Before, the "and only if" could not be
>included.
>
This could take care of ambiguous situations like:
print (1, 2, 3), "\n";
I don't know how many times I've done that and wanted it to print
"123\n". I know it's a feature, but it can be a bug in my writing. Now
it'd be unambiguous:
print [1, 2, 3], "\n";
--matt diephouse
Simon Cozens
> Why can't perl be smart enough to figure out what we mean?
We're talking about lists, the second most fundamental data structure
in the language.
If we have to resort to much magic to get these right, we're pretty much
doomed from the outset.
--
There seems no plan because it is all plan.
-- C.S. Lewis
Simon Cozens
> Does that matter? This example is fairly contrived, and anybody
> actually concerned about this can always use:
>
> $num = @massive.length;
I'd be in favour of forcing people to say this if they want the length
of the array.
But then, it might be that what I want is Pythonish and not Perlish.
--
This process can check if this value is zero, and if it is, it does
something child-like.
-- Forbes Burkowski, CS 454, University of Washington
Pixel
> According to David Whipp:
> > (7,8,9) == 3 # true
> > (7,8) == 2 # true
> > (7) == 1 # false
> > () == 0 # true?
>
> Hell, yes, why didn't I think of that? This is exactly the same
> problem that afflicts Python's tuple syntax!
various 1-uple syntaxes:
a or [a] Ruby
a, Python
tuple([a]) Python
(a) Perl
((a)) merd
{a} Smalltalk
"http://merd.net/pixel/language-study/syntax-across-languages.html#Various Data Types"
Dan Sugalski
>So, you expect 7.pow(2) to work? I'd expect it to be an error (this
>isn't python after all).
Sure, why not? I mean, we already use methods on integers all the
time--what do you thin 12.5 is anyway, other than calling the 5
method on the constant 12? :)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Markus Laire
How do you do C< ($a + $b) * $c > if parentheses are forbidden for
mathematical expressions?
Simon Cozens
> How do you do C< ($a + $b) * $c > if parentheses are forbidden for
> mathematical expressions?
I thought that , was actually the list constructor, much as => is the
pair constructor. (And hence
a => 1, b => 2
would be a list of pairs.)
Of course, if we're being rigorously regular, this would mean that the
parentheses were optional, and
@a = 1,2,3,4;
would make sense.
I quite like that.
--
"How should I know if it works? That's what beta testers are for. I only
coded it."
(Attributed to Linus Torvalds, somewhere in a posting)
John Williams
>
> Why can't perl be smart enough to figure out what we mean? Something
> along these lines:
>
> (7) # list context
> (3+4) # numeric context (there's a numeric operator in there)
> (3+4,5) # list context (comma trumps the numeric op)
My understanding of context (which admittedly, may be completely
incorrect) is that context is imposed from the outside. So in (3+4), 3
and 4 are in numeric contect because the '+' says so, but we can't tell
what context (...) is in, because there is no context. + has higher
precendence than comma, so the 3+4 becomes 7 before the comma creates a
list: 7,5.
A different workaround just occurred to me for perl6. Maybe instead of
(7) having list context imposed by the parenthesis, imposing list context
on a scalar automatically creates a 1 item list. So:
@a = (7);
is the same as
@a = 7;
And actually, that works in perl5 too.
So maybe we're arguing about nothing?
> (7,) is an abomination. It's one of python's misfeatures that annoys
> me the most.
Strangely enough, it's one of the features of perl that I really like,
although you have to think of it in the context of
(
'a',
'long',
'list',
'of',
'items',
'one',
'per',
'line', # <-- notice the comma!
)
Of course, _requiring_ the comma is bad, but as long as we can use [7] or
rely on list context creating a single item list out of a single item, it
is not required.
~ John Williams
Chip Salzenberg
> On Sat, 21 Sep 2002, Jonathan Scott Duff wrote:
> > (7,) is an abomination. It's one of python's misfeatures that annoys
> > me the most.
>
Well, I don't know about Jonathan, but requiring the comma is exactly
what Python does[1], and I'm sure I don't want that misfeature in Perl.
[1] for tuples in (), that is. lists use []
Andrew Rodland
> You know, the idea that square brackets are the only things that can
> make lists is starting to really appeal to me. Similar for squiggles
> and hashes. I don't know how many times in my early Perl5 days I did
> this:
> Since we now have an explicit flattening operator (unary *), there's
> no need to differentiate between a "real" list and a reference to one.
> We
> could extend it to sub calls:
>
> print["foo ", "bar"];
>
> But that would look like Mathematica, which would be creepy. It would
> be good to keep parens in sub calls (and declarations), but the
> details on how that unifies are wrinkly. Of course, they were never
> ironed anyway:
>
> print "foo ", "bar";
>
> So parens really do provide grouping, not list constructing. Thus,
> this can stay:
>
> print("foo ", "bar");
>
> It also provides a really nice visual clue: If and only if you see
> [], there's a list creeping around. Before, the "and only if" could
> not be included.
>
> Sure, it's not clean yet, but I presume it could be. Objections?
> Suggestions? Obsessions?
I really really like this. The list/precedence ambiguity can sometimes
cause some really nasty confusion... and there's something to be said
for matching the array-construction symbol with the array-lookup one,
and hash-construction with hash-lookup as well.
P.S. Delurk.
Simon Cozens
> Since we now have an explicit flattening operator (unary *), there's no
> need to differentiate between a "real" list and a reference to one.
What context does "push" impute on its operands?
If
push @a, [1,2,3,4];
and
push @a, 1,2,3,4;
are going to be the same, you'll have real problems. I don't fancy doing
push @a, [[1,2,3,4]];
And if you get around that by special-casing push to take an list of scalar
contexts, then, well, urgh.
--
UNIX was not designed to stop you from doing stupid things, because that
would also stop you from doing clever things.
-- Doug Gwyn
Aaron Sherman
> So if the difference between lists with parens and anon arrays with
> square brackets is going away, it may make sense to standardize on the
> latter rather than the former. In other words, lists now use square
> brackets.
>
> That frees up parens for overriding precedence:
>
> > (3 + 4) == 7 -- the mathematical way
> > (3 + 4) == 1 -- the length of the list ... BAD!
>
> (3 + 4) == 7
> [3 + 4] == 1
I don't disagree that this is a good thing, but let's look at some cases
that might not look the way you had intended:
[$a,$b,$c] = [1,2,3]; # or is that ($a,$b,$c)?
my($x,$y,$z) = [1,2,3];
[1,2,3][1] == 2;
Thoughts?
--
Aaron Sherman <a...@ajs.com>
Luke Palmer
> fibo...@babylonia.flatirons.org (Luke Palmer) writes:
> > Since we now have an explicit flattening operator (unary *), there's no
> > need to differentiate between a "real" list and a reference to one.
>
> What context does "push" impute on its operands?
>
> If
> push @a, [1,2,3,4];
> and
> push @a, 1,2,3,4;
> are going to be the same, you'll have real problems. I don't fancy doing
> push @a, [[1,2,3,4]];
>
> And if you get around that by special-casing push to take an list of scalar
> contexts, then, well, urgh.
Aha! Kudos, Simon, this (alongside Aaron's message) was a stumper. But I
think I've got it!
push @a: [1,2,3,4];
pushes an array ref onto @a.
push @a: *[1,2,3,4];
pushes 1, 2, 3, and 4 onto @a (as it would without the * and []).
[$a, $b] = [$b, $a];
is a syntax error (assignment to non-lvalue).
[$a, $b] ^= [$b, $a];
Assigns $a to $b and $b to $a. C<my> would return a list of its
declarees, so:
my($a, $b) ^= [1, 2];
would work. Finally,
[1,2,3][1] == 2
means
[1,2,3].[1] == 2
which is fine.
Luke
Trey Harris
Damian or Allison will grace us with a resolution soon. :-)
May I suggest that we start with some DWIMmy examples and try to arrive at
a mechanism that will make them all DWIM? Here are my opinions, feel free
to shoot them down if you disagree:
1. Subroutines calls.
Given the prototype
sub func(*@ary);
Then
func(X, Y, ..., Z)
should be equivalent to
(func X, Y, ..., Z)
Given the prototype
sub func($scalar);
with no other definitions of func(), then
func(X, Y, ..., Z)
should raise an exception, while
(func X, Y, ..., Z)
should be equivalent to
((func X), Y, ..., Z)
and create a list.
2. Scalar assignment.
my $a; # 1.
$a = X;
my $a; # 2.
$a = X;
my $a; # 3.
($a) = X;
my($a) = X; # 4.
my($a) = (X); # 5.
These should all do the same thing, regardless of X.
3. Precedence.
Adding an additional set of parentheses around an expression already
surrounded by parentheses should never cause that expression to change
meaning. That is to say
(N) === ((N))
(=== meaning "is equivalent to") for all expressions N. Precedence is one
of the hardest things for many programmers, especially unsophisticated
ones, to grasp. At least in Perl 5, the programmer can always overdo it
with parentheses if she is unsure. Requiring that the programmer get
precedence *exactly* right, because one too many parens will result in
coercion of the expression into a list, and thus usually coerced
numerically back to the value 1, is completely unacceptable.
4. Numeric value.
The progression spoken about at great length previously:
+() # == 0
+(0) # == WHAT? 0? 1?
+(0,1) # == 2
+(0,1,2) # == 3
+(0,1,2,3) # == 4
+(0,...,n) # == n + 1
is largely irrelevant to the ways people use Perl. It may look odd framed
so clearly as a progression, but programmers do not ordinarily create
literal lists simply in order to take the length of them. This is a cute
programming puzzle that sadistic technical interviewers will foist on
frightened young job candidates in a few years, but I think it has little
bearing on language design.
Thus, item 3 on precedence above usually applies even in the N === (N)
case (though it may sometimes fail to apply because of parsing rules).
And the answer to WHAT above is 0, aesthetics of the progression be
damned.
5. Assignment to arrays and lists.
The following should be vaild:
($a, $b) = ($b, $a); # swaps $a and $b
($a, $b) = (1, 2); # $a == 1, $b == 2
($a, $b, $c) ^*= 2; # doubles each of $a, $b and $c
@a = (1, 2, 3); # Same as Perl 5
$a = (1, 2, 3); # Same as Perl 5's $a = [1,2,3];
6. List slicing.
These expressions should both be valid and have the value 2:
(1,2,3,4)[1]
[1,2,3,4][1]
7. Miscellanea.
for 1,2,3,4 { ... }
should be equivalent to
for (1,2,3,4) { ... }
and
for 1,["a","b","c"],3 { print "x"; }
should print "xxx".
What
for (1,("a","b","c"),3 { ... }
and
for 1,("a","b","c"),3 { ... }
do is left for Larry and/or Damian to answer, but whatever they do, the
two lines should be equivalent.
Now that I've ventured away from DWIMs and more into WIHDTEMs (What In
Hell Does This Expression Mean), is the above equivalent to
for 1,qw(a b c), 3 { ... }
as well?
A final unresolved question. I take it that the splat operator is a
deeply flattening operator. For instance,
*[1,[2,[3,4,5]],6]
will be converted into
[1,2,3,4,5,6]
It seems that, if the new order does allow the creation of
multi-dimensional things using simply (), that we also need a "shallowly
flattening operator". That is, it would convert the above list into
[1,2,[3,4,5],6]
Otherwise, the flattening required by the new syntax can go wild and cause
unwanted flattening in data structures being passed around.
--
In conclusion, my reading of what Larry has said is compatible with the
above--ASSUMING that
$a = (7);
causes $a to have the value 7, not the value [7]. If it has the value
[7], as seems to be the result of the reduction that many here have been
doing, then we have a very large problem with precedence, because as I
said in item 3, we can't rely on people getting the paren count exactly
right. Several other DWIMs above also fall apart.
So, if you want to create a one-item list, you're left with
$a = [7];
or possibly
$a = @(7);
It seems to me that the vagaries of the one-element list and the coarse
level of control provided by the flattening operator has gotten us into
this level of confusion. I hope Larry, Damian, Allison or somebody "in
charge" :-) can help us out of it.
Trey
Simon Cozens
> push @a: [1,2,3,4];
>
> pushes an array ref onto @a.
>
> push @a: *[1,2,3,4];
>
> pushes 1, 2, 3, and 4 onto @a (as it would without the * and []).
Remind me which language this is supposed to be, again?
--
"Life sucks, but it's better than the alternative."
-- Peter da Silva
Simon Cozens
> May I suggest that we start with some DWIMmy examples
Sam sat on the ground and put his head in his hands. 'I wish I had
never come here, and I don't want to see no more magic,' he said, and
fell silent.
--
I hooked up my accelerator pedal in my car to my brake lights. I hit the gas,
people behind me stop, and I'm gone. -- Steven Wright
Luke Palmer
> On Mon, Sep 23, 2002 at 04:58:55PM -0400, Trey Harris wrote:
> > for (1,("a","b","c"),3 { ... }
> >
> > and
> >
> > for 1,("a","b","c"),3 { ... }
> >
> > Now that I've ventured away from DWIMs and more into WIHDTEMs (What In
> > Hell Does This Expression Mean), is the above equivalent to
> >
> > for 1,qw(a b c), 3 { ... }
> >
> > as well?
>
> I'd expect all 3 to mean exactly the same thing.
>
> > A final unresolved question. I take it that the splat operator is a
> > deeply flattening operator. For instance,
> >
> > *[1,[2,[3,4,5]],6]
> >
> > will be converted into
> >
> > [1,2,3,4,5,6]
>
> What other operator acts recursively in this fashion? None that I know
> of. If someone wants the recursive behavior, they can redefine the
> operator appropriately.
>
> Besides, with the ^ operator, you can already express arbitrary
> levels:
>
> *[1,[2,[3,4,5]],6] # 1,[2,[3,4,5]],6
> ^*[1,[2,[3,4,5]],6] # 1,2,[3,4,5],6
> ^^*[1,[2,[3,4,5]],6] # 1,2,3,4,5,6
>
> et cetera. :-)
Y'all have it backwards.
[1,*[2,[3,4,5]],6] # [1,2,[3,4,5],6]
[1,*[2,*[3,4,5]],6] # [1,2,3,4,5,6]
Flat flattens outwards, not inwards.
Luke
Jonathan Scott Duff
>
> and
>
> for 1,("a","b","c"),3 { ... }
>
> Hell Does This Expression Mean), is the above equivalent to
>
> for 1,qw(a b c), 3 { ... }
>
> as well?
I'd expect all 3 to mean exactly the same thing.
> A final unresolved question. I take it that the splat operator is a
> deeply flattening operator. For instance,
>
> *[1,[2,[3,4,5]],6]
>
> will be converted into
>
> [1,2,3,4,5,6]
What other operator acts recursively in this fashion? None that I know
of. If someone wants the recursive behavior, they can redefine the
operator appropriately.
Besides, with the ^ operator, you can already express arbitrary
levels:
*[1,[2,[3,4,5]],6] # 1,[2,[3,4,5]],6
^*[1,[2,[3,4,5]],6] # 1,2,[3,4,5],6
^^*[1,[2,[3,4,5]],6] # 1,2,3,4,5,6
et cetera. :-)
-Scott
Luke Palmer
> fibo...@babylonia.flatirons.org (Luke Palmer) writes:
> > push @a: [1,2,3,4];
> >
> > pushes an array ref onto @a.
> >
> > push @a: *[1,2,3,4];
> >
> > pushes 1, 2, 3, and 4 onto @a (as it would without the * and []).
>
> Remind me which language this is supposed to be, again?
Heh, I see your point. Though the first of these two isn't so non-perly.
The second, people wouldn't do at all: they'd leave off the *[ ]
altogether.
BTW, the colon is indirect object, remember? The first is equivilent to:
@a.push [1,2,3,4];
Since I assume push is going to be a method now.
As far as the brackets-as-list thing, I think it has been discussed
ad nauseum, and I'll leave it to the heavyweights to sort it out.
Luke
Trey Harris
> Y'all have it backwards.
>
> [1,*[2,[3,4,5]],6] # [1,2,[3,4,5],6]
> [1,*[2,*[3,4,5]],6] # [1,2,3,4,5,6]
>
> Flat flattens outwards, not inwards.
Ah. *slaps head* of course. That makes much more sense. Thanks.
So then, I think if there's just some clarification about how one-tuples
are formed, I think everything I wrote in my earlier mail can DWIM
correctly. There seems to be no magic here, quotations from LoTR to the
contrary. :-)
Trey
Aaron Sherman
> 4. Numeric value.
>
> The progression spoken about at great length previously:
>
> +() # == 0
> +(0) # == WHAT? 0? 1?
> +(0,1) # == 2
> +(0,1,2) # == 3
> +(0,1,2,3) # == 4
> +(0,...,n) # == n + 1
>
> is largely irrelevant to the ways people use Perl.
Typing this in the car, so pardon only taking this section...
Here are some examples that I see a lot of, re-cast as Perl 6:
my int $a = (($x+(y())) * $z); # Parenoia, as I call it
if (-s $file) > 100000 { ... } # LOTS of code does this
So, in our ultimate solution, I suggest that both of the examples above
must apply the parentheses for precedence purposes only.
Now, the idea of using brackets for list construction was, I grant, a
bit scary at first, but I think it's the only thing that gets what Larry
was suggesting in terms of list construction *and* avoids these issues
cleanly. Let's not kill that conversation before it has a chance to
prove itself or not.
This is one of the things that I find frustrating about discussing
language details like this. We (all) often find it hard to maintain
context with real-world code, and get lost in over-simplified examples
like C<+(0)> which seem contrived and unimportant in a vacuum.
--
Aaron Sherman <a...@ajs.com>
Aaron Sherman
> On 23 Sep 2002, Simon Cozens wrote:
>
> > fibo...@babylonia.flatirons.org (Luke Palmer) writes:
> > > Since we now have an explicit flattening operator (unary *), there's no
> > > need to differentiate between a "real" list and a reference to one.
> >
> > What context does "push" impute on its operands?
> >
> > If
> > push @a, [1,2,3,4];
> > and
> > push @a, 1,2,3,4;
> > are going to be the same, you'll have real problems. I don't fancy doing
> > push @a, [[1,2,3,4]];
> >
> > And if you get around that by special-casing push to take an list of scalar
> > contexts, then, well, urgh.
>
>
> Aha! Kudos, Simon, this (alongside Aaron's message) was a stumper. But I
> think I've got it!
>
> push @a: [1,2,3,4];
>
> pushes an array ref onto @a.
>
> push @a: *[1,2,3,4];
>
> pushes 1, 2, 3, and 4 onto @a (as it would without the * and []).
Grrr... I want that to work, really I do, but since, as Larry has
pointed out, there's no functional difference between an array ref and
an array in Perl 6, they would be the same. This is because push is
almost certainly defined as:
sub push(@target, *@list) { ... }
Regardless of this entire conversation, that problem exists in Perl 6 as
described in the apocalypses, doesn't it? The way to avoid this is to
say that array refs behave the same as arrays in every way *except* as
pertains to list flattening, and in that case, explicit flattening is
required, otherwise the ref is kept in the flattened array.
Does this make sense?
--
Aaron Sherman <a...@ajs.com>
Trey Harris
In a message dated Mon, 23 Sep 2002, Trey Harris writes:
> 2. Scalar assignment.
>
> my $a; # 1.
> $a = X;
>
> my $a; # 2.
> $a = X;
>
> my $a; # 3.
> ($a) = X;
>
> my($a) = X; # 4.
>
> my($a) = (X); # 5.
>
> These should all do the same thing, regardless of X.
This is, I imagine, where Simon saw magic. I suspect that, for all X, it
would be magic if true (pretty neat magic, though!). I started with a
literal 7 instead of an abstract X, and then went back and changed it. I
shouldn't have done so.
> 5. Assignment to arrays and lists.
>
> The following should be vaild:
>
> ($a, $b) = ($b, $a); # swaps $a and $b
> ($a, $b) = (1, 2); # $a == 1, $b == 2
That last line should read
($a, $b) = (1, 2); # $a = 1, $b = 2
> 7. Miscellanea.
> What
>
> for (1,("a","b","c"),3 { ... }
There's a missing paren here. Should read
for (1,("a","b","c"),3) { ... }
> A final unresolved question. I take it that the splat operator is a
> deeply flattening operator. For instance,
>
> *[1,[2,[3,4,5]],6]
>
> will be converted into
>
> [1,2,3,4,5,6]
>
> It seems that, if the new order does allow the creation of
> multi-dimensional things using simply (), that we also need a "shallowly
> flattening operator". That is, it would convert the above list into
>
> [1,2,[3,4,5],6]
>
> Otherwise, the flattening required by the new syntax can go wild and cause
> unwanted flattening in data structures being passed around.
I take this back. Apparently splat was always "shallowly flattening".
Something bothers me about that, but it seems better than the alternative.
Can anyone think of a cause where you need a "deeply flattening" operator?
Seems to be that there's a common one that I can't quite put my finger
on...
> In conclusion, my reading of what Larry has said is compatible with the
> above--ASSUMING that
>
> $a = (7);
>
> causes $a to have the value 7, not the value [7]. If it has the value
> [7], as seems to be the result of the reduction that many here have been
> doing, then we have a very large problem with precedence, because as I
> said in item 3, we can't rely on people getting the paren count exactly
> right. Several other DWIMs above also fall apart.
>
> So, if you want to create a one-item list, you're left with
>
> $a = [7];
>
> or possibly
>
> $a = @(7);
I think this might be the answer. One-tuples can't be created with a
simple (N). If you want a one-tuple, you use [], and if you want to
coerce a list context onto something that might return a single element,
you use @(). That's analogous to how it works in Perl 5, and
list-vs.-array behavior is one thing that I'd argue is *not* broken in
Perl 5. Being able to use arbitrary lists as lvalues, being able to index
lists as if they were arrays, being able to construct lists easily out of
disparate scalar and list constituents, etc., are one of the major things
that make Perl a joy to use.
Trey
Trey Harris
> Grrr... I want that to work, really I do, but since, as Larry has
> pointed out, there's no functional difference between an array ref and
> an array in Perl 6, they would be the same. This is because push is
> almost certainly defined as:
>
> sub push(@target, *@list) { ... }
>
> Regardless of this entire conversation, that problem exists in Perl 6 as
> described in the apocalypses, doesn't it? The way to avoid this is to
> say that array refs behave the same as arrays in every way *except* as
> pertains to list flattening, and in that case, explicit flattening is
> required, otherwise the ref is kept in the flattened array.
>
> Does this make sense?
Yikes. You might be right. According to Larry,
$a = (1,2,3);
is equivalent to
$a = [1,2,3];
because they're both equivalent to
$a = scalar(1,2,3)
which converts the list to an arrayref. This only tells us about the
behavior of lists in scalar context, though--it says nothing about the
behavior of parens in a list or list-flattening context. Is this key to
push's behavior? Perhaps parens do not construct a list in list context,
but leave whatever is receiving the list and caused the list context to
deal with the elements, i.e., it auto-flattens a paren'ed list if one is
present but not a square-bracketed one?
In that case, we could once again DWIM so that
push @a, 1, 2, 3;
is equivalent to
push @a, (1,2,3);
but not to
push @a, [1,2,3];
I agree, though, that this is getting highly magical. Perhaps
parens-creating-arrayrefs is something that be considered specialized and
arcane and not something that programmers should do, because square
brackets are much more consistent. I know that's a dodge, but maybe
it's the right dodge. :-)
Trey
Aaron Sherman
> $num = @massive;
>
> C<$num> becomes a reference to C<@massive>, but in a numeric context it
> will evaluate to the number of elements in that array.
>
But in most cases, you would never do this. You would do something like
my int $num = @massive;
or
if @massive {...}
or the like. In both cases, your later concerns about long-lived
references go away.
--
Aaron Sherman <a...@ajs.com>
Trey Harris
> almost certainly defined as:
>
> sub push(@target, *@list) { ... }
That should be
sub push(@target is rw, *@list);
but otherwise I think that's right.
Now, implementation in Perl 6 (though I assume it's actually written in
Parrot). This would obviously work:
sub push(@target is rw, *@list) {
@target[@target.length ..
@target.length + @list.length - 1] = @list;
}
Now, how to do it more Perlishly?
@target = *(@target, @list);
? Or would that have to be
@target = (*@target, *@list);
? Surely
@target = (@target, @list);
or
@target = (*@target, @list);
would not work. Or would it?
Trey
John Williams
>
> So then, I think if there's just some clarification about how one-tuples
> are formed, I think everything I wrote in my earlier mail can DWIM
> correctly. There seems to be no magic here, quotations from LoTR to the
> contrary. :-)
Your post was very helpful to pull us back to sanity.
Allowing list context to create a 1-item list out of a scalar makes sense
in my mind. (ie @a = 7 sets @a[0] to 7).
~ John Williams
P.S. Caution: this way lies madness...
In perl5, to get the 'x' repetition operator to do a list repeat, it
must be in list context _and_ the left side must be in parenthesis. Will
this strange combination of syntactic context and semantic context still
apply in perl6? Would it be simpler if it only relied on the scalar/list
context?
After testing various cases of x, I came up with one that I cannot
explain. Can someone tell me what is happening here (in perl5)?
$ perl -le 'print "@{[ $a = ('a','b') x 3 ]}"; print $a'
a bbb
bbb
or in other words, after evaluating "@a = $a = ('a','b') x 3",
$a is 'bbb' and @a is ('a','bbb') !
Aaron Sherman
> du...@cbi.tamucc.edu (Jonathan Scott Duff) writes:
> > Why can't perl be smart enough to figure out what we mean?
>
> in the language.
>
> If we have to resort to much magic to get these right, we're pretty much
> doomed from the outset.
You have that upside-down. Because this is so fundamental, it's worth a
great deal of magic to make it "seem right" in as many contexts as
possible. This is what Perl has always done, no?
--
Aaron Sherman <a...@ajs.com>
Aaron Sherman
> In a message dated 24 Sep 2002, Aaron Sherman writes:
> > This is because push is
> > almost certainly defined as:
> >
> > sub push(@target, *@list) { ... }
>
> That should be
>
> sub push(@target is rw, *@list);
Well, yes, but that wasn't the point. The C<*@list> will force array
flattening, thus
push @a, [1,2,3], 4;
will (according to Larry's stated desire to unify arrays and references
to arrays in terms of behavior) result in four elements getting pushed
onto C<@a>, not two.
Therein lies the rub.
--
Aaron Sherman <a...@ajs.com>
Simon Cozens
> > If we have to resort to much magic to get these right, we're pretty much
> > doomed from the outset.
>
> You have that upside-down. Because this is so fundamental, it's worth a
> great deal of magic to make it "seem right" in as many contexts as
> possible. This is what Perl has always done, no?
Maybe you're right; maybe what I want isn't Perlish, as I've said before.
I just worry about having to teach all this.
At any rate, I do wish we'd stop kidding ourselves that Perl 6 is at all
going to be "cleaned up" or "regular"; I bet it'll end up with more edge
cases and special exceptions than Perl 5.
--
* Progress (n.): The process through which Usenet has evolved from
smart people in front of dumb terminals to dumb people in front of
smart terminals. -- o...@burnout.demon.co.uk (obscurity)
Simon Cozens
> say that array refs behave the same as arrays in every way *except* as
> pertains to list flattening, and in that case, explicit flattening is
> required, otherwise the ref is kept in the flattened array.
Another blow to regularity. :(
--
buf[hdr[0]] = 0; /* unbelievably lazy ken (twit) */ - Andrew Hume
Jonathan Scott Duff
> At any rate, I do wish we'd stop kidding ourselves that Perl 6 is at all
> going to be "cleaned up" or "regular"; I bet it'll end up with more edge
> cases and special exceptions than Perl 5.
Simon, Perl 6 *will* be more "regular" as long as we have people like
you pointing out when something isn't right.
When reading through the Apocalypses and subsequent discussion on
perl6-language, I too get the feeling that we're trading one set of
special cases for another. But keep in mind, these are draft documents
on how things should work. We have the opportunity to fix our mistakes
before we cast them in stone and I fully believe that we will.
This message of optimism brought to you by the
future-perl-6-users-society. :-)
Peter Haworth
But the decision on how arguments get passed happens at compile time, not run
time. At that point we can tell the difference between an explicit arrayref
and a flattened array:
push @a,1,2,3; # 1 - list
push @a,(1,2,3); # 2 - list
push @a,[1,2,3]; # 3 - scalar
push @a,@b; # 4 - list
push @a,*@b; # 5 - list
push @a,\@b; # 6 - scalar
push @a,[@b]; # 7 - scalar
1 and 2 are the same; parens in a list don't have any effect, and push
receives three elements in its @list parameter. 3 is an explicit arrayref so
gets passed as a single scalar. This is a simple and obvious distinction for
the programmer to make.
4 and 5 are the same due to the *@ prototype; push receives the contents of
@b in its @list parameter. 6 is an explicit arrayref, so that's what push gets
given. I would argue that 7 is like 6, except that it copies @b's elements.
--
Peter Haworth p...@edison.ioppublishing.com
Reporter: Mr Gandhi, what do you think of Western Civilization?
Gandhi: I think it would be a good idea.
Chip Salzenberg
> According to Larry,
> $a = (1,2,3);
> is equivalent to
> $a = [1,2,3];
> because they're both equivalent to
> $a = scalar(1,2,3)
But that's the bit we're arguing about. If you allow
$a = (1,2)
then what about
$a = (1)
? And if someone says that I have to write:
$a = (1,)
then I am going on the warpath. That Way Lay Python.
Trey Harris
> According to Trey Harris:
> > According to Larry,
> > $a = (1,2,3);
> > is equivalent to
> > $a = [1,2,3];
> > because they're both equivalent to
> > $a = scalar(1,2,3)
>
> But that's the bit we're arguing about. If you allow
>
> $a = (1,2)
>
> then what about
>
> $a = (1)
>
> ? And if someone says that I have to write:
>
> $a = (1,)
>
> then I am going on the warpath. That Way Lay Python.
*shrug* Regardless of whether we like it, what Larry said is true unless
and until he invokes Rule 2. And unless he invokes Rule 2,
C<scalar(1,2,3)> is equivalent to C<[1,2,3]>.
My suggestion is merely that one-tuples lacking the comma cannot be
constructed with parens (round brackets) and that list-flattening context
has the effect of voiding top-level round parens (but not square
brackets).
So
$a = (7);
would assign 7 to $a, and
push @a, (7,3,2);
would push the elements 7, 3 and 2 to the end of @a, but
push @a, [7,3,2];
would push a single element containing the arrayref [7,3,2] onto the end
of @a.
I agree it's weird, but it seems to DWIM, doesn't it? I just don't think
a reduction that C<()> is equivalent to C<[]> is workable.
If you want to assign $a the value [1], then you write
$a = [7];
I would think that
$a = (7,);
would be legal as well, but only in order to handle the DWIM of
$a = (1,
2,
3,
);
where you kill the middle two lines--not as the preferred (and certainly
not as the only) way to create a one-tuple. Making
$a = (7);
create a single-element list is just unworkable. It requires that
programmers get precedence exactly right, and it badly violates the
principle of least surprise.
Trey
Aaron Sherman
> On 24 Sep 2002 05:21:37 -0400, Aaron Sherman wrote:
> > On Tue, 2002-09-24 at 01:46, Trey Harris wrote:
> > > sub push(@target is rw, *@list);
> >
> > Well, yes, but that wasn't the point. The C<*@list> will force array
> > flattening, thus
> >
> > push @a, [1,2,3], 4;
> >
> > will (according to Larry's stated desire to unify arrays and references
> > to arrays in terms of behavior) result in four elements getting pushed
> > onto C<@a>, not two.
>
> But the decision on how arguments get passed happens at compile time, not run
> time. At that point we can tell the difference between an explicit arrayref
> and a flattened array:
Again, we're wading into the waters of over-simplification. Let's try:
sub foo1(){ my @foo=(1,2,3); return @foo; }
sub foo2(){ my $foo = [1,2,3]; return $foo; }
sub foo3(*@list) { print @list.length, "\n"; }
@foo = (1,2,3);
foo3(@foo, [1,2,3], foo2(), foo1());
Ok, so what is the output? 12? 10? 8?
More importantly, why? I could argue the case for each of the above
numbers, but I think 12 is the way it would be right now.
--
Aaron Sherman <a...@ajs.com>
Dan Sugalski
>
>*shrug* Regardless of whether we like it, what Larry said is true unless
>and until he invokes Rule 2. And unless he invokes Rule 2,
>C<scalar(1,2,3)> is equivalent to C<[1,2,3]>.
Then perhaps, rather than fretting over the unpleasant consequences
of the current decision, effort would be better placed in getting
that decision changed?
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Aaron Sherman
> In a message dated Tue, 24 Sep 2002, Chip Salzenberg writes:
> > then what about
> >
> > $a = (1)
> >
> > ? And if someone says that I have to write:
> >
> > $a = (1,)
> >
> > then I am going on the warpath. That Way Lay Python.
I would *never* suggest such a thing :)
Seriously, it's not that it's Python-like, but that it's not intuitive
to Perl programmers at all. There's no way to map your brain into that
grammar without re-learning what a list is, and I don't see the reward
being worth that kind of mind-bending.
> *shrug* Regardless of whether we like it, what Larry said is true unless
> and until he invokes Rule 2. And unless he invokes Rule 2,
> C<scalar(1,2,3)> is equivalent to C<[1,2,3]>.
>
> My suggestion is merely that one-tuples lacking the comma cannot be
> constructed with parens (round brackets) and that list-flattening context
> has the effect of voiding top-level round parens (but not square
> brackets).
The crux of the no-parens for lists discussion has been the idea that in
the current state of affairs, square brackets are a pointless tumor on
the syntax of Perl 6. You don't need them, not ever... almost. You can
do:
$x = (1,2,(3,4),(5,(6)))
And everything except for that last C<(6)> will be an anonymous array,
constructed for your viewing pleasure. Of course (again, NOT PROPOSING
ANYTHING, just citing how it is supposed to be now):
$x = [1,2,[3,4],[5,[6]]]
Will do what you intended, but now we're keeping brackets on just for
the single-element anonymous array feature, which is one hell of an
impact on the syntax for such a small feature. Larry's work on Patterns
would seem to indicate a deep disdain for this sort of slop, so I
imagine a future apoc. will address the waste of operators here. I await
it with much faith in the power of authoritarian rules :-)
> push @a, (7,3,2);
>
> would push the elements 7, 3 and 2 to the end of @a, but
>
> push @a, [7,3,2];
>
> would push a single element containing the arrayref [7,3,2] onto the end
> of @a.
>
That doesn't really work. Because now you introduce the case where:
$x = (1,2,3);
@y = (1,2,3);
$z = [1,2,3];
push @a, $x, @y, $z, (1,2,3), [1,2,3];
Behaves in ways that will take hours to explain to newbies, and I assure
you it ain't WIM. Not even a little bit.
--
Aaron Sherman <a...@ajs.com>
Trey Harris
>
> $x = (1,2,3);
> @y = (1,2,3);
> $z = [1,2,3];
> push @a, $x, @y, $z, (1,2,3), [1,2,3];
>
> Behaves in ways that will take hours to explain to newbies, and I assure
> you it ain't WIM. Not even a little bit.
Hmm. What *I* would mean, anyway, would be that @a gets pushed nine
elements: ([1,2,3], 1, 2, 3, [1,2,3], 1, 2, 3, [1,2,3]). And that works
under my proposal. But I may have an idiosyncratic idea of WIM. :-)
But I think Dan's right. I think we should just let this drop for now,
let Larry take a look at the mess we've gotten ourselves into, and let him
decide whether he needs to Rule-2 something or not.
Trey
Jonathan Scott Duff
> Again, we're wading into the waters of over-simplification. Let's try:
>
> sub foo1(){ my @foo=(1,2,3); return @foo; }
> sub foo2(){ my $foo = [1,2,3]; return $foo; }
> sub foo3(*@list) { print @list.length, "\n"; }
> @foo = (1,2,3);
> foo3(@foo, [1,2,3], foo2(), foo1());
>
> Ok, so what is the output? 12? 10? 8?
>
> More importantly, why? I could argue the case for each of the above
> numbers, but I think 12 is the way it would be right now.
Hrm. I think it must be 8. Since foo3() flattens it's parameters, we
get this:
foo3(1, 2, 3, [1,2,3], [1,2,3], 1, 2, 3);
and since the two [1,2,3] are scalar things, we have 8 scalar things
in our list. Splat doesn't "look inside" the thing it flattens AFAIK,
so it doesn't flatten the two [1,2,3].
Trey Harris
Yes, but would the lack of parens in
foo3 @foo, [1,2,3], foo2, foo1;
change anything? (I think and hope not.)
Trey
Jonathan Scott Duff
Not from where I sit.
John Williams
>
> > > then what about
> > >
> > > $a = (1)
> > >
> > > ? And if someone says that I have to write:
> > >
> > > $a = (1,)
> > >
> > > then I am going on the warpath. That Way Lay Python.
You _can_ write that, but you don't _have_ to. [1], @(1), list(1), or
maybe other things will work too. But (1) is not enough in scalar
context.
On 24 Sep 2002, Aaron Sherman wrote:
> The crux of the no-parens for lists discussion has been the idea that in
> the current state of affairs, square brackets are a pointless tumor on
> the syntax of Perl 6. You don't need them, not ever... almost. You can
> do:
>
> $x = (1,2,(3,4),(5,(6)))
>
> And everything except for that last C<(6)> will be an anonymous array,
> constructed for your viewing pleasure. Of course (again, NOT PROPOSING
> ANYTHING, just citing how it is supposed to be now):
>
> $x = [1,2,[3,4],[5,[6]]]
>
> Will do what you intended, but now we're keeping brackets on just for
> the single-element anonymous array feature, which is one hell of an
> impact on the syntax for such a small feature.
Larry's comment about [1,2,3] being mnemonic because we use @a[1] to index
arrays was an excellent point. Since [1,2,3] works for both $a = [] and
@a = [], maybe we should consider dropping the parenthesis instead of the
brackets. (And I was the putz that first suggested that brackets might be
superfluous.) Of course, that won't stop commas from creating lists.
> On Tue, 2002-09-24 at 11:07, Trey Harris wrote:
> > push @a, (7,3,2);
> >
> > would push the elements 7, 3 and 2 to the end of @a, but
> >
> > push @a, [7,3,2];
> >
> > would push a single element containing the arrayref [7,3,2] onto the end
> > of @a.
From reading the apocalypses, I think Larry, et al, are aware of this, and
I fully expect the situation to be clarified when the next apocalypse
comes out. Maybe we should have a pool for the release date? :)
> That doesn't really work. Because now you introduce the case where:
>
> $x = (1,2,3);
> @y = (1,2,3);
> $z = [1,2,3];
> push @a, $x, @y, $z, (1,2,3), [1,2,3];
>
> Behaves in ways that will take hours to explain to newbies, and I assure
> you it ain't WIM. Not even a little bit.
The parenthesis have no effect because they are only grouping. So the
only question in my mind is whether @y gets flattened or is treated as a
single object. In either case, we can clarify our meaning by writing *@y
to force flattening or \@y to prevent flattening.
~ John Williams
David Whipp
a scalar, and a list of 1 elem. Thus, we want
$a = 7
to DWIM, whether I mean a list, or a scalar. Seems to me that
the best way to solve a dichotomy is to declare it to not to
be one: a scalar *IS* a list of one element. The only thing
that needs to go is the inappropriate casting in numeric
context.
This leads to a second clarification, which has bothered me
wrt perl6: the purpose of sigils. If everything is an object,
and objects are $ things, then why have sigils? I think the
answer is that the sigil defines the default interface
("skin"?) on an object. So,
$a = 7;
@a = 7;
both create identical objects; but the interface to these
objects is different. so +$a == 7, while +@a is 1.
Next:
$b = 7, 6, 5
@b = 7, 6, 5
Again, both create identical objects, under different
interfaces. But now we have a problem with +$b: what should
this mean? To be consistant with +$a (above), I would
suggest that it simply returns the sum of its elements
(i.e. +(1,2,3) == 6).
Dave.
Jonathan Scott Duff
> It seems that the fundamental problem is the dichotomy between
> a scalar, and a list of 1 elem. Thus, we want
>
> $a = 7
>
> to DWIM, whether I mean a list, or a scalar. Seems to me that
> the best way to solve a dichotomy is to declare it to not to
> be one: a scalar *IS* a list of one element. The only thing
> that needs to go is the inappropriate casting in numeric
> context.
So you're saying that +$a == 7 is inappropriate and it should be
+$a == 1? (since lists in numeric context yield their length)
Or are you saying that lists in numeric context should NOT yield their
length but rather the programmer must type @a.length to get that?
> I think the
> answer is that the sigil defines the default interface
> ("skin"?) on an object. So,
>
> $a = 7;
> @a = 7;
>
> both create identical objects; but the interface to these
> objects is different. so +$a == 7, while +@a is 1.
Okay ...
> Next:
>
> $b = 7, 6, 5
> @b = 7, 6, 5
>
> Again, both create identical objects, under different
> interfaces. But now we have a problem with +$b: what should
> this mean? To be consistant with +$a (above), I would
> suggest that it simply returns the sum of its elements
> (i.e. +(1,2,3) == 6).
Makes no sense to me.
if $b and @b are identical objects then what kind of objects are they?
Are the commas list constructors? If so, then why wouldn't +$b == 3?
$a = 10; $b = 7,6,5;
$c = $a + $b; # what happens here? Is $c == 28?
Anyway, this is most bizarre. My little perl 5 brain can't intuit.
Aaron Sherman
> It seems that the fundamental problem is the dichotomy between
> a scalar, and a list of 1 elem. Thus, we want
After the first couple of messages, that was really no longer *my*
concern, but I can't speak for others. My concern was mostly that
parentheses and brackets are now doing exactly the same thing with some
very limited non-intersection around single-element lists. So my
question was: why would we want that? Why would anyone ever need to have
this in their code: C<(1,[2,(3,[4,(5,6),7],8),9],0xa)>.
But, I'm quite content to wait for Larry to get back and have a chance
to mull all of this over. He tends to have a very level head about these
things, and I imagine he'll have a point of view colored by some
concerns he has not yet put into writing.
For what it's worth, I once started working on a cut-down,
general-purpose-only version of Perl that I was calling Sand. The
interesting thing was that I made a lot of these same decisions, but I
went even further. There was no array or hash type at all. They could
only be manipulated by reference through anonymous structures or scalar
variables. I rat-holed on the topic of how to pass parameters without
throwing away the benefit of Perl's sloppy-list-based stack that was
always so useful. A lot of these "why do I need parens" and "how do you
explode a list when you want, but not when you don't" sorts of issues
kept coming up, and I just didn't have time to explore them.
Now that Perl 6 is starting to take shape, I may go back and finish Sand
as a Parrot front-end (though it was ultimately aimed at being purely
compiled like C).
--
Aaron Sherman <a...@ajs.com>
Mike Lambert
>
> my $a; # 1.
> $a = X;
>
> ($a) = X;
>
> These should all do the same thing, regardless of X.
Consider:
$a = (1);
and
($a) = (1);
> 5. Assignment to arrays and lists.
>
> $a = (1, 2, 3); # Same as Perl 5's $a = [1,2,3];
$a = (1) should then do $a = [1], according to the above.
This implies that:
($a) = (1) implies that $a is [1], something I don't particularly agree
with.
How would you resolve this contradiction you've created? (Or do you think
the last example is perfectly fine?)
What about:
$a = 1,2,3
($a) = (1,2,3)
$a = (1,2,3)
($a) = 1,2,3
Do you still believe those should be identical? They have the same
problems mentioned above, and likely other issues as well.
Mike Lambert
Trey Harris
> Consider:
> $a = (1);
> and
> ($a) = (1);
Yes? They both do the same thing--set $a to 1. It looks like the bottom
one is a list assigned to a list, but that might be optimized out, as it
doesn't matter.
> > 5. Assignment to arrays and lists.
> >
> > $a = (1, 2, 3); # Same as Perl 5's $a = [1,2,3];
>
> $a = (1) should then do $a = [1], according to the above.
I most definitely did not write that. Did you read my conclusion?
One-tuples are special and can't be created simply with round parens.
> This implies that:
>
> ($a) = (1) implies that $a is [1], something I don't particularly agree
> with.
Once again, did you read my conclusion? One-tuples are special.
>
> How would you resolve this contradiction you've created? (Or do you think
> the last example is perfectly fine?)
No contradiction. One-tuples are special.
> What about:
> $a = 1,2,3
I don't know. I think Larry must adjudicate.
> ($a) = (1,2,3)
$a gets 1, I think. Otherwise you can't do list assignment where you
throw away the trailing elements, which is a very common and useful thing
to do in Perl 5. Losing that ability in Perl 6 would be a great loss.
> $a = (1,2,3)
By definition, according to Larry, $a is [1,2,3].
> ($a) = 1,2,3
Same as without the parens. Larry must decide.
> Do you still believe those should be identical? They have the same
> problems mentioned above, and likely other issues as well.
Oh, wait, I think I see where you're going. You didn't read the whole
thread to date before responding. I later quoted my own text there and
said that arbitrary X was not what I meant. I meant a single scalar item,
such as 7, but I changed it to X in an effort to be general without
considering what that meant. My mistake.
Trey
David Whipp
> From: Jonathan Scott Duff
> > $b = 7, 6, 5
> > @b = 7, 6, 5
> >
> > Again, both create identical objects, under different
> > interfaces. But now we have a problem with +$b: what should
> > this mean? To be consistant with +$a (above), I would
> > suggest that it simply returns the sum of its elements
> > (i.e. +(1,2,3) == 6).
>
> Makes no sense to me.
>
> if $b and @b are identical objects then what kind of objects are they?
> Are the commas list constructors? If so, then why wouldn't +$b == 3?
>
> $a = 10; $b = 7,6,5;
> $c = $a + $b; # what happens here? Is $c == 28?
>
> Anyway, this is most bizarre. My little perl 5 brain can't intuit.
$a and @a are not objects, they are variables. Variables provide
access to objects. $a and @a are different kinds of variables:
when you view an object though a $ variable, it DWIMs like a
scalar; when you view it through an @ variable, it DWIMs like
a list. In numeric context, a $ variable obtains its value via
a .NUMBER method. In the same context, an @ variable uses
the .LENGTH method
In both caes, the underlying object would have both .NUMBER and
..LENGTH methods. The only difference would be that the sigil
defines different mappings between the calling context, and the
method that returns the value.
And thinking about your example, above, the value of $a + $b
is probably 10; for the same reason as 3+"foo" is 3. If you're
using -w then, of course, you also get the warning that
"argument [7,6,5] is not numeric in add at ...".
As others have said, we need Larry to look at all the various
issues and proposals ... and then to chop the baby in half.
Dave.
John Williams
> >
> > $a = (1, 2, 3); # Same as Perl 5's $a = [1,2,3];
>
> $a = (1) should then do $a = [1], according to the above.
>
> This implies that:
>
> ($a) = (1) implies that $a is [1], something I don't particularly agree
> with.
You may be missing the change in the comma operator. Perl5 uses the
"return the rightmost value" comma from C. Perl6 is changing the comma to
a "list constructor". So (1,2,3) is definitely a list, but (4) probably
isn't.
If I understand our non-conclusions so far, we're waiting for Larry to
clarify:
1) how to create a 1-tuple/1-item list?
2) how to interpret the flattened list context? e.g. given this:
> $x = (1,2,3);
> @y = (1,2,3);
> $z = [1,2,3];
> push @a, $x, @y, $z, (1,2,3), [1,2,3];
What flattens, what doesn't, and how do you override the behavior?
Is there anything I missed?
~ John Williams
Aaron Sherman
> If I understand our non-conclusions so far, we're waiting for Larry to
> clarify:
>
> 1) how to create a 1-tuple/1-item list?
>
> 2) how to interpret the flattened list context? e.g. given this:
>
> > $x = (1,2,3);
> > @y = (1,2,3);
> > $z = [1,2,3];
> > push @a, $x, @y, $z, (1,2,3), [1,2,3];
>
> What flattens, what doesn't, and how do you override the behavior?
Mostly I'm interested in the fact that () and [] now do exactly the same
thing, except that Perl 6 ()s can't create one-element lists. Given
that, ()s are just being wasted, syntacticly speaking, on backward
compatibility with Perl 5. I'd like to know if there's any chance of our
breaking with that backward compatibility.
Once again, just waiting for Larry to come back. I'm not really very
interested in pursuing this debate further until I find out what caveats
he may already be planning on introducing.
Once that's in place, I have a whole slew of questions regarding []s
that I think people will find interesting.
--
Aaron Sherman <a...@ajs.com>
Nicholas Clark
> After testing various cases of x, I came up with one that I cannot
> explain. Can someone tell me what is happening here (in perl5)?
>
> $ perl -le 'print "@{[ $a = ('a','b') x 3 ]}"; print $a'
> a bbb
> bbb
>
> or in other words, after evaluating "@a = $a = ('a','b') x 3",
> $a is 'bbb' and @a is ('a','bbb') !
Well, Deparse says:
$ perl5.6.1 -MO=Deparse -le 'print "@{[ $a = ('a','b') x 3 ]}"; print $a'
print "@{[$a = x 3];}";
print $a;
-e syntax OK
but if I use a nice new perl (where someone, IIRC Rafael Garcia-Suarez, has
fixed many many bugs):
$ perl5.8.0 -MO=Deparse -le 'print "@{[ $a = ('a','b') x 3 ]}"; print $a'
BEGIN { $/ = "\n"; $\ = "\n"; }
print "@{[$a = ('a', 'b') x 3];}";
print $a;
-e syntax OK
and interestingly, perl 5.8.0 gives a different answer from the perl you ran:
$ perl5.8.0 -le 'print "@{[ $a = ('a','b') x 3 ]}"; print $a'
bbb
bbb
so I'd say that what you see is a bug, and it's already fixed in 5.8
Nicholas Clark
--
Even better than the real thing: http://nms-cgi.sourceforge.net/
Smylers
> On Sat, 2002-09-21 at 06:38, Smylers wrote:
>
> > ... lists now use square brackets.
>
> I don't disagree that this is a good thing, but let's look at some
> cases that might not look the way you had intended: <Snip>
Oh, I hadn't really intending anything. Starting from what Larry said
about parens creating array refs, I ended up with the evil thought about
square brackets just being for precedence.
Realizing that doing this t'other way round might actually be sensible
was very much an afterthought. I posted it knowing that I'd be away for
a week, and without even attempting to think through all the
consequences.
> Thoughts?
Fortunately by the time I got back online I find that Luke Palmer has
created a very sensible RFC based on my suggestion. He's obviously done
more thinking about this than I had, so I don't think there's any point
in me adding anything.
(Thanks Luke, by the way.)
Smylers
Smylers
> On 21 Sep 2002, Smylers wrote:
>
> > But because C<$num> _might_ be used as an array ref, the data has to
> > be kept around, which is wasteful.
>
> The programmer should know whether it would or wouldn't,
Oh, I wasn't doubting that. I was just concerned that if the 'typical'
way of determining the size of an array remains as it is in Perl 5 then
a programmer could unwittingly be keeping superfluous data around.
> so he could put + or not.
Fair enough. It would probably be good style always to include the C<+>
when only the size is required; just doing this when otherwise would
leave an array in memory would be too subtle.
Smylers