Re: regex and
On Tue, Aug 10, 2010 at 9:00 PM, wrote: > Once the & operator is in rakudo, though... I gather I /could/ do something > like the following > > ^ [ * & ] $ > > And this would in effect ensued that the sequence "abc" doesn't exist > anywhere across the match for > > > Is this correct? > Not quite, I suspect – the is still zero-width, so unless quantified zero-width assertions are DWIMmier than what's healthy, this is likely still equivalent to ^$. I think the following should DWYW, though: ^ [ [ . ] * & ] $ ... though perhaps there is a shorter way to write [ . ]? Feels like there should be one ... Eirik
RE: regex and
Back to your original advice... > If you want to match an alphabetic string which does not include 'abc' > anywhere, you can write this as > > ^ [ ]* $ I presume this only works here because is one character... if instead of I used anything more complicated (for example) token name { <[A..Z]>* } And then tried to do ^ [ ]* $ This wouldn't work since there's a wildcard within name. Once the & operator is in rakudo, though... I gather I /could/ do something like the following ^ [ * & ] $ And this would in effect ensued that the sequence "abc" doesn't exist anywhere across the match for Is this correct?
Re: regex and
philippe.beauch...@bell.ca wrote: > On the & operator... are you saying that it would operate basically as > expected... > allowing sets of rules and'ed rather than or's with the | ? Yes, with the limitation that both parts separated by & have to match the same length of string, so that for example ^ [ a+ & . ** 3 ] could only match exactly 3 a's. If you don't want to them tied to the same length, you look-ahead assertions instead. Cheers, Moritz
RE: regex and
Great! That does it. Thanks. :) I realized my error on the anchors after sending... but didn't think of the * on the grouping. On the & operator... are you saying that it would operate basically as expected... allowing sets of rules and'ed rather than or's with the | ? --- Phil -Original Message- From: Moritz Lenz [mailto:mor...@faui2k3.org] Sent: August 10, 2010 2:09 PM To: Beauchamp, Philippe (6009210) Cc: perl6-language@perl.org Subject: Re: regex and Hi, philippe.beauch...@bell.ca wrote: > rule TOP > { > ^ > [ > & * > & > ] > $ > } The & syntax is specced, but it's not yet implemented in Rakudo. But note that is a zero-width assertion, so your example regex matches at the start of a string, if it does not begin with 'abc'. Since you anchor it to the end of string too, it can only ever match the empty string. You can achieve the same with just ^$. If you want to match an alphabetic string which does not include 'abc' anywhere, you can write this as ^ [ ]* $ Cheers, Moritz
Re: regex and
Hi, philippe.beauch...@bell.ca wrote: > rule TOP > { > ^ > [ > & * > & > ] > $ > } The & syntax is specced, but it's not yet implemented in Rakudo. But note that is a zero-width assertion, so your example regex matches at the start of a string, if it does not begin with 'abc'. Since you anchor it to the end of string too, it can only ever match the empty string. You can achieve the same with just ^$. If you want to match an alphabetic string which does not include 'abc' anywhere, you can write this as ^ [ ]* $ Cheers, Moritz
Re: Regex interpolation
Use <{...}>. as the string returned is reinterpreted as a regex, if it consists of the single quoted string then it's a literal, but you must include the single quotes in the result returned. E.g., <{ my $x = funct($a, $b, $c); "'$x'";}> Mark Biggar -- m...@biggar.org mark.a.big...@comcast.net mbig...@paypal.com - Original Message - From: Mark J. Reed To: perl6-language@perl.org Sent: Mon, 29 Mar 2010 14:27:00 + (UTC) Subject: Regex interpolation Is there not a way to run arbitrary code and interpolate the result as a literal string (instead of a Regex)? I assume that {...} is intended to be where you hook in semantics/actions mid-parse, but it seems a bit counter-intuitive that the same syntax interpolates in double-quote context but not regexes. Question Inspired by this Rakudo patch: On Monday, March 29, 2010, Bruce Keeler wrote: > # New Ticket Created by Bruce Keeler > # Please include the string: [perl #73862] > # in the subject line of all future correspondence about this issue. > # > > > The attached patch adds support for variable and block-result > interpolation into regexes. > > It does so by means of a new PAST::Regex node pasttype 'interpolator'. > The following syntaxes are supported by this patch: > > / $var / -- Interpolates as literal string, unless it's a Regex object > / @foo / -- Interpolated as ||-style alternations of literal strings > or Regex objects > / <$var> / -- compiled into a Regex (unless it's already one), then > interpolated > / <@foo> / -- A list of ||-style alternations of things to be > compiled into Regexes (unless they already are) > / <{ ... }> / -- Result of capture is interpolated as a Regex, > compiling if necessary > / / -- Unchanged > / { ... } / -- Capture is merely executed, but not interpolated. > (Unchanged) > -- Mark J. Reed
Re: Regex - Accessing captured subrules could be problematic
On Thu, Dec 04, 2008 at 07:00:55PM +0100, Moritz Lenz wrote: > GW wrote: > > I found something that could be problematic (haven't yet found out if it > > should be a special case) in Synopsis 5. More precisely it is under the > > chapter "Accessing captured subrules" in the test case > > t/regex/from_perl6_rules/capture.t lines 67–71: > > > > ok(eval(' "bookkeeper" ~~ m/ ($/)/ '), 'Named backref', > > :todo); > > > > How can the parser know what you mean by $/? Maybe you want $/ > > followed by or maybe $/? I suspect $/ would parse as a single variable. If you want the separate subrule one can use whitespace (as noted in other posts) or brackets (if whitespace is an issue): [$/] > The same rule applies for interpolation in strings: > > "my big $house.uc" is parsed as "my big { $house.uc }", ie $house.uc is > taken as one token, even though a valid interpretation would be to > interpolate $house first and then append .uc to that string. Alas, this is not exactly the case here. Interpolation in strings only occurs for things that end with a postcircumfix (parens, braces, brackets), thus my $house = 'building'; say "a big $house.uc";# "a big building.uc" say "a big { $house.uc }";# "a big BUILDING" say "a big $house.uc()"; # "a big BUILDING" say "a big { $house }.uc";# "a big building.uc" > The Perl 6 solution is that you disambiguate with whitespace if you > don't want to follow the LTM-rule (ie you'd say '$/ ' in the regex). I think I would tend to recommend disambiguating with brackets instead of whitespace -- it's slightly more explicit (similar to how we recommend disambiguating with parens in other types of expressions). Pm
Re: Regex - Accessing captured subrules could be problematic
On Wed, Dec 3, 2008 at 6:19 PM, GW <[EMAIL PROTECTED]> wrote: > Hi, > > I found something that could be problematic (haven't yet found out if it > should be a special case) in Synopsis 5. More precisely it is under the > chapter "Accessing captured subrules" in the test case > t/regex/from_perl6_rules/capture.t lines 67–71: > > ok(eval(' "bookkeeper" ~~ m/ ($/)/ '), 'Named backref', > :todo); > > How can the parser know what you mean by $/? Maybe you want $/ > followed by or maybe $/? If you wanted $/ followed by then you would introduce some intervening whitespace. This is just like interpolation into double quoted strings. When you say my @what = ; my $str = "This is a @what[2]"; you always get the 3rd item from the @what array interpolated, not the string '@what[2]'. If you want the latter, you have to use some other technique (concatenation, single quotes, etc.) > A rewrite of this to $ would solve this specific problem, but > not situations like: $/. Variants like $/. are also > ambiguous. Same for these. And if you're doing this in a context where whitespace has meaning (e.g. :sigspace is in effect), but you don't want the significant whitespace, you can turn that off temporarily (or again, use some other technique). HTH, -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Regex - Accessing captured subrules could be problematic
Hello, GW wrote: > I found something that could be problematic (haven't yet found out if it > should be a special case) in Synopsis 5. More precisely it is under the > chapter "Accessing captured subrules" in the test case > t/regex/from_perl6_rules/capture.t lines 67–71: > > ok(eval(' "bookkeeper" ~~ m/ ($/)/ '), 'Named backref', > :todo); > > How can the parser know what you mean by $/? Maybe you want $/ > followed by or maybe $/? I don't know if this is the answer to your particular question, but these questions are usually answered by "Longest Token Matching" (LTM). This principle says that every grammar rule that parses the source code eats up as many characters as possible. So I think this means here that $/ will be parsed as one long token instead of two separate tokens. The same rule applies for interpolation in strings: "my big $house.uc" is parsed as "my big { $house.uc }", ie $house.uc is taken as one token, even though a valid interpretation would be to interpolate $house first and then append .uc to that string. > A rewrite of this to $ would solve this specific problem, but > not situations like: $/. Variants like $/. are also > ambiguous. > > A solution could be something like like the Perl5 style: ${/} The Perl 6 solution is that you disambiguate with whitespace if you don't want to follow the LTM-rule (ie you'd say '$/ ' in the regex). For string interpolation embedded closures ("my big {$house}.uc") can be used for disambiguation. Cheers, Moritz
Re: Regex repetition controlled by characters
On Sun, Aug 31, 2008 at 08:33:48AM -0600, Stephen Simmons wrote: > In S05, I found this regarding the generalized repetition specifier: > > ** '|'# repetition controlled by presence of character > > I tried it out with > > rule thislist { ** '|' }; > > and got (with Rakudo): > > perl6regex parse error: Error in closure quantifier at offset 28, found ''' > > Is this feature unsupported at the moment or am I misunderstanding it? It's unsupported at the moment -- currently this is RT #53100. Pm
Re: Regex repetition controlled by characters
Stephen Simmons wrote: > In S05, I found this regarding the generalized repetition specifier: > > ** '|'# repetition controlled by presence of character > > I tried it out with > > rule thislist { ** '|' }; > > and got (with Rakudo): > > perl6regex parse error: Error in closure quantifier at offset 28, found ''' > > Is this feature unsupported at the moment or am I misunderstanding it? It seems to be not yet supported, yes. Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
Re: Regex syntax
Moritz Lenz wrote: > I noticed that in larger grammars (like STD.pm and many PGE grammars in > the parrot repo) string literals are always quoted for clarity > > regex foo { > 'literal' > } > > Since I think this is a good idea, we could just as well enforce that, and > drop the <...> around method/regex calls: > > regex foo { > 'literal' subregex > } > > This way we'll approximate "normal" Perl 6 syntax, and maybe even improve > huffman coding. > > I guess such a syntax wouldn't be acceptible in short regexes, which are > typically written as m/.../, rx/.../ or s[...][..], so we could preseve > the old syntax for these regexes. Nitpick: s[...][..] isn't valid syntax anymore; the correct P6 equivalent is s[...] = qq[..], for reasons that were hashed out on this list some time ago. However, s/.../../ is still valid. I'm not in favor of the so-called "short forms" having a different syntax from the "long forms", and I personally like the current syntax for both. That said, all's fair if you predeclare: I could see someone creating a module that allows you to tweak the regex syntax in a manner similar to what you're proposing, if there's enough of a demand for it. -- Jonathan "Dataweaver" Lang
Re: regex matching from a position ?
> Phil, please see the perlfunc entry for "pos" and the perlre section > on \G. This is what you need. Thanks a lot! I know about pos but thought it was read-only. And \G is relatively new, isn't it? Certainly wasn't existing in '97 when I learned perl :-) And the "basics" are seldom read again in the docs... Thank you very much, although it's still 32% slower: 2505792 bytes to do ... Benchmark: timing 100 iterations of from_start, pos, re_dyn, re_once, substr, substr_set... from_start: 2 wallclock secs ( 1.06 usr + 0.00 sys = 1.06 CPU) @ 943396.23/s (n=100) pos: 0 wallclock secs ( 1.55 usr + 0.01 sys = 1.56 CPU) @ 641025.64/s (n=100) re_dyn: 7 wallclock secs ( 6.13 usr + 0.00 sys = 6.13 CPU) @ 163132.14/s (n=100) re_once: 2 wallclock secs ( 1.22 usr + 0.00 sys = 1.22 CPU) @ 819672.13/s (n=100) substr: 2 wallclock secs ( 2.39 usr + 0.01 sys = 2.40 CPU) @ 41.67/s (n=100) substr_set: 3 wallclock secs ( 3.10 usr + 0.00 sys = 3.10 CPU) @ 322580.65/s (n=100) Ratere_dyn substr_setsubstr pos re_once from_start re_dyn 163132/s-- -49% -61% -75% -80% -83% substr_set 322581/s 98% -- -23% -50% -61% -66% substr 416667/s 155%29%-- -35% -49% -56% pos641026/s 293%99% 54%-- -22% -32% re_once819672/s 402% 154% 97% 28% -- -13% from_start 943396/s 478% 192% 126% 47% 15% -- Regards, Phil #!/usr/bin/perl use Benchmark qw(cmpthese); $pos=500; $runs=100; $_=`cat /etc/* 2> /dev/null`; study $_; print length($_), " bytes to do ...\n"; cmpthese($runs, { "from_start" => sub { m/\S*\s+(\S+)/; }, "re_dyn" => sub { m/^[\x00-\xff]{$pos}\S*\s+(\S+)/; }, "re_once" => sub { m/^[\x00-\xff]{$pos}\S*\s+(\S+)/o; }, "substr" => sub { substr($_,$pos) =~ m/\S*\s+(\S+)/; }, "substr_set" => sub { $tmp=substr($_,$pos); $tmp =~ m/\S*\s+(\S+)/; }, "pos" => sub { pos($pos); m/\G\S*\s+(\S+)/; }, } );
Re: regex matching from a position ?
> From: "Ph. Marek" <[EMAIL PROTECTED]> > Date: Wed, 12 Feb 2003 08:42:57 +0100 > > --Boundary-00=_BsfS+fOE40iabfr > Content-Type: text/plain; > charset="us-ascii" > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > Hello everybody, > > I've sometimes the task to analyse a string > starting from a given position, where this position > changes after each iteration. (like index() does) > > > As this is perl there are MTOWTDIIP but I'd like > to know the fastest. > > So I used Benchmark.pm to find that out. (script attached) > > > Excerpt from script: > "from_start" => sub { m/\S*\s+(\S+)/; }, > "re_dyn" => sub { m/^[\x00-\xff]{$pos}\S*\s+(\S+)/; }, > "re_once" => sub { m/^[\x00-\xff]{$pos}\S*\s+(\S+)/o; }, > "substr" => sub { substr($_,$pos) =~ m/\S*\s+(\S+)/; }, > "substr_set" => sub { $tmp=substr($_,$pos); $tmp =~ m/\S*\s+(\S+)/; }, > > from_start is for comparision only as it should be. > re_once is for comparision too as the index can't be adjusted. > (and dynamically recompiling via eval() for changing indexes can't > be fast enough) Phil, please see the perlfunc entry for "pos" and the perlre section on \G. This is what you need. Luke
Re: Paren madness (was Re: Regex query)
David Whipp wrote: > $b = 7, 6, 5 > @b = 7, 6, 5 I understand that C's *interpretation* of the comma operator will be expunged from Perl 6. But unless comma's *precedence* is also changing, neither of those statements would build a list with three elements. It seems to me that $b = 7, 6, 5; is the same as ($b = 7), 6, 5; not $b = (7, 6, 5); because '=' binds tighter than ','. So it will assign 7 to $b, and then effectively evaluate the statement 7, 6, 5; which might build a list and then discard it. I.e., it is akin to these statements: [7, 6, 5]; 3 + 4; 7; (and equally feckless). =thom
Re: Regex query
Luke Palmer wrote: > 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
Re: Regex query
Aaron Sherman wrote: > 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: 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
Re: Paren madness (was Re: Regex query)
On Mon, Sep 23, 2002 at 11:54:06PM -0600, John Williams wrote: > 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/
Re: Paren madness (was Re: Regex query)
On Tue, 2002-09-24 at 17:27, John Williams wrote: > 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 <[EMAIL PROTECTED]>
Re: Paren madness (was Re: Regex query)
On Tue, 24 Sep 2002, Mike Lambert wrote: > > > > $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
RE: Paren madness (was Re: Regex query)
> 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.
Re: Paren madness (was Re: Regex query)
In a message dated Tue, 24 Sep 2002, Mike Lambert writes: > 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
Re: Paren madness (was Re: Regex query)
> 2. Scalar assignment. > > my $a;# 1. > $a = X; > > my $a;# 3. > ($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
RE: Paren madness (was Re: Regex query)
On Tue, 2002-09-24 at 14:47, David Whipp wrote: > 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 <[EMAIL PROTECTED]>
Re: Paren madness (was Re: Regex query)
On Tue, Sep 24, 2002 at 11:47:16AM -0700, David Whipp wrote: > 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. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
RE: Paren madness (was Re: Regex query)
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. 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.
Re: Regex query
> > 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. 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
Re: Regex query
On Tue, Sep 24, 2002 at 12:14:10PM -0400, Trey Harris wrote: > In a message dated Tue, 24 Sep 2002, Jonathan Scott Duff writes: > > > On Tue, Sep 24, 2002 at 11:14:04AM -0400, Aaron Sherman wrote: > > > 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]. > > Yes, but would the lack of parens in > > foo3 @foo, [1,2,3], foo2, foo1; > > change anything? (I think and hope not.) Not from where I sit. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Regex query
In a message dated Tue, 24 Sep 2002, Jonathan Scott Duff writes: > On Tue, Sep 24, 2002 at 11:14:04AM -0400, Aaron Sherman wrote: > > 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]. Yes, but would the lack of parens in foo3 @foo, [1,2,3], foo2, foo1; change anything? (I think and hope not.) Trey
Re: Regex query
On Tue, Sep 24, 2002 at 11:14:04AM -0400, Aaron Sherman wrote: > 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]. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Regex query
In a message dated 24 Sep 2002, Aaron Sherman writes: > 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. 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
Re: Regex query
On Tue, 2002-09-24 at 11:07, Trey Harris wrote: > 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 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 <[EMAIL PROTECTED]>
Re: Regex query
At 11:07 AM -0400 9/24/02, Trey Harris wrote: > >*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 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 [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Regex query
On Tue, 2002-09-24 at 10:27, Peter Haworth wrote: > 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 <[EMAIL PROTECTED]>
Re: Regex query
In a message dated Tue, 24 Sep 2002, Chip Salzenberg writes: > 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 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
Re: Regex query
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. -- Chip Salzenberg - a.k.a. -<[EMAIL PROTECTED]> "It furthers one to have somewhere to go."
Re: Regex query
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: 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 [EMAIL PROTECTED] Reporter: Mr Gandhi, what do you think of Western Civilization? Gandhi: I think it would be a good idea.
Re: Regex query
On Tue, Sep 24, 2002 at 11:30:57AM +0100, Simon Cozens wrote: > 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. :-) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Regex query
[EMAIL PROTECTED] (Aaron Sherman) writes: > > 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. -- [EMAIL PROTECTED] (obscurity)
Re: Regex query
[EMAIL PROTECTED] (Aaron Sherman) writes: > 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
Re: Regex query
On Tue, 2002-09-24 at 01:46, Trey Harris wrote: > 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 <[EMAIL PROTECTED]>
Re: Regex query
On Sun, 2002-09-22 at 08:07, Simon Cozens wrote: > [EMAIL PROTECTED] (Jonathan Scott Duff) writes: > > 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. 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 <[EMAIL PROTECTED]>
Re: Paren madness (was Re: Regex query)
On Mon, 23 Sep 2002, Trey Harris wrote: > > 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') !
Re: Regex query
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); 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
Re: Regex query
On Sat, 2002-09-21 at 06:18, Smylers wrote: > $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 <[EMAIL PROTECTED]>
Re: Regex query
In a message dated 24 Sep 2002, Aaron Sherman writes: > 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
Re: Paren madness (was Re: Regex query)
Replying to myself to clear a few things up... 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
Re: Regex query
On Mon, 2002-09-23 at 15:48, Luke Palmer wrote: > On 23 Sep 2002, Simon Cozens wrote: > > > [EMAIL PROTECTED] (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 <[EMAIL PROTECTED]>
Re: Paren madness (was Re: Regex query)
On Mon, 2002-09-23 at 16:58, Trey Harris wrote: > 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) > 10 { ... } # 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 <[EMAIL PROTECTED]>
Re: Paren madness (was Re: Regex query)
In a message dated Mon, 23 Sep 2002, Luke Palmer writes: > 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
Re: Regex query
On 24 Sep 2002, Simon Cozens wrote: > [EMAIL PROTECTED] (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
Re: Paren madness (was Re: Regex query)
On Mon, 23 Sep 2002, Jonathan Scott Duff wrote: > 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
Re: Paren madness (was Re: Regex query)
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. :-) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Paren madness (was Re: Regex query)
[EMAIL PROTECTED] (Trey Harris) writes: > 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
Re: Regex query
[EMAIL PROTECTED] (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? -- "Life sucks, but it's better than the alternative." -- Peter da Silva
Paren madness (was Re: Regex query)
I think this discussion has gotten out of hand, and I hope that Larry, 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
Re: Regex query
On 23 Sep 2002, Simon Cozens wrote: > [EMAIL PROTECTED] (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 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
Re: Regex query
On Sat, 2002-09-21 at 06:38, Smylers wrote: > 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 <[EMAIL PROTECTED]>
Re: Regex query
[EMAIL PROTECTED] (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. -- UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things. -- Doug Gwyn
Re: Regex query
On Sat, 21 Sep 2002 16:33:31 -0600 (MDT), Luke Palmer said: > 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. msg10771/pgp0.pgp Description: PGP signature
Re: Regex query
According to John Williams: > 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. > > Of course, _requiring_ the comma is bad [...] 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 [] -- Chip Salzenberg - a.k.a. -<[EMAIL PROTECTED]> "It furthers one to have somewhere to go."
Re: Regex query
On Sat, 21 Sep 2002, Jonathan Scott Duff wrote: > > 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
Re: Regex query
[EMAIL PROTECTED] (Markus Laire) writes: > 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)
Re: Regex query
And the one best reason I forgot to include: How do you do C< ($a + $b) * $c > if parentheses are forbidden for mathematical expressions? -- Markus Laire 'malaire' <[EMAIL PROTECTED]>
Re: Regex query
At 10:52 AM -0500 9/21/02, Jonathan Scott Duff wrote: >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 [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Regex query
Chip Salzenberg <[EMAIL PROTECTED]> writes: > 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"
Re: Regex query
[EMAIL PROTECTED] (Smylers) writes: > 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
Re: Regex query
[EMAIL PROTECTED] (Jonathan Scott Duff) writes: > 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
Re: Regex query
Luke Palmer wrote: >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 > >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
Re: Regex query
On Sun, 22 Sep 2002, Markus Laire wrote: > > 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 => 'ff', 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
Re: Regex query
> 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. 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' <[EMAIL PROTECTED]>
Re: Regex query
On 21 Sep 2002, Smylers wrote: > 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 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
Re: Regex query
On Sat, Sep 21, 2002 at 11:36:49AM -0600, John Williams wrote: > 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-) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Regex query
On 21 Sep 2002, Smylers wrote: > > 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
Re: Regex query
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: $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
Re: Regex query
On Fri, Sep 20, 2002 at 09:46:58PM -0600, John Williams wrote: > 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). -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Regex query
Tanton Gibbs wrote: > (7) == 7 > > why? Otherwise, we couldn't use parens for mathematical expressions 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 ... (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
Re: Regex query
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. 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
Re: Regex query
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. 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
Re: Regex query
> > 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. (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
Re: Regex query
On Fri, Sep 20, 2002 at 10:16:38PM -0400, Chip Salzenberg wrote: > 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. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Regex query
On Fri, Sep 20, 2002 at 02:17:42PM -0700, David Whipp wrote: > 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 :-) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Regex query
On Fri, Sep 20, 2002 at 09:02:52PM -0600, John Williams wrote: > 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 [EMAIL PROTECTED]
Re: Regex query
On Fri, 20 Sep 2002, Tanton Gibbs wrote: > > 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
Re: Regex query
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. Heck, I'd rather Perl take Python's "import" than this abomination of punctuation. -- Chip Salzenberg - a.k.a. -<[EMAIL PROTECTED]> "It furthers one to have somewhere to go."
Re: Regex query
> > 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 If this is the case, then can you also have: (,7) What is its length? Tanton
RE: Regex query
On Fri, 20 Sep 2002, David Whipp wrote: > 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
Re: Regex query
On Fri, 20 Sep 2002, Chip Salzenberg wrote: > 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
Re: Regex query
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! Larry, I strongly suggest that making () act in any way like [] is a VERY BAD IDEA. -- Chip Salzenberg - a.k.a. -<[EMAIL PROTECTED]> "It furthers one to have somewhere to go."
RE: Regex query
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? 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.
Re: Regex query
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. -- Chip Salzenberg - a.k.a. -<[EMAIL PROTECTED]> "It furthers one to have somewhere to go."
Re: Regex query
> >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. 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
Re: Regex query
John Williams wrote: >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
Re: Regex query
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). ~ John Williams
Re: Regex query
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). : 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
Re: Regex query
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)? 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
Re: Regex query
On Fri, 2002-09-20 at 10:39, Larry Wall wrote: > On 20 Sep 2002, Aaron Sherman wrote: > : 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.) Yes, sorry for the bad example. That's what I meant. -- Aaron Sherman <[EMAIL PROTECTED]>
Re: Regex query
On 20 Sep 2002, Aaron Sherman wrote: : 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
Re: Regex query
On Fri, 2002-09-20 at 04:14, Larry Wall wrote: > On 20 Sep 2002, Simon Cozens wrote: > : > 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); 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 <[EMAIL PROTECTED]>
Re: Regex query
On 20 Sep 2002, Simon Cozens wrote: : > 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