Re: `lines.contains( / \h / )` returning True for input strings not containing horizonal whitespace
lines.contains... is really short for: lines.Str.contains... Do you then understand what's going on? > On 28 Jan 2023, at 21:41, William Michels via perl6-users > wrote: > > Some more examples: > > ~$ raku -e 'put "1\n2\n3";' | raku -e 'lines.contains(/ \h /).put;' > True > ~$ raku -e 'put "1\02\03";' | raku -e 'lines.contains(/ \h /).put;' > False > ~$ raku -e 'put "1\02\03";' | raku -e 'lines.contains(/ 12 /).put;' > False > ~$ raku -e 'put "1\02\03";' | raku -e 'lines.contains(/ "1 2" /).put;' > False > ~$ > > So what I don't understand is how`.contains` coerces `\0` null-separated > strings to a `Str` without whitespace, but coerces `\n` newline-separated > strings to a `Str` with whitespace. Furthermore, it seems that `\0` > null-separated strings are correctly processed so that concatenation > artifacts such as "12" string or "1 2" string are not produced. > > And if `.contains` can coerce `\0` null-separated strings to a Str without > whitespace, can't it do the same for `\n` newline separated strings? What am > I missing? > > Best Regards, Bill. > > PS. Typo: of course, that title should read 'horizontal', not 'horizonal'. > > On Thu, Jan 26, 2023 at 3:40 PM William Michels wrote: > Thanks Sean. > > Made some progress. I like this result better: > > ~$ raku -e 'put "1\n2\n3";' | raku -e 'lines.map(*.contains(/ \h /)).put;' > False False False > > Thx, Bill. > > On Thu, Jan 26, 2023 at 12:12 PM Sean McAfee wrote: > On Thu, Jan 26, 2023 at 12:05 PM William Michels via perl6-users > wrote: > ~$ raku -e 'put "1\n2\n3";' | raku -e 'put lines.contains(/ \h /) ?? True !! > False;' > True > > lines() returns a Seq. The contains method for a Seq coerces its argument to > a Str and calls contains on that Str. And: > > $ raku -e 'put "1\n2\n3"' | raku -e 'put lines.Str' > 1 2 3 > > There's your horizontal whitespace. >
Re: `lines.contains( / \h / )` returning True for input strings not containing horizonal whitespace
Some more examples: ~$ raku -e 'put "1\n2\n3";' | raku -e 'lines.contains(/ \h /).put;' True ~$ raku -e 'put "1\02\03";' | raku -e 'lines.contains(/ \h /).put;' False ~$ raku -e 'put "1\02\03";' | raku -e 'lines.contains(/ 12 /).put;' False ~$ raku -e 'put "1\02\03";' | raku -e 'lines.contains(/ "1 2" /).put;' False ~$ So what I don't understand is how`.contains` coerces `\0` null-separated strings to a `Str` without whitespace, but coerces `\n` newline-separated strings to a `Str` with whitespace. Furthermore, it seems that `\0` null-separated strings are correctly processed so that concatenation artifacts such as "12" string or "1 2" string are not produced. And if `.contains` can coerce `\0` null-separated strings to a Str without whitespace, can't it do the same for `\n` newline separated strings? What am I missing? Best Regards, Bill. PS. Typo: of course, that title should read 'horizontal', not 'horizonal'. On Thu, Jan 26, 2023 at 3:40 PM William Michels wrote: > Thanks Sean. > > Made some progress. I like this result better: > > ~$ raku -e 'put "1\n2\n3";' | raku -e 'lines.map(*.contains(/ \h /)).put;' > False False False > > Thx, Bill. > > On Thu, Jan 26, 2023 at 12:12 PM Sean McAfee wrote: > >> On Thu, Jan 26, 2023 at 12:05 PM William Michels via perl6-users < >> perl6-us...@perl.org> wrote: >> >>> ~$ raku -e 'put "1\n2\n3";' | raku -e 'put lines.contains(/ \h /) ?? >>> True !! False;' >>> True >>> >> >> lines() returns a Seq. The contains method for a Seq coerces its >> argument to a Str and calls contains on that Str. And: >> >> $ raku -e 'put "1\n2\n3"' | raku -e 'put lines.Str' >> 1 2 3 >> >> There's your horizontal whitespace. >> >>
Re: `lines.contains( / \h / )` returning True for input strings not containing horizonal whitespace
Thanks Sean. Made some progress. I like this result better: ~$ raku -e 'put "1\n2\n3";' | raku -e 'lines.map(*.contains(/ \h /)).put;' False False False Thx, Bill. On Thu, Jan 26, 2023 at 12:12 PM Sean McAfee wrote: > On Thu, Jan 26, 2023 at 12:05 PM William Michels via perl6-users < > perl6-us...@perl.org> wrote: > >> ~$ raku -e 'put "1\n2\n3";' | raku -e 'put lines.contains(/ \h /) ?? True >> !! False;' >> True >> > > lines() returns a Seq. The contains method for a Seq coerces its argument > to a Str and calls contains on that Str. And: > > $ raku -e 'put "1\n2\n3"' | raku -e 'put lines.Str' > 1 2 3 > > There's your horizontal whitespace. > >
Re: `lines.contains( / \h / )` returning True for input strings not containing horizonal whitespace
On Thu, Jan 26, 2023 at 12:05 PM William Michels via perl6-users < perl6-us...@perl.org> wrote: > ~$ raku -e 'put "1\n2\n3";' | raku -e 'put lines.contains(/ \h /) ?? True > !! False;' > True > lines() returns a Seq. The contains method for a Seq coerces its argument to a Str and calls contains on that Str. And: $ raku -e 'put "1\n2\n3"' | raku -e 'put lines.Str' 1 2 3 There's your horizontal whitespace.
`lines.contains( / \h / )` returning True for input strings not containing horizonal whitespace
Hi, I'm seeing an issue where I try to write parallel code between `slurp` and `lines`, expecting that when I feed each one-liner a string with vertical whitespace (but not horizontal whitespace), the two methods will be differentiated--since lines autochomps by default. ~$ raku -e 'put "1\n2\n3";' | raku -e 'put slurp.contains(/ \h /) ?? True !! False;' False ~$ raku -e 'put "1\n2\n3";' | raku -e 'put lines.contains(/ \h /) ?? True !! False;' True However, my 'control case' (second example above) is showing that a string devoid of apparent whitespace is coming up positive, i.e. returning True. I would think this is a 'trap for the unwary', if it is indeed the specified behavior. Comments/feedback welcome and appreciated. FYI I'm on Rakudo™ v2022.07. Thx, Bill.
Re: Seq whitespace sensitivity? (was Re: print particular lines question)
Dear Tobias (and Sean), I opened a Github issue:
https://github.com/rakudo/rakudo/issues/3881
On Wed, Aug 26, 2020 at 12:12 PM Tobias Boege wrote:
> On Wed, 26 Aug 2020, Tobias Boege wrote:
> > Observe:
> >
> > > 1 ...^ 20
> > (1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19)
> >
> > > 1 ... ^20 # actually C«1 ... (0..19)»
> > (1 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19)
> >
> > The documentation [1] states that the C«...» infix is list-associative
> > and while I have never seen an example of that (including in that docs
> > page), it would explain why it happily takes in your list (1) and then
> > your list (0 .. 19) and concatenates them into a sequence, without
> > applying any of the usual sequence operator magic.
>
> And I must correct myself. The associativity has nothing to do with this.
> I don't know where my mind was when I wrote that. From the documtation,
> I would blame the slurpy argument **@ for that behavior of just taking in
> lists and effectively iterating them into a new Seq, and in Rakudo it is
> apparently this special candidate:
>
> #
> https://github.com/rakudo/rakudo/blob/e2855aa/src/core.c/operators.pm6#L129
> multi sub infix:<...>(\a, Mu \b) {
> Seq.new(SEQUENCE(a, b))
> }
>
> Best,
> Tobias
>
Re: Seq whitespace sensitivity? (was Re: print particular lines question)
On Wed, 26 Aug 2020, Tobias Boege wrote:
> Observe:
>
> > 1 ...^ 20
> (1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19)
>
> > 1 ... ^20 # actually C«1 ... (0..19)»
> (1 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19)
>
> The documentation [1] states that the C«...» infix is list-associative
> and while I have never seen an example of that (including in that docs
> page), it would explain why it happily takes in your list (1) and then
> your list (0 .. 19) and concatenates them into a sequence, without
> applying any of the usual sequence operator magic.
And I must correct myself. The associativity has nothing to do with this.
I don't know where my mind was when I wrote that. From the documtation,
I would blame the slurpy argument **@ for that behavior of just taking in
lists and effectively iterating them into a new Seq, and in Rakudo it is
apparently this special candidate:
# https://github.com/rakudo/rakudo/blob/e2855aa/src/core.c/operators.pm6#L129
multi sub infix:<...>(\a, Mu \b) {
Seq.new(SEQUENCE(a, b))
}
Best,
Tobias
Re: Seq whitespace sensitivity? (was Re: print particular lines question)
On Wed, Aug 26, 2020 at 10:33 AM Tobias Boege wrote:
>
> On Wed, 26 Aug 2020, William Michels via perl6-users wrote:
> > > They can be pretty great, especially when combined with the magic op=
> > > operators that (in essence) know about identity elements. I've done a
> > > few challenges on the Code Golf Stackexchange site where I wanted an
> > > infinite sequence like this:
> > >
> > > 0, 1, -2, 3, -4, 5, -6, ...
> > >
> > > It took me a while to realize this can be expressed in Raku simply as:
> > >
> > > { $++ * ($ *= -1) } ... *
> > >
> >
> > Hi Sean, that's a neat solution! I seem to have found an oddity though
> > (whitespace sensitivity). In the REPL:
> >
> > > say { $++ * ($ *= -1) } ...21
> > (0 1 -2 3 -4 5 -6 7 -8 9 -10 11 -12 13 -14 15 -16 17 -18 19 -20 21)
> > > say { $++ * ($ *= -1) } ...^21
> > (0 1 -2 3 -4 5 -6 7 -8 9 -10 11 -12 13 -14 15 -16 17 -18 19 -20)
> > > say { $++ * ($ *= -1) } ... 21
> > (0 1 -2 3 -4 5 -6 7 -8 9 -10 11 -12 13 -14 15 -16 17 -18 19 -20 21)
> > > say { $++ * ($ *= -1) } ... ^21
> > (0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20)
> >
> > I would have expected the last line of code (whitespace between "..."
> > and "^21") to give the same answer as the first three. Any ideas?
> >
>
> The difference is likely to come from the fact that "^20" as a term is
> a shorthand for the range "0..^20", while "...^" is the sequence operator
> with exclusive endpoint. Placement of whitespace will dictate where the
> little hat attaches to and thus change the meaning of the statement.
>
> Observe:
>
> > 1 ...^ 20
> (1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19)
>
> > 1 ... ^20 # actually C«1 ... (0..19)»
> (1 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19)
>
> The documentation [1] states that the C«...» infix is list-associative
> and while I have never seen an example of that (including in that docs
> page), it would explain why it happily takes in your list (1) and then
> your list (0 .. 19) and concatenates them into a sequence, without
> applying any of the usual sequence operator magic.
>
> When you write "1 ...^20" I suppose that longest-token matching prefers
> the former interpretation as it makes the infix token longer.
>
> Best,
> Tobias
>
> [1] https://docs.raku.org/language/operators#index-entry-..._operators
>
> --
> "There's an old saying: Don't change anything... ever!" -- Mr. Monk
Thank you, Tobias! Here's my take (REPL, below):
> 1...20
(1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20)
> 1... 20
(1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20)
> 1...^20
(1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19)
> 1... ^20
(1 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19)
WOW. I never would have expected the last line of code above to return
a sequence starting "1, 0, 1 ..." up to 19.
Would I ever want that sequence? Couldn't I get that sequence just as
easily by asking for a sequence of (-1 ... ^20), and then calling
abs() on each element (using hyper)? See below:
> (-1... ^20)>>.abs
(1 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19)
>
Anyway, I opened a Github issue, and (like yourself here), Jonathan
has graciously replied. Feel free to chime in at:
https://github.com/rakudo/rakudo/issues/3881
Thanks again, Bill.
Re: Seq whitespace sensitivity? (was Re: print particular lines question)
On Wed, 26 Aug 2020, William Michels via perl6-users wrote:
> > They can be pretty great, especially when combined with the magic op=
> > operators that (in essence) know about identity elements. I've done a few
> > challenges on the Code Golf Stackexchange site where I wanted an infinite
> > sequence like this:
> >
> > 0, 1, -2, 3, -4, 5, -6, ...
> >
> > It took me a while to realize this can be expressed in Raku simply as:
> >
> > { $++ * ($ *= -1) } ... *
> >
>
> Hi Sean, that's a neat solution! I seem to have found an oddity though
> (whitespace sensitivity). In the REPL:
>
> > say { $++ * ($ *= -1) } ...21
> (0 1 -2 3 -4 5 -6 7 -8 9 -10 11 -12 13 -14 15 -16 17 -18 19 -20 21)
> > say { $++ * ($ *= -1) } ...^21
> (0 1 -2 3 -4 5 -6 7 -8 9 -10 11 -12 13 -14 15 -16 17 -18 19 -20)
> > say { $++ * ($ *= -1) } ... 21
> (0 1 -2 3 -4 5 -6 7 -8 9 -10 11 -12 13 -14 15 -16 17 -18 19 -20 21)
> > say { $++ * ($ *= -1) } ... ^21
> (0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20)
>
> I would have expected the last line of code (whitespace between "..."
> and "^21") to give the same answer as the first three. Any ideas?
>
The difference is likely to come from the fact that "^20" as a term is
a shorthand for the range "0..^20", while "...^" is the sequence operator
with exclusive endpoint. Placement of whitespace will dictate where the
little hat attaches to and thus change the meaning of the statement.
Observe:
> 1 ...^ 20
(1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19)
> 1 ... ^20 # actually C«1 ... (0..19)»
(1 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19)
The documentation [1] states that the C«...» infix is list-associative
and while I have never seen an example of that (including in that docs
page), it would explain why it happily takes in your list (1) and then
your list (0 .. 19) and concatenates them into a sequence, without
applying any of the usual sequence operator magic.
When you write "1 ...^20" I suppose that longest-token matching prefers
the former interpretation as it makes the infix token longer.
Best,
Tobias
[1] https://docs.raku.org/language/operators#index-entry-..._operators
--
"There's an old saying: Don't change anything... ever!" -- Mr. Monk
Seq whitespace sensitivity? (was Re: print particular lines question)
> They can be pretty great, especially when combined with the magic op=
> operators that (in essence) know about identity elements. I've done a few
> challenges on the Code Golf Stackexchange site where I wanted an infinite
> sequence like this:
>
> 0, 1, -2, 3, -4, 5, -6, ...
>
> It took me a while to realize this can be expressed in Raku simply as:
>
> { $++ * ($ *= -1) } ... *
>
Hi Sean, that's a neat solution! I seem to have found an oddity though
(whitespace sensitivity). In the REPL:
> say { $++ * ($ *= -1) } ...21
(0 1 -2 3 -4 5 -6 7 -8 9 -10 11 -12 13 -14 15 -16 17 -18 19 -20 21)
> say { $++ * ($ *= -1) } ...^21
(0 1 -2 3 -4 5 -6 7 -8 9 -10 11 -12 13 -14 15 -16 17 -18 19 -20)
> say { $++ * ($ *= -1) } ... 21
(0 1 -2 3 -4 5 -6 7 -8 9 -10 11 -12 13 -14 15 -16 17 -18 19 -20 21)
> say { $++ * ($ *= -1) } ... ^21
(0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20)
I would have expected the last line of code (whitespace between "..."
and "^21") to give the same answer as the first three. Any ideas?
Best, Bill.
[perl #126532] [BUG] Internal error when passing whitespace through a named argument in Rakudo
The examples would fail usage constraints with the parameterless MAIN. I could not get them to fail with any internal messages on current rakudo, either with the parameterless MAIN or with a MAIN that had a :$y. Haven't looked as to when this got fixed. Tests added for both cases (though I had to add a sub USAGE when testing the parameterless case) in https://github.com/perl6/roast/commit/bdf67b698b, so closing as resolved.
Re: User defined infix operators and whitespace
It seems to work without spaces if you choose a symbol that is not
letter-like.
# U+1F3B2 Game Die
sub infix:<> ( Int $num, Int $size ) { [+] (1..$size).roll($num) };
sub prefix:<> ( Int $size ) { 1$size }
say 10;
say 46;
# ⛏ U+26CF Pick
sub infix:<⛏> ( Int $num, Int $size ) { [+] (1..$size).roll($num) };
sub prefix:<⛏> ( Int $size ) { 1⛏$size }
say ⛏10;
say 4⛏6;
# Not working
# ⅆ U+2146 Double-Struck Italic Small D
#sub infix:<ⅆ> ( Int $num, Int $size ) { [+] (1..$size).roll($num) };
#sub prefix:<ⅆ> ( Int $size ) { 1ⅆ$size }
#say ⅆ10;
#say 4ⅆ6;
On 10 August 2017 at 21:16, Simon Proctor <simon.proc...@gmail.com> wrote:
> So I had a crazy little idea. I've played the odd bit of roleplaying in my
> time and wanted to created a 'd' operator.
>
> Quite simple really.
>
> sub infix: ( Int $num, Int $size ) { [+] (1..$size).roll($num) };
>
> sub prefix: ( Int $size ) { 1 d $size }
>
> Gives us 3 d 6 to roll 3 six sided dice or a prefix d 10 for a single 10
> sided dice.
>
> Except... I'd really like to write 3d6 or d10 but the parser barfs.
>
> Am I going to just have to live with that? Or did I miss something
> obvious?
>
> Obviously it's possible to have operators that ignore whitespace (1+1
> works just fine) but is it possibly for user defined ones?
>
> Possibly more serious ones.
>
> Simon
>
--
Norman Gaywood, Computer Systems Officer
School of Science and Technology
University of New England
Armidale NSW 2351, Australia
ngayw...@une.edu.au http://turing.une.edu.au/~ngaywood
Phone: +61 (0)2 6773 2412 Mobile: +61 (0)4 7862 0062
Please avoid sending me Word or Power Point attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html
Re: User defined infix operators and whitespace
I think there are a couple answers. The simple one is yes -- embrace the
whitespace. Maybe wrap them in ()', like (2 d 6).
Another line of ideas is wrapping things with some other operators. Maybe a
special quoting operator or a converter.
[[2d6]] # double for dice!
"2d6":dice # postfix. This used to work but maybe doesn't now
dice[ 2d6 ] # circumfix
And then the third thing that comes to mind is adding a slang, though that
is, I believe, the least stable language-level approach. Dunno.
--Brock
On Thu, Aug 10, 2017 at 7:16 AM, Simon Proctor <simon.proc...@gmail.com>
wrote:
> So I had a crazy little idea. I've played the odd bit of roleplaying in my
> time and wanted to created a 'd' operator.
>
> Quite simple really.
>
> sub infix: ( Int $num, Int $size ) { [+] (1..$size).roll($num) };
>
> sub prefix: ( Int $size ) { 1 d $size }
>
> Gives us 3 d 6 to roll 3 six sided dice or a prefix d 10 for a single 10
> sided dice.
>
> Except... I'd really like to write 3d6 or d10 but the parser barfs.
>
> Am I going to just have to live with that? Or did I miss something
> obvious?
>
> Obviously it's possible to have operators that ignore whitespace (1+1
> works just fine) but is it possibly for user defined ones?
>
> Possibly more serious ones.
>
> Simon
>
User defined infix operators and whitespace
So I had a crazy little idea. I've played the odd bit of roleplaying in my
time and wanted to created a 'd' operator.
Quite simple really.
sub infix: ( Int $num, Int $size ) { [+] (1..$size).roll($num) };
sub prefix: ( Int $size ) { 1 d $size }
Gives us 3 d 6 to roll 3 six sided dice or a prefix d 10 for a single 10
sided dice.
Except... I'd really like to write 3d6 or d10 but the parser barfs.
Am I going to just have to live with that? Or did I miss something obvious?
Obviously it's possible to have operators that ignore whitespace (1+1 works
just fine) but is it possibly for user defined ones?
Possibly more serious ones.
Simon
[perl #131382] [LTA] for, parens, and lack of whitespace (for(^700){say 2})
# New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev
# Please include the string: [perl #131382]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=131382 >
Code:
for(^700){say 2}
Result:
===SORRY!=== Error while compiling -e
Undeclared routine:
for used at line 1
This just happened on the channel:
https://irclog.perlgeek.de/perl6/2017-05-27#i_14645895
Note that we already have a good error message:
Code:
for(^700) {say 2}
Result:
===SORRY!===
Word 'for' interpreted as 'for()' function call; please use whitespace instead
of parens
at -e:1
--> for⏏(^700) {say 2}
Unexpected block in infix position (two terms in a row)
at -e:1
--> for(^700)⏏ {say 2}
However, it is not printed if you omit space everywhere.
[perl6/specs] 78c421: S05-regex.pod: clairify that trailing whitespace i...
Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: 78c4211e940306f896086f6304b470a4cdcb954c https://github.com/perl6/specs/commit/78c4211e940306f896086f6304b470a4cdcb954c Author: Samantha McVey <samant...@posteo.net> Date: 2017-01-01 (Sun, 01 Jan 2017) Changed paths: M S05-regex.pod Log Message: --- S05-regex.pod: clairify that trailing whitespace is significant w/ :s
[perl #129920] [BUG] Configure.PL does not protect whitespace in --prefix
# New Ticket Created by "brian d foy" # Please include the string: [perl #129920] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=129920 > In the rakudo-star-2016.07 release, the value given to Configure's --prefix might end up with whitespace (even if the initial value does not have it). This path is not quoted in nqp/Makefile, so that fails and the build cannot continue. I ran into this because I used a path that was a symlink: % perl Configure.pl --gen-moar --prefix /Users/brian/Dropbox/perl6s/rakudo-star-2016.07 Various things had the same problem: % perl Configure.PL --gen-moar --prefix "/Volumes/Big Scratch/Dropbox/perl6s/rakudo-star-2016.07" % perl Configure.PL --gen-moar --prefix /Volumes/"Big Scratch"/Dropbox/perl6s/rakudo-star-2016.07 % perl Configure.PL --gen-moar --prefix /Volumes/Big\\ Scratch/Dropbox/perl6s/rakudo-star-2016.07 Paths interpolated into shell programs or makefiles should be protected in some fashion. -- brian d foy <brian.d@gmail.com> http://www.pair.com/~comdog/
[perl #129316] [BUG] In given block, whitespace matters too much to parser.
# New Ticket Created by Larry Brasfield
# Please include the string: [perl #129316]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=129316 >
Using Rakudo Star:
~$ perl6 -version
This is Rakudo version 2016.07.1 built on MoarVM version 2016.07
implementing Perl 6.c.
With a script, try.pl, containing this text:
given prompt "Enter a number: " {
when * < 0 { say "Negative"; }
when * > 0 { say "Positive"; }
default { say "Zero"; }
}
, I get results precisely as expected. (It compiles, prompts, classifies
its input.)
But if the script is changed, only by replacing some newline~space
sequences with space:
given prompt "Enter a number: " {
when * < 0 { say "Negative"; } when * > 0 { say "Positive"; } default {
say "Zero"; }
}
then an error message issues:
~$ perl6 try.pl
===SORRY!=== Error while compiling /home/larry/try.pl
Strange text after block (missing semicolon or comma?)
at /home/larry/try.pl:8
--> when * < 0 { say "Negative"; }⏏ when * > 0 { say "Positive"; }
default
, which I expect to give the same result as before since Perl6 is not a
line-oriented language (excepting a certain literal construct.)
For convenience, I attach the file I used to demonstrate this bug. I
discovered it when trying an example which I converted to a one-liner in an
interactive REPL session.
Best regards,
--
Larry
#given prompt "Enter a number: " {
# when * < 0 { say "Negative"; }
# when * > 0 { say "Positive"; }
# default { say "Zero"; }
#}
given prompt "Enter a number: " {
when * < 0 { say "Negative"; } when * > 0 { say "Positive"; } default { say "Zero"; }
}
[perl #129316] [BUG] In given block, whitespace matters too much to parser.
Thank you for the report, however, this is not a bug.
Closing curlies ('}') end statements when they're the last
non-whitespace/non-unspace character on the line, which is why your first
version works.
When putting them all on one line, you have to explicitly specify where the
statements end,
so when * < 0 { say "Negative"; }; when * > 0 { say "Positive"; }; default {
say "Zero"; } will work just fine.
Cheers,
ZZ
On Tue Sep 20 08:02:39 2016, brasfield.la...@gmail.com wrote:
> Using Rakudo Star:
> ~$ perl6 -version
> This is Rakudo version 2016.07.1 built on MoarVM version 2016.07
> implementing Perl 6.c.
>
> With a script, try.pl, containing this text:
> given prompt "Enter a number: " {
> when * < 0 { say "Negative"; }
> when * > 0 { say "Positive"; }
> default { say "Zero"; }
> }
> , I get results precisely as expected. (It compiles, prompts, classifies
> its input.)
>
> But if the script is changed, only by replacing some newline~space
> sequences with space:
> given prompt "Enter a number: " {
> when * < 0 { say "Negative"; } when * > 0 { say "Positive"; } default {
> say "Zero"; }
> }
> then an error message issues:
> ~$ perl6 try.pl
> ===SORRY!=== Error while compiling /home/larry/try.pl
> Strange text after block (missing semicolon or comma?)
> at /home/larry/try.pl:8
> --> when * < 0 { say "Negative"; }⏏ when * > 0 { say "Positive"; }
> default
> , which I expect to give the same result as before since Perl6 is not a
> line-oriented language (excepting a certain literal construct.)
>
> For convenience, I attach the file I used to demonstrate this bug. I
> discovered it when trying an example which I converted to a one-liner in an
> interactive REPL session.
>
> Best regards,
[perl #128561] [LTA] inconsistent whitespace rules re diacritics
# New Ticket Created by Zefram
# Please include the string: [perl #128561]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=128561 >
Does a space-with-diacritic grapheme count as whitespace, for the purposes
of the Perl 6 grammar? Sometimes it does, and sometimes it doesn't:
> "".EVAL.perl
("foo", "bar")
> "+ \x[308]3".EVAL.perl
===SORRY!=== Error while compiling /home/zefram/tmp/EVAL_1
Prefix + requires an argument, but no valid term found
at /home/zefram/tmp/EVAL_1:1
--> +^ ?3
expecting any of:
prefix
> "Q \x[308]foo bar \x[308]".EVAL
===SORRY!=== Error while compiling /home/zefram/tmp/EVAL_2
Whitespace character (0x20) is not allowed as a delimiter
at /home/zefram/tmp/EVAL_2:1
--> Q^ ?foo bar ?
I think it should be consistent.
-zefram
[perl6/specs] 94357c: Typos, markup corrections, trailing whitespace
Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: 94357ccfebed86b1c223244e69d364d03b3a548b https://github.com/perl6/specs/commit/94357ccfebed86b1c223244e69d364d03b3a548b Author: Aleks-Daniel Jakimenko-Aleksejev <alex.jakime...@gmail.com> Date: 2015-12-29 (Tue, 29 Dec 2015) Changed paths: M S99-glossary.pod Log Message: --- Typos, markup corrections, trailing whitespace
[perl #120895] heredocs get tabs removed when asked to dedent whitespace
On Sat Jan 04 02:26:52 2014, masak wrote: > On Sun Dec 29 08:24:44 2013, FROGGS.de wrote: > > p: say qq:to/EOF/ ~~ /\t/;\thelloEOF# the tab is > > preserved > > rakudo-parrot c14a84: OUTPUT«｢ ｣» > > p: say qq:to/EOF/ ~~ /\t/;\thelloEOF# now it is > > gone > > rakudo-parrot c14a84: OUTPUT«Nil» > > > > In the second example it is meant to strip four space chars, but > > additionally it converts the tabs to space chars. Which is bad for > > e.g. Makefiles. > > I agree. S32/Str is a bit vague about what to do in this case. It > talks about different policies (spaces only, only some other \h char, > or mixed types) when *adding* spaces, but it doesn't mention what to > do when removing spaces. > > I'm fine with clarifying the spec, as long as we err on the side of > sanity/consistency. Feel free to run any patches through me for > review. TimToady++ confirmed that \t falls under the same rule as \r, \n, and so forth - that is, we should be interpolating it after considering the dedent. I've implemented that now, and it's tested in S02-literals/quoting.t. /jnthn
[perl #125543] [BUG] De-indentation should de-indent physical lines, not whitespace following a \n escape in heredocs in Rakudo
On Fri Jul 03 12:29:34 2015, masak wrote: > I found some behavior using heredocs, and I'm not really > sure what the right thing to do is > https://gist.github.com/hoelzro/3b1ff9951908c9ce5aa4 > > (Gist shows the following heredoc with a \n in it, which gives a > de-indentation warning at compile time.) > > my $here = qq:to/END_TEXT/; > foo\nbar > END_TEXT > > it's concerning how leading whitespace removal is handled > when one has an embedded newline via \n in a heredoc > oh, interesting > i hadn't considered newlines that are escaped inside > heredocs like that when i wrote the new dedenting code > timotimo: I hadn't considered it either until I was > converting code that used a single non-heredoc line and came across > that =/ > I would file a ticket, but I don't even know if that's a > bug. I don't even know what I expect it should do! > Is there a way to dedent the heredoc literal text before > expanding newline escape sequences? > TimToady may have to weigh in > I'm... not sure I feel that's a bug... > masak: "not sure" is the thing with me too =/ > I can understand the argument that this \n newline is not part > of the heredoc's actual newlines, but... > ...I'm also not ready to tear up compiler internals just to > fix this one. > but let's see if TimToady has some nice insight about it. > it's kind of related to (but not the same as) > http://strangelyconsistent.org/blog/here-be-heredocs under the heading > "Indentation, revisited" > why would you want to embed a \n in a heredoc? > colomon: that's a good, but separate question :) > we're exploring "what happens when you do?" > I don't believe it should be illegal. > colomon, masak: there's no good reason, I just found it > interesting > it is interesting. > I was converting a long single double quoted string with > multiple embedded newlines into a heredoc while refactoring a program > I mean, from the user's point of view, a \n in a heredoc isn't > the same as a hard newline in a heredoc. > right > what happens if you embed a string with a newline in it? I > actually do that quite a bit in my (mostly p5) scripts > colomon: read the blog post I linked. > I seem to remember I did it one way in the original herdocs > impl in Rakudo, and something was off and got changed (probably what > masak++ is referencing) > yes. > re \n in heredocs, the dedent should be happening before \n > interpolation, just as it happens before $I-contain-a-newline > interpolation > so re http://irclog.perlgeek.de/perl6/2015-07-03#i_10845432 > I'd call it a bug > > (URL referencing hoelzro's original example at the top of this report) > > recall that dedent is only for the purposes of establishing > a false margin on the literal text, so from the user's perspective it > really needs to happen before any kind of string processing > I can think of several ways to fix it > one is to treat \n interpolation more like $newline > interpolation > another is to substitute a sentinel character for \n inside > heredoc parsing, and only dedent after the sentinel (and replace the > sentinel with a real \n) > * masak submits TimToady-approved heredoc \n de-indentation rakudobug Turns out there was a neater way than a sentinel: in the case of being inside a heredoc, code-gen \n and \r\n as an AST node, not just a string. This triggers the same codepaths that deal with interpolation. Tests in S02-literals/quoting.t. /jnthn
[perl #126532] [BUG] Internal error when passing whitespace through a named argument in Rakudo
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #126532]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=126532 >
Basically, any argument containing only whitespace seems to trigger
this error. It seems that the presence of the MAIN sub is part of the
error; remove it and it accepts all of the inputs causing an error
below.
$ cat x.pl
sub MAIN {}
$ perl6 x.pl -y=' '
Cannot invoke this object
in block at x.pl:1
$ perl6 x.pl -y=''
Cannot invoke this object
in block at x.pl:1
$ perl6 x.pl -y=`perl -E'say "\n"'`
Cannot invoke this object
in block at x.pl:1
$ perl6 x.pl -y=`perl -E'say "\t"'`
Cannot invoke this object
in block at x.pl:1
$ perl6 x.pl -y=`perl -E'say "\t "'`
Cannot invoke this object
in block at x.pl:1
$ perl6 --version
This is perl6 version 2015.10-89-g36c4c6a built on MoarVM version
2015.10-14-g5ff3001
[perl #126219] LTA error message includes whitespace (dd .     dd)
# New Ticket Created by Alex Jakimenko # Please include the string: [perl #126219] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=126219 > Code: dd . dd Result: ===SORRY!=== Error while compiling ./test2.pl Preceding context expects a term, but found infix . instead at ./test2.pl:5 --> dd .⏏ I don't see any reason for it to include whitespace in the error message.
[perl #125812] LTA error message when doing with() { } with no whitespace before ()
# New Ticket Created by Alex Jakimenko
# Please include the string: [perl #125812]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/Ticket/Display.html?id=125812
Code:
with(1) { }
Result:
===SORRY!=== Error while compiling ./test.pl
Unexpected block in infix position (missing statement control word before
the expression?)
at ./test.pl:2
-- with(1)⏏ { }
expecting any of:
infix
infix stopper
It looks like “with” and “without” are missing some checks, unlike “if”,
“unless”. Here is what happens if you use if:
===SORRY!===
Word 'if' interpreted as 'if()' function call; please use whitespace
instead of parens
at ./test.pl:2
-- if⏏(1) { }
Unexpected block in infix position (two terms in a row)
at ./test.pl:2
-- if(1)⏏ { }
In other words, “with” and “without” should produce same error message
about whitespace.
IRC log: http://irclog.perlgeek.de/perl6/2015-08-15#i_11061258
[perl #125543] [BUG] De-indentation should de-indent physical lines, not whitespace following a \n escape in heredocs in Rakudo
# New Ticket Created by Carl Mäsak # Please include the string: [perl #125543] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/Ticket/Display.html?id=125543 hoelzro I found some behavior using heredocs, and I'm not really sure what the right thing to do is hoelzro https://gist.github.com/hoelzro/3b1ff9951908c9ce5aa4 (Gist shows the following heredoc with a \n in it, which gives a de-indentation warning at compile time.) my $here = qq:to/END_TEXT/; foo\nbar END_TEXT hoelzro it's concerning how leading whitespace removal is handled when one has an embedded newline via \n in a heredoc timotimo oh, interesting timotimo i hadn't considered newlines that are escaped inside heredocs like that when i wrote the new dedenting code hoelzro timotimo: I hadn't considered it either until I was converting code that used a single non-heredoc line and came across that =/ hoelzro I would file a ticket, but I don't even know if that's a bug. I don't even know what I expect it should do! lucasb Is there a way to dedent the heredoc literal text before expanding newline escape sequences? hoelzro TimToady may have to weigh in masak I'm... not sure I feel that's a bug... hoelzro masak: not sure is the thing with me too =/ masak I can understand the argument that this \n newline is not part of the heredoc's actual newlines, but... masak ...I'm also not ready to tear up compiler internals just to fix this one. masak but let's see if TimToady has some nice insight about it. masak it's kind of related to (but not the same as) http://strangelyconsistent.org/blog/here-be-heredocs under the heading Indentation, revisited colomon why would you want to embed a \n in a heredoc? masak colomon: that's a good, but separate question :) masak we're exploring what happens when you do? masak I don't believe it should be illegal. hoelzro colomon, masak: there's no good reason, I just found it interesting masak it is interesting. hoelzro I was converting a long single double quoted string with multiple embedded newlines into a heredoc while refactoring a program masak I mean, from the user's point of view, a \n in a heredoc isn't the same as a hard newline in a heredoc. hoelzro right colomon what happens if you embed a string with a newline in it? I actually do that quite a bit in my (mostly p5) scripts masak colomon: read the blog post I linked. jnthn I seem to remember I did it one way in the original herdocs impl in Rakudo, and something was off and got changed (probably what masak++ is referencing) masak yes. TimToady re \n in heredocs, the dedent should be happening before \n interpolation, just as it happens before $I-contain-a-newline interpolation TimToady so re http://irclog.perlgeek.de/perl6/2015-07-03#i_10845432 I'd call it a bug (URL referencing hoelzro's original example at the top of this report) TimToady recall that dedent is only for the purposes of establishing a false margin on the literal text, so from the user's perspective it really needs to happen before any kind of string processing TimToady I can think of several ways to fix it TimToady one is to treat \n interpolation more like $newline interpolation TimToady another is to substitute a sentinel character for \n inside heredoc parsing, and only dedent after the sentinel (and replace the sentinel with a real \n) * masak submits TimToady-approved heredoc \n de-indentation rakudobug
[perl6/specs] 221b27: typos and whitespace fixes
Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: 221b27df6c37f7154e51a062faa3a9b93218d11f https://github.com/perl6/specs/commit/221b27df6c37f7154e51a062faa3a9b93218d11f Author: Steve Mynott steve.myn...@gmail.com Date: 2015-05-09 (Sat, 09 May 2015) Changed paths: M S99-glossary.pod Log Message: --- typos and whitespace fixes
[perl #124213] [BUG] Bizarre LTA error message when not putting in whitespace between 'is MyBase' and the opening brace '{' in class declaration in Rakudo
# New Ticket Created by Carl Mäsak
# Please include the string: [perl #124213]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/Ticket/Display.html?id=124213
Ven m: class T{}; class S is T{}
camelia rakudo-moar 2b303a: OUTPUT«===SORRY!===Cannot find method
'has_compile_time_value'»
Ven uh-ho.
moritz Ven: try with a space before the {
Ven m: class T {}; class S is T {}
camelia rakudo-moar 2b303a: OUTPUT«1»
* masak submits rakudobug
jnthn I bet it's the is T{} parsing as a postcircumfix...it's still
a bizarre error.
Ven incomprehension-based debugging
[perl6/specs] 9f20af: Fix typos and whitespace
Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: 9f20af7d7575f6f1fd685a941fd39857a84193a8 https://github.com/perl6/specs/commit/9f20af7d7575f6f1fd685a941fd39857a84193a8 Author: raiph raiph.mel...@gmail.com Date: 2014-11-17 (Mon, 17 Nov 2014) Changed paths: M S17-concurrency.pod Log Message: --- Fix typos and whitespace
[perl6/specs] ac5860: * whitespace
Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: ac586073aea057c20ab1992bbb7a83d6966e3a63 https://github.com/perl6/specs/commit/ac586073aea057c20ab1992bbb7a83d6966e3a63 Author: Will Coke Coleda w...@coleda.com Date: 2014-08-20 (Wed, 20 Aug 2014) Changed paths: M S99-glossary.pod Log Message: --- * whitespace * spelling * reordering some entries for clarity * grammar * fix POD-os * americanize * capitalization consistency
[perl6/specs] 2be6bf: just a tiny whitespace fix.
Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: 2be6bfa128ad3d4ba74978649f1071c00ed7af32 https://github.com/perl6/specs/commit/2be6bfa128ad3d4ba74978649f1071c00ed7af32 Author: Timo Paulssen timona...@perpetuum-immobile.de Date: 2014-03-10 (Mon, 10 Mar 2014) Changed paths: M S32-setting-library/Containers.pod Log Message: --- just a tiny whitespace fix.
[perl #78202] [BUG] Rakudo treats ' #' after interpolated variable as whitespace (whereas STD.pm6 doesn't)
On Tue Nov 20 11:36:45 2012, FROGGS.de wrote:
looks good nowadays:
FROGGS rakudo: sub Good ($time) { say Good $time #perl6. }; Good now
# discovered by tylercurtis
p6eval rakudo bf472b: OUTPUT«Good Instant:1353440186.178945 #perl6.»
Test added in S02-literals/string-interpolation.t
--
Will Coke Coleda
[perl #120895] heredocs get tabs removed when asked to dedent whitespace
# New Ticket Created by Tobias Leich # Please include the string: [perl #120895] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/Ticket/Display.html?id=120895 FROGGS p: say qq:to/EOF/ ~~ /\t/;\thelloEOF# the tab is preserved camelia rakudo-parrot c14a84: OUTPUT«｢ ｣» FROGGS p: say qq:to/EOF/ ~~ /\t/;\thelloEOF# now it is gone camelia rakudo-parrot c14a84: OUTPUT«Nil» In the second example it is meant to strip four space chars, but additionally it converts the tabs to space chars. Which is bad for e.g. Makefiles.
[perl #120526] ss/.../.../ doesn't preserve whitespace
# New Ticket Created by Will Coleda
# Please include the string: [perl #120526]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/Ticket/Display.html?id=120526
S05-substitution/subst.t has the following test which fails on both rakudos:
{
$_ = a\nb\tc d;
ok ss/a b c d/w x y z/, 'successful substitution returns True';
# XXX This test fails.
is $_, w\nx\ty z, 'ss/.../.../ preserves whitespace';
dies_ok {abc ~~ ss/a b c/ x y z/}, 'Cannot ss/// string literal';
}
--
Will Coke Coleda
[perl6/specs] 7b0188: [new 17] whitespace fixes
Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: 7b0188b633d795136bca15d70401c146eb20089a https://github.com/perl6/specs/commit/7b0188b633d795136bca15d70401c146eb20089a Author: Moritz Lenz mor...@faui2k3.org Date: 2013-11-03 (Sun, 03 Nov 2013) Changed paths: M S17-concurrency-jnthn.pod Log Message: --- [new 17] whitespace fixes and close a dangling quote
[perl #119083] [BUG] infix operator with several words matches against one space between the words in Rakudo, but not against any other whitespace (as in Niecza and STD.pm6)
# New Ticket Created by Carl Mäsak
# Please include the string: [perl #119083]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=119083
masak r: sub circumfix:is not($x) { $x }; say is 42 not; say alive
camelia rakudo 45e8c4: OUTPUT«42alive»
masak w... wow.
masak r: sub infix:is not($l, $r) { $l !== $r }; say 5 isnot 42
camelia rakudo 45e8c4: OUTPUT«===SORRY!===Two terms in a row [...]
masak apparently, arbitrary whitespace doesn't work too well.
FROGGS r: sub infix:is not($l, $r) { $l !== $r }; say 5 is not 42
# looks like it must match exactly
camelia rakudo 45e8c4: OUTPUT«===SORRY!===Two terms in a row [...]
GlitchMr Actually, that's strange.
GlitchMr Last time I've done that, it worked.
GlitchMr But perhaps it's because I checked it with Niecza
FROGGS I believe it splits the name by space when declaring it, and
joins it later by one when using it
GlitchMr I know I once implemented not in operator in Perl 6, and
it worked, even as '$elem not in @array'
masak there's a possible rakudobug in here, methinks.
masak what *should* be the expected behavior?
GlitchMr std: sub infix:is not($l, $r) { $l !== $r }; say 5 is
not 42
camelia std c2215f0: OUTPUT«ok 00:00 48m»
GlitchMr STD finds it fine
* masak submits rakudobug
[perl #119053] [BUG] a rule doesn't match whitespace after a '^' anchor with whitespace after it in Rakudo
# New Ticket Created by Carl Mäsak
# Please include the string: [perl #119053]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=119053
masak r: grammar G { rule TOP { ^ foo }; rule foo { foo } }; say
?G.parse( foo)
camelia rakudo 96776b: OUTPUT«False»
masak I was under the impression that the space between '^' and
'foo' would eat the space at the beginning of foo.
masak what am I missing?
moritz masak: I think there's a special case that leading
whitespaces in rules aren't counted as .ws
masak moritz: right, but this one isn't leading, it's after the '^'.
masak r: grammar G { rule TOP { ^ ? foo }; rule foo { foo } };
say ?G.parse( foo)
camelia rakudo 96776b: OUTPUT«False»
masak and putting more stuff in between doesn't help either...
masak if no-one has an explanation I'm going to file a rakudobug.
masak S03:330 has this to say:
masak Only whitespace sequences immediately following a
masak matching construct (atom, quantified atom, or assertion) are eligible.
masak but at least ? is an assertion, no?
moritz it is
moritz in the very least it's an atom :-)
masak heh.
* masak submits rakudobug
[perl #114692] [BUG] :i doesn't require whitespace after modifier
On Tue Oct 16 09:18:12 2012, jn...@jnthn.net wrote: On Sat Sep 01 00:30:49 2012, glitc...@myopera.com wrote: This code works when it shouldn't. It happens on Rakudo 2012.08-27-gf3d2b53. print so 'abc' ~~ /:iabc/ Fixed: $ perl6 -e say 'ABC' ~~ /:iabc/ ===SORRY!=== Unrecognized regex modifier :iabc at line 2, near / Tagging testneeded. /jnthn Added test to S05-modifier/ignorecase.t -- Will Coke Coleda
[perl #114692] [BUG] :i doesn't require whitespace after modifier
# New Ticket Created by GlitchMr # Please include the string: [perl #114692] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=114692 This code works when it shouldn't. It happens on Rakudo 2012.08-27-gf3d2b53. print so 'abc' ~~ /:iabc/
Re: [perl #114692] [BUG] :i doesn't require whitespace after modifier
unsubscribe On Sat, Sep 1, 2012 at 3:30 AM, GlitchMr perl6-bugs-follo...@perl.orgwrote: # New Ticket Created by GlitchMr # Please include the string: [perl #114692] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=114692 This code works when it shouldn't. It happens on Rakudo 2012.08-27-gf3d2b53. print so 'abc' ~~ /:iabc/
[perl #113808] Bug report: whitespace in grammars
# New Ticket Created by Sir Robert Burbridge # Please include the string: [perl #113808] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=113808 Bug report. The snippet below (and associated github gist) says it all. -Sir 20:07 sirrobert I'm learning to write grammars, but having a wierd problem. (I think there's something I don't get about newlines or something). 20:07 sirrobert https://gist.github.com/2980628 20:08 pmichaud \s* doesn't really make sense in a rule 20:08 sirrobert ok... 20:08 pmichaud since whitespaces in the rule already implies \s* 20:08 sirrobert I can't get it to ignore the first part of a slurped file 20:08 pmichaud inside of method verb($/), you might want 'eq' instead of '==' 20:09 sirrobert oh, yeah 20:10 sirrobert Still, adding a blank line at the top of the file breaks it 20:10 sirrobert even with the \s* removed 20:10 pmichaud looking 20:11 sirrobert (cleaned up the gist by replacing == with 'eq' and removed the \s* in all places. Same problem) 20:13 pmichaud ah, it's the ^ that's an issue. 20:14 pmichaud it's somewhat of a rakudobug; the whitespace before the ^ is eating up the newline before testing for start of string, and with 'rule' there's no backtracking. 20:14 sirrobert ok! 20:14 pmichaud I think a recentish spec change causes leading whitespace before a ^ to be ignored... but rakudo doesn't implement that. 20:14 sirrobert glad it's not me =) 20:14 pmichaud so, eliminate the space before the ^ and maybe it will work. 20:14 pmichaud or, switch TOP to be a 'token' instead of a 'rule' 20:15 sirrobert ok, great.
[perl #75710] [BUG] Whitespace trouble involving a sub whose name begins with 'x' in Rakudo
On Sun Jun 13 10:07:20 2010, masak wrote:
pmichaud okay, someone review what I'm doing and please tell me I'm
missing something obvious... http://paste.lisp.org/+2DYG
pmichaud@orange:~/rakudo$ cat x
our sub xyz($abc) { say $abc.WHAT; }
xyz(1);
pmichaud@orange:~/rakudo$ ./perl6 x
===SORRY!===
Confused at line 2, near our sub xy
pmichaud@orange:~/rakudo$
pmichaud oh, I found a bug for masak!
masak pmichaud: that one should definitely not error out.
pmichaud if I change the name of the sub to something else it works.
pmichaud apparently it doesn't like 'xyz'
moritz_ is there a quote form beginning with x?
moritz_ rakudo: Quox
p6eval rakudo ecacff: OUTPUT«===SORRY!===Confused at line 11, near
Quox»
moritz_ same error
masak rakudo: our sub xyz($abc) { say $abc.WHAT; }; xyz(1); say
alive
p6eval rakudo ecacff: OUTPUT«Int()alive»
masak pmichaud: it only manifests in a file?
pmichaud it's also fine if there's a semicolon after the block
masak oh.
pmichaud I'm guessing it's being confused by operator x
masak rakudo: our sub xyz($abc) { say $abc.WHAT; } xyz(1); say
alive
p6eval rakudo ecacff: OUTPUT«===SORRY!===Confused at line 11, near
our sub xy»
* masak submits rakudobug
pmichaud it's parsing as infix:x
pmichaud what does STD.pm have to say about it, I wonder?
moritz_ rakudo: our sub xyz($x) { say $x }xyz 3
p6eval rakudo ecacff: OUTPUT«===SORRY!===Confused at line 11, near
our sub xy»
moritz_ std: our sub xyz($x) { say $x }xyz 3
p6eval std 31238: OUTPUT«ok 00:01 109m»
pmichaud rakudo: our sub xyz($x) { say $x }xyz 3
p6eval rakudo ecacff: OUTPUT«===SORRY!===Confused at line 11, near
our sub xy»
pmichaud rakudo: our sub xyz($x) { say $x }+ xyz 3
p6eval rakudo ecacff: OUTPUT«3Method 'Num' not found for invocant
of class 'Perl6Sub' [...]
masak pmichaud: what's that last evaluation?
masak pmichaud: where does Perl6Sub enter into it?
pmichaud masak: the + is acting like an infix:+
pmichaud where it ought to be a prefix:+
masak due to the same whitespace bug?
pmichaud yes
pmichaud I'm going to need to run STD on it to see how STD handles
it
masak so this all goes into the same ticket?
pmichaud it's the same problem, just demonstrating that the problem
is not strictly a ltm issue
pmichaud anyway, I want to make sure that STD doesn't see that 'x'
as infix:x
pmichaud (and then I'll figure out _how_ STD does it :)
diakopter std: sub xyz ($abc) { say $abc.WHAT }x 3
p6eval std 31238: OUTPUT«[31m===[0mSORRY![31m===[0mUndeclared
routine: 'x' used at line 2Check failedFAILED 00:01 106m»
pmichaud right
pmichaud so there's something missing in rakudo's close-brace
handling logic again
pmichaud anyway, I'll figure it out later.
moritz_ shouldn't it see it as statement-ending because the next
thing is a newline?
pmichaud sure, but the expression parser keeps going anyway
pmichaud actually, I misstated that
pmichaud the close brace is indeed marking end of statement
pmichaud but the expression parser is ignoring the end-of-statement
condition
pmichaud the expression parser thinks aha, whitespace and an infix,
I know what to do!
pmichaud (because we're in the expression parser at the time this
gets parsed)
Rakudo seems to be fine with this now:
21:01 [Coke] rakudo: our sub xyz($abc) { say $abc.WHAT; } xyz(1); say
alive
21:01 +p6eval rakudo 38907e: OUTPUT«Int()alive»
21:01 [Coke] rakudo: our sub xyz($x) { say $x }xyz 3
21:01 +p6eval rakudo 38907e: OUTPUT«3»
$ cat foo
our sub xyz($abc) { say $abc.WHAT; }
xyz(1);
$ ./perl6 foo
Int()
Closable with tests.
--
Will Coke Coleda
[perl #66966] [BUG] Supposedly equivalent code doesn't work the same when formatted with different whitespace
On Thu Jun 25 12:53:52 2009, matt-w wrote:
As far as I'm aware, these should be, semantically, the same:
role R { }
class C {
method a { }
a := method { } but R;
}
and
role R {}; class C { method a { }; a := method { } but R; }
However, the first says:
rtype not set
in Main (src/gen_setting.pm:3225)
While the second remains silent.
I'm not sure I'm supposed to be mixing roles into methods, but as far
as I'm concerned they're objects, so why not? This particular
behaviour came to light trying to produce a test case for the 'rtype
not set' error to help figure out what that is (it comes from inside
the PAST compiler inside PCT, as far as I can tell, from one of two
methods in Compiler.pir, but I can't figure out any more than that).
These now both error the same way on rakudo:
$ ./perl6 a.p6
===SORRY!===
Cannot use bind operator with this LHS at line 4, near method {
$ ./perl6 b.p6
===SORRY!===
Cannot use bind operator with this LHS at line 1, near method {
--
Will Coke Coleda
[perl6/specs] f99866: fix podchecker whitespace warning
Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: f9986623480765aef85820e3f20fc5706ad3aa6c https://github.com/perl6/specs/commit/f9986623480765aef85820e3f20fc5706ad3aa6c Author: diakopter diakop...@gmail.com Date: 2011-09-15 (Thu, 15 Sep 2011) Changed paths: M S02-bits.pod Log Message: --- fix podchecker whitespace warning
[perl #89606] Whitespace in operators is not disallowed
# New Ticket Created by 卓明亮
# Please include the string: [perl #89606]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=89606
JimmyZ rakudo:sub postfix:!($a) { [*] 1..$a; }; say (*!)(5);
p6eval rakudo 8533c3: OUTPUT«120»
JimmyZ rakudo:sub postfix: ($a) { [*] 1..$a; }; say (* )(5); #is
this expected?
p6eval rakudo 8533c3: OUTPUT«120»
moritz no, I think whitespace in operators is disallowed
JimmyZ rakudo:sub postfix: ($a) { [*] 1..$a; }; say (* )(5); # SBC case
p6eval rakudo 8533c3: OUTPUT«120»
JimmyZ std:sub postfix: ($a) { [*] 1..$a; }; say (* )(5);
p6eval std 3468e14: OUTPUT«Use of uninitialized value $starter in
concatenation (.) or string at
/usr/local/share/perl/5.10.1/CursorBase.pm line 2754.Use of
uninitialized value $stopper in concatenation (.) or string at
/usr/local/share/perl/5.10.1/CursorBase.pm line 2754.Use of
uninitialized value
p6eval ..$starte…
JimmyZ std:sub postfix: ($a) { [*] 1..$a; }; say (* )(5); # SBC case
p6eval std 3468e14: OUTPUT«Use of uninitialized value $starter in
concatenation (.) or string at
/usr/local/share/perl/5.10.1/CursorBase.pm line 2754.Use of
uninitialized value $stopper in concatenation (.) or string at
/usr/local/share/perl/5.10.1/CursorBase.pm line 2754.Use of
uninitialized value
p6eval ..$starte…
--
在此祝你身体健康，事事顺心
卓明亮
[perl #89610] [BUG] Rakudo erroneously allows whitespace postfix operators
# New Ticket Created by Carl Mäsak
# Please include the string: [perl #89610]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=89610
JimmyZ rakudo:sub postfix: ($a) { [*] 1..$a; }; say (* )(5); #is
this expected?
p6eval rakudo 8533c3: OUTPUT«120»
moritz no, I think whitespace in operators is disallowed
JimmyZ rakudo:sub postfix: ($a) { [*] 1..$a; }; say (* )(5); # SBC case
p6eval rakudo 8533c3: OUTPUT«120»
masak JimmyZ++ # whitespace op bug
* masak submits rakudobug
masak rakudo: say (* )(5)
p6eval rakudo 8533c3: OUTPUT«invoke() not implemented in class
'Whatever' in main program body at line 22:/tmp/B33jnbC8fQ»
[perl #85506] [BUG] String interpolation doesn't handle '[' after whitespace after variable right in Rakudo
# New Ticket Created by Carl Mäsak # Please include the string: [perl #85506] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=85506 masak std: my $a = 42; say $a [file] [13:05] p6eval std 4608239: OUTPUT«ok 00:01 122m» masak rakudo: my $a = 42; say $a [file] p6eval rakudo bfdd78: OUTPUT«===SORRY!===Unable to parse infixish, couldn't find final ']' at line 22» * masak submits rakudobug Should of course interpolate $a but not the '[file]' after that.
[perl #80330] [BUG] Rakudo allows [+]@a without intervening whitespace, STD.pm6 doesn't
# New Ticket Created by Carl Mäsak # Please include the string: [perl #80330] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=80330 jnthn rakudo: my @a; [...@a p6eval rakudo : ( no output ) jnthn rakudo: my @a; [+] @a p6eval rakudo : ( no output ) jnthn std: my @a; [...@a p6eval std a194beb: OUTPUT«[31m===[0mSORRY![31m===[0mTwo terms in a row [...] jnthn ETOOLIBERAL jnthn oh masak... :) * masak submits rakudobug
[perl #78202] [BUG] Rakudo treats ' #' after interpolated variable as whitespace (whereas STD.pm6 doesn't)
# New Ticket Created by Carl Mäsak
# Please include the string: [perl #78202]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=78202
masak rakudo: sub Good ($time) { say Good $time #perl6. }; Good
now # discovered by tylercurtis
p6eval rakudo 7c74c0: OUTPUT«===SORRY!===Unable to parse blockoid,
couldn't find final '}' at line 22»
masak std: sub Good ($time) { say Good $time #perl6. }; Good now
p6eval std 237d266: OUTPUT«ok 00:01 119m»
* masak submits rakudobug
masak I know what this is. it's the whitespace thingy inside the
interpolator being too greedy/needy.
masak STD seems to get this right.
masak in Rakudo, the interpolator finds the ' #', thinks the rest of
the line is a comment, and then dies.
masak we've had other similar cases of Rakudo doing run-on interpolation.
[perl #75710] [BUG] Whitespace trouble involving a sub whose name begins with 'x' in Rakudo
# New Ticket Created by Carl Mäsak
# Please include the string: [perl #75710]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=75710
pmichaud okay, someone review what I'm doing and please tell me I'm
missing something obvious... http://paste.lisp.org/+2DYG
pmich...@orange:~/rakudo$ cat x
our sub xyz($abc) { say $abc.WHAT; }
xyz(1);
pmich...@orange:~/rakudo$ ./perl6 x
===SORRY!===
Confused at line 2, near our sub xy
pmich...@orange:~/rakudo$
pmichaud oh, I found a bug for masak!
masak pmichaud: that one should definitely not error out.
pmichaud if I change the name of the sub to something else it works.
pmichaud apparently it doesn't like 'xyz'
moritz_ is there a quote form beginning with x?
moritz_ rakudo: Quox
p6eval rakudo ecacff: OUTPUT«===SORRY!===Confused at line 11, near Quox»
moritz_ same error
masak rakudo: our sub xyz($abc) { say $abc.WHAT; }; xyz(1); say alive
p6eval rakudo ecacff: OUTPUT«Int()alive»
masak pmichaud: it only manifests in a file?
pmichaud it's also fine if there's a semicolon after the block
masak oh.
pmichaud I'm guessing it's being confused by operator x
masak rakudo: our sub xyz($abc) { say $abc.WHAT; } xyz(1); say alive
p6eval rakudo ecacff: OUTPUT«===SORRY!===Confused at line 11, near
our sub xy»
* masak submits rakudobug
pmichaud it's parsing as infix:x
pmichaud what does STD.pm have to say about it, I wonder?
moritz_ rakudo: our sub xyz($x) { say $x }xyz 3
p6eval rakudo ecacff: OUTPUT«===SORRY!===Confused at line 11, near
our sub xy»
moritz_ std: our sub xyz($x) { say $x }xyz 3
p6eval std 31238: OUTPUT«ok 00:01 109m»
pmichaud rakudo: our sub xyz($x) { say $x }xyz 3
p6eval rakudo ecacff: OUTPUT«===SORRY!===Confused at line 11, near
our sub xy»
pmichaud rakudo: our sub xyz($x) { say $x }+ xyz 3
p6eval rakudo ecacff: OUTPUT«3Method 'Num' not found for invocant
of class 'Perl6Sub' [...]
masak pmichaud: what's that last evaluation?
masak pmichaud: where does Perl6Sub enter into it?
pmichaud masak: the + is acting like an infix:+
pmichaud where it ought to be a prefix:+
masak due to the same whitespace bug?
pmichaud yes
pmichaud I'm going to need to run STD on it to see how STD handles it
masak so this all goes into the same ticket?
pmichaud it's the same problem, just demonstrating that the problem
is not strictly a ltm issue
pmichaud anyway, I want to make sure that STD doesn't see that 'x'
as infix:x
pmichaud (and then I'll figure out _how_ STD does it :)
diakopter std: sub xyz ($abc) { say $abc.WHAT }x 3
p6eval std 31238: OUTPUT«[31m===[0mSORRY![31m===[0mUndeclared
routine: 'x' used at line 2Check failedFAILED 00:01 106m»
pmichaud right
pmichaud so there's something missing in rakudo's close-brace
handling logic again
pmichaud anyway, I'll figure it out later.
moritz_ shouldn't it see it as statement-ending because the next
thing is a newline?
pmichaud sure, but the expression parser keeps going anyway
pmichaud actually, I misstated that
pmichaud the close brace is indeed marking end of statement
pmichaud but the expression parser is ignoring the end-of-statement condition
pmichaud the expression parser thinks aha, whitespace and an infix,
I know what to do!
pmichaud (because we're in the expression parser at the time this gets parsed)
Re: [perl #75668] [BUG] whitespace before ^ in rule
I think whitespace before a leading/trailing ^/$ needs to be discounted. Dwimmery and elegance demand. +1
Re: [perl #75668] [BUG] whitespace before ^ in rule
On Fri, Jun 11, 2010 at 02:16:28PM -0700, Moritz Lenz via RT wrote:
On Thu Jun 10 21:11:42 2010, rir...@comcast.net wrote:
I think it is a bug that these differ
rule TOP { ^ tok }
rule TOP {^ tok }
It actually conforms the current spec. Each consecutive run of
whitespace is replaced by a call to .ws. So the first rule is
equivalent to
token TOP { .ws ^ .ws tok .ws }
When there is leading whitespace in the string, the first .ws matches,
and ^ fails. Since there's no backtracking in a token, the match fails.
I agree that that it's not obvious or intuitive, but rakudo should only
special-case it if the spec says so.
Thanks for the reply, I'll be slower to submit bugs.
I get your point. I think the spec may be open to other interpretations
though:
^ and $ now always match the start/end of a string,
How can even a zero-width atom ever match before the start of a string?
What are we matching against?
I think whitespace before a leading/trailing ^/$ needs to be discounted.
Dwimmery and elegance demand.
It is foul if the formalization of matching leads us to
rule TOP {
: my $dog = Magic;
^ matchme
}
needing to be
rule TOP {
: my $dog = Magic;^
matchme
}
Either way, the spec needs to be clarified.
Moritz, I appreciate the time you have taken with me. I'm more or less
at 5.005 regarding regexes, so some of the Perl5 refs in the synopses are
not so helpful to me. I'm am excited by grammars; they change
the mentation of matching.
On Perlmonks, I have found your answers satisfying but was disappointed
that we seem to be a party of two (at least there is an audience). I feel
that I could wear you out with my questions. I like Perlmonks, but could
move to another site.
Be well,
rir
Re: [perl #75668] [BUG] whitespace before ^ in rule
... On Perlmonks, I have found your answers satisfying but was disappointed that we seem to be a party of two (at least there is an audience). I feel that I could wear you out with my questions. I like Perlmonks, but could move to another site. A good thing about perlmonks is that your audience is likely to grow, and those posts will be referenced by future perl6-ers.
[perl #75668] [BUG] whitespace before ^ in rule
# New Ticket Created by rir...@comcast.net
# Please include the string: [perl #75668]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=75668
In
commit a5467733bdab87210a4eae6d3af309a0c3041c87
I think it is a bug that these differ
rule TOP { ^ tok }
rule TOP {^ tok }
If I'm far from right, let me know so I
won't waste folks time.
Thank you for rakudo.
Be well,
rir
[perl #73772] [BUG] Rakudo returns the wrong thing from a quote with only whitespace in it
Now fixed in 841262f. Assigning to moritz++ for test verification to close ticket. Pm
[perl #73804] whitespace between expression and block
# New Ticket Created by Steven Albano
# Please include the string: [perl #73804]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=73804
Hello, I was trying out some example code (release #27) when I stumbled upon
what appears to be a parsing bug where white-space is incorrectly required
between the expression and the block in an if statement.
I checked the bug tracker, and failed to find anything, so I checked the
grammar. In the grammar, there is a .ws between the expression and the
block.
I could be misunderstanding, as I am just getting used to perl6, and I could
have missed an existing low priority bug since it is fairly obvious. If that
is the case, please consider this to be fan mail. You folks are doing cool
stuff.
Steven Albano
my @b= 5, 1, 2;
if(@b2) {say 'yes';} # works
if(@b2){say 'yes';} # fails
[perl #73772] [BUG] Rakudo returns the wrong thing from a quote with only whitespace in it
# New Ticket Created by Carl Mäsak # Please include the string: [perl #73772] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=73772 TimToady rakudo: say .elems p6eval rakudo db0f85: OUTPUT«Method 'elems' not found for invocant of class 'Perl6Str' [...] TimToady hmm moritz_ rakudo: say .perl p6eval rakudo db0f85: OUTPUT«» * masak submits rakudobug TimToady looks to me like rakudo is making an unwarranted assumption there ...the unwarranted assumption being, IIUC, that the thing returned should be Nil, not the empty string.
[perl #70606] [BUG] Null PMC access on a regex with a final infix:| followed by whitespace in Rakudo
# New Ticket Created by Carl Mäsak
# Please include the string: [perl #70606]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=70606
masak rakudo: b ~~ /b| /
p6eval rakudo 7347ec: Null PMC access in find_method('reduce') [...]
* masak cackles
* masak submits rakudobug
diakopter u win for now ..
masak I sure do!
jnthn ng won't give a NPMCA on that.
jnthn ;-)
moritz_ right, a parse error
jnthn moritz_: shhh! :-P
moritz_ ng: b ~~ /b| /
p6eval ng b893c8: Confused at line 1, near \b\ ~~ /b| [...]
masak hah!
masak LTA.
TimToady std: b ~~ /b| /
p6eval std 29113: ===SORRY!===Null pattern not allowed [...]
masak STD++
[perl #66966] [BUG] Supposedly equivalent code doesn't work the same when formatted with different whitespace
# New Ticket Created by Matthew Walton
# Please include the string: [perl #66966]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=66966
As far as I'm aware, these should be, semantically, the same:
role R { }
class C {
method a { }
a := method { } but R;
}
and
role R {}; class C { method a { }; a := method { } but R; }
However, the first says:
rtype not set
in Main (src/gen_setting.pm:3225)
While the second remains silent.
I'm not sure I'm supposed to be mixing roles into methods, but as far
as I'm concerned they're objects, so why not? This particular
behaviour came to light trying to produce a test case for the 'rtype
not set' error to help figure out what that is (it comes from inside
the PAST compiler inside PCT, as far as I can tell, from one of two
methods in Compiler.pir, but I can't figure out any more than that).
Re: Whitespace in \c[...], \x[...], etc.
On Mon, Apr 27, 2009 at 11:04:03AM +0200, Helmut Wollmersdorfer wrote: It's not explicitly specified, if insignificant whitespace is allowed in \c[...], \x[...], etc. Std.pm allows e.g. \x[ 41 , 42 , 43 ] For convenience - especially with long charnames - it should be possible to write \c[ SPACE, # blafasel LATIN SMALL LETTER A, # some comment COMBINING DOT BELOW, # thisandthat ] Does anyone know offhand whether the Unicode Consortium has an explicit policy against use of punctuation in a charname? So far they only seem to use hyphen and parens, but I wonder to what extent we can depend on that... In any case, STD doesn't currently try to check the string in \c[...] for correctness. It just scans for the closing bracket. We will certainly need to refine this, and the suggested approach is certainly a possible outcome, if we decide it's sufficiently unambiguous. Larry
Re: Whitespace in \c[...], \x[...], etc.
On Tue, Apr 28, 2009 at 10:22 AM, Larry Wall la...@wall.org wrote: Does anyone know offhand whether the Unicode Consortium has an explicit policy against use of punctuation in a charname? So far they only seem to use hyphen and parens, but I wonder to what extent we can depend on that... According to the 5.0.0 standard, section 4.8: Unicode character names contain only uppercase Latin letters A through Z, digits, space, and hyphen-minus. So it seems the notes in parentheses are not considered part of the char name. -- Mark J. Reed markjr...@gmail.com
Re: Whitespace in \c[...], \x[...], etc.
On Tue, Apr 28, 2009 at 01:28:40PM -0400, Mark J. Reed wrote:
On Tue, Apr 28, 2009 at 10:22 AM, Larry Wall la...@wall.org wrote:
Does anyone know offhand whether the Unicode Consortium has an explicit
policy against use of punctuation in a charname? So far they only
seem to use hyphen and parens, but I wonder to what extent we can
depend on that...
According to the 5.0.0 standard, section 4.8:
Unicode character names contain only uppercase Latin letters A
through Z, digits, space, and hyphen-minus.
So it seems the notes in parentheses are not considered part of the char name.
Countering this, though:
* The XML schema for the Unicode Character Database in XML [1]
seems to allow parens in the character name property:
character-name = xsd:string { pattern=([A-Z0-9 #\-\(\)]*)|(control) }
* The Unicode character name database [2] has parens in the
name property field for many characters
000A;control;Cc;0;B;N;LINE FEED (LF)
* ICU doesn't seem to recognize the versions of the name without
the parens (or if it does, I haven't been able to figure out the
correct incantations to make it do so).
Of course, it's very possible that I'm misreading the Unicode
specifications, and the note that Mark cites would seem to be
very explicit. But thus far in playing with this I've seen
more indications that the parens are allowed or even required
than I've seen that indicate they're excluded.
Pm
[1] http://www.unicode.org/reports/tr42/tr42-3.html#N66310
[2] http://unicode.org/Public/UNIDATA/UnicodeData.txt
Re: Whitespace in \c[...], \x[...], etc.
On Tue, Apr 28, 2009 at 07:22:18AM -0700, Larry Wall wrote: On Mon, Apr 27, 2009 at 11:04:03AM +0200, Helmut Wollmersdorfer wrote: Std.pm allows e.g. \x[ 41 , 42 , 43 ] For convenience - especially with long charnames - it should be possible to write \c[ SPACE, # blafasel LATIN SMALL LETTER A, # some comment COMBINING DOT BELOW, # thisandthat ] In any case, STD doesn't currently try to check the string in \c[...] for correctness. It just scans for the closing bracket. We will certainly need to refine this, and the suggested approach is certainly a possible outcome, if we decide it's sufficiently unambiguous. FWIW, Rakudo and PGE now allow spaces inside the brackets, although they don't understand the # ... comments yet. Pm
Re: Whitespace in \c[...], \x[...], etc.
On Tue, Apr 28, 2009 at 2:27 PM, Patrick R. Michaud pmich...@pobox.com wrote:
According to the 5.0.0 standard, section 4.8:
Unicode character names contain only uppercase Latin letters A
through Z, digits, space, and hyphen-minus.
So it seems the notes in parentheses are not considered part of the char
name.
Countering this, though:
* The XML schema for the Unicode Character Database in XML [1]
seems to allow parens in the character name property:
character-name = xsd:string { pattern=([A-Z0-9 #\-\(\)]*)|(control) }
Also '#', though I see no character names containing that symbol.
But all the parentheses I see in the list of character names are
surrounding lowercase letters, which are explicitly disallowed not
only in the spec I quoted, but in the XML scheme definition you quote
above. e.g.
00C6 LATIN CAPITAL LETTER AE (ash)
* The Unicode character name database [2] has parens in the
name property field for many characters
000A;control;Cc;0;B;N;LINE FEED (LF)
That's not the name property field. The Unicode character name is
field 1 (control, in this case). The field whose value is LINE
FEED (LF) is the Unicode_1_Name field, wihch for control characters
supplies the ISO 6429 name.
--
Mark J. Reed markjr...@gmail.com
Re: Whitespace in \c[...], \x[...], etc.
On Tue, Apr 28, 2009 at 03:08:05PM -0400, Mark J. Reed wrote: On Tue, Apr 28, 2009 at 2:27 PM, Patrick R. Michaud pmich...@pobox.com wrote: * The Unicode character name database [2] has parens in the name property field for many characters 000A;control;Cc;0;B;N;LINE FEED (LF) That's not the name property field. The Unicode character name is field 1 (control, in this case). The field whose value is LINE FEED (LF) is the Unicode_1_Name field, wihch for control characters supplies the ISO 6429 name. Ah, thanks for the excellent clarification. Returning to the original question: Would this then mean that we don't provide a way to specify U+000A and other control characters using a name inside of \c[...]? Or (more likely) does it mean that the names we accept inside of the \c[...] are more than just the strict Unicode character names listed above--i.e., the Unicode_1_Name field and other related aliases (whatever those might be)? Pm
Whitespace in \c[...], \x[...], etc.
It's not explicitly specified, if insignificant whitespace is allowed in \c[...], \x[...], etc. Std.pm allows e.g. \x[ 41 , 42 , 43 ] For convenience - especially with long charnames - it should be possible to write \c[ SPACE, # blafasel LATIN SMALL LETTER A, # some comment COMBINING DOT BELOW, # thisandthat ] Helmut Wollmersdorfer
[perl #61914] [BUG] Declarator Parser Failure if Whitespace after Opening Paren
On Fri Jan 02 12:06:57 2009, publiustemp-perl6compil...@yahoo.com wrote:
However, any whitespace after the opening paren causes a parse
failure:
class Foo {
has ($.this,
$.that,
);
}
my Foo $foo .= new( this = 3, that = 4 );
say $foo.this;
Unable to parse declarator; couldn't find final ')' at line 4, near
$.this, \n
Now working as of r35397:
$ cat x
class Foo {
has ( $.this,
$.that,
);
}
my Foo $foo .= new( this = 3, that = 4);
say $foo.this;
$ ./parrot perl6.pbc x
3
$
Assigning ticket to moritz so we can make sure there's a regression
spectest for this. Thanks!
Pm
[perl #61914] [BUG] Declarator Parser Failure if Whitespace after Opening Paren
# New Ticket Created by publiustemp-perl6compil...@yahoo.com
# Please include the string: [perl #61914]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=61914
This works fine:
class Foo {
has ($.this,
$.that,
);
}
my Foo $foo .= new( this = 3, that = 4 );
say $foo.this;
However, any whitespace after the opening paren causes a parse failure:
class Foo {
has ($.this,
$.that,
);
}
my Foo $foo .= new( this = 3, that = 4 );
say $foo.this;
Unable to parse declarator; couldn't find final ')' at line 4, near $.this, \n
current instr.: 'parrot;PGE;Util;die' pc 129
(runtime/parrot/library/PGE/Util.pir:83)
called from Sub 'parrot;Perl6;Grammar;declarator' pc 81845
(src/gen_grammar.pir:23527)
called from Sub 'parrot;Perl6;Grammar;scoped' pc 82534
(src/gen_grammar.pir:23780)
called from Sub 'parrot;Perl6;Grammar;scope_declarator' pc 83560
(src/gen_grammar.pir:24183)
called from Sub 'parrot;Perl6;Grammar;noun' pc 70435 (src/gen_grammar.pir:19268)
called from Sub 'parrot;Perl6;Grammar;expect_term' pc 65600
(src/gen_grammar.pir:17435)
called from Sub 'parrot;PGE;OPTable;parse' pc 1988
(compilers/pge/PGE/OPTable.pir:566)
called from Sub 'parrot;Perl6;Grammar;statement' pc 29622
(src/gen_grammar.pir:3674)
called from Sub 'parrot;Perl6;Grammar;statementlist' pc 27358
(src/gen_grammar.pir:2799)
called from Sub 'parrot;Perl6;Grammar;statement_block' pc 24895
(src/gen_grammar.pir:1841)
called from Sub 'parrot;Perl6;Grammar;block' pc 26388 (src/gen_grammar.pir:2419)
called from Sub 'parrot;Perl6;Grammar;package_block' pc 79263
(src/gen_grammar.pir:22572)
called from Sub 'parrot;Perl6;Grammar;package_def' pc 77242
(src/gen_grammar.pir:21820)
called from Sub 'parrot;Perl6;Grammar;package_declarator' pc 75576
(src/gen_grammar.pir:21207)
called from Sub 'parrot;Perl6;Grammar;noun' pc 70330 (src/gen_grammar.pir:19233)
called from Sub 'parrot;Perl6;Grammar;expect_term' pc 65600
(src/gen_grammar.pir:17435)
called from Sub 'parrot;PGE;OPTable;parse' pc 1988
(compilers/pge/PGE/OPTable.pir:566)
called from Sub 'parrot;Perl6;Grammar;statement' pc 29622
(src/gen_grammar.pir:3674)
called from Sub 'parrot;Perl6;Grammar;statementlist' pc 27358
(src/gen_grammar.pir:2799)
called from Sub 'parrot;Perl6;Grammar;statement_block' pc 24895
(src/gen_grammaruse v6;
This is r34828
$ uname -a
Darwin curtis-poes-computer-3.local 9.5.1 Darwin Kernel Version 9.5.1: Fri Sep
19 16:19:24 PDT 2008; root:xnu-1228.8.30~1/RELEASE_I386 i386
Cheers,
Ovid
--
Buy the book - http://www.oreilly.com/catalog/perlhks/
Tech blog- http://use.perl.org/~Ovid/journal/
Twitter - http://twitter.com/OvidPerl
Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
[perl #54610] [PATCH] for 'no trailing whitespace' test
# New Ticket Created by Ifejinelo Onyiah # Please include the string: [perl #54610] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=54610 The purpose of this patch is to allow parrot pass the no trailing whitespace test at t/codingstd/trailing_space.t line 50. Just deleted the empty lines following done_to: and do_sort: in languages/perl6/src/classes/List.pir. N: Nelo Onyiah E: [EMAIL PROTECTED] D: Get parrot to pass the 'no trailing whitespace' test at t/codingstd/trailing_space.t line 50 Index: languages/perl6/src/classes/List.pir === --- languages/perl6/src/classes/List.pir (revision 27726) +++ languages/perl6/src/classes/List.pir (working copy) @@ -660,13 +660,11 @@ goto copy_to done_to: - # Check comparer if have_comparer goto do_sort get_hll_global comparer, 'infix:cmp' do_sort: - # Sort in-place arr.'sort'(comparer)
[perl #54610] [PATCH] for 'no trailing whitespace' test
Thanks. Applied as r27734. kid51
[perl #51880] [PATCH] Remove trailing whitespace in languages/tcl/runtime/conversions.pir
# New Ticket Created by Matt Kraai # Please include the string: [perl #51880] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=51880 Howdy, t/codingstd/trailing_space.t fails because languages/tcl/runtime/conversions.pir contains trailing whitespace. The attached patch removes it. -- Matt diff --git a/languages/tcl/runtime/conversions.pir b/languages/tcl/runtime/conversions.pir index 7d7b0ea..82c91b8 100644 --- a/languages/tcl/runtime/conversions.pir +++ b/languages/tcl/runtime/conversions.pir @@ -366,7 +366,7 @@ Given an expression, return a subroutine, or optionally, the raw PIR tcl_error $S0 empty: -tcl_error empty expression\nin expression \\ +tcl_error empty expression\nin expression \\ .end =head2 _Tcl::__script
[perl #51880] [PATCH] Remove trailing whitespace in languages/tcl/runtime/conversions.pir
On Tue Mar 18 22:34:56 2008, kraai wrote: Howdy, t/codingstd/trailing_space.t fails because languages/tcl/runtime/conversions.pir contains trailing whitespace. The attached patch removes it. Thanks, applied in r26492.
Re: Indirect objects, adverbial arguments and whitespace
Markus Laker schreef: If I've got this right: mangle $foo :a;# mangle($foo, a = 1); mangle $foo: a;# $foo.mangle(a()); So these -- mangle $foo:a; mangle $foo : a; are ambiguous and, as far as I can tell from the synopses, undefined. So what's the rule: that indirect-object colon needs whitespace after but not before, and adverbial colon needs whitespace before but not after? The reason I ask is that I'm knocking up an intro to Perl 6 for C and C++ programmers. I expect some of Perl 6's whitespace rules to trip up people used to C++ (as they have me, in my clumsy attempts with Pugs), and I'd like to summarise all the whitespace dwimmery in one place. We were making fun of this: news:[EMAIL PROTECTED] -- Affijn, Ruud Gewoon is een tijger.
Indirect objects, adverbial arguments and whitespace
If I've got this right: mangle $foo :a;# mangle($foo, a = 1); mangle $foo: a;# $foo.mangle(a()); So these -- mangle $foo:a; mangle $foo : a; are ambiguous and, as far as I can tell from the synopses, undefined. So what's the rule: that indirect-object colon needs whitespace after but not before, and adverbial colon needs whitespace before but not after? The reason I ask is that I'm knocking up an intro to Perl 6 for C and C++ programmers. I expect some of Perl 6's whitespace rules to trip up people used to C++ (as they have me, in my clumsy attempts with Pugs), and I'd like to summarise all the whitespace dwimmery in one place. Many thanks, Markus
Re: Indirect objects, adverbial arguments and whitespace
Visually, I interpret :a as a token unto itself, though that's probably Ruby's fault. That interpretation would man that the dual-whitespace version would have to be an indirect object. I would argue for disallowing the all-jammed-together case, lest we run into longest-match arguments where foobar:baz is foobar: baz but foo:barbaz is foo :barbaz. Yuck. On 7 Oct 2007 12:22:56 -, Markus Laker [EMAIL PROTECTED] wrote: If I've got this right: mangle $foo :a;# mangle($foo, a = 1); mangle $foo: a;# $foo.mangle(a()); So these -- mangle $foo:a; mangle $foo : a; are ambiguous and, as far as I can tell from the synopses, undefined. So what's the rule: that indirect-object colon needs whitespace after but not before, and adverbial colon needs whitespace before but not after? The reason I ask is that I'm knocking up an intro to Perl 6 for C and C++ programmers. I expect some of Perl 6's whitespace rules to trip up people used to C++ (as they have me, in my clumsy attempts with Pugs), and I'd like to summarise all the whitespace dwimmery in one place. Many thanks, Markus -- Mark J. Reed [EMAIL PROTECTED]
Re: Indirect objects, adverbial arguments and whitespace
On 10/7/07, Mark J. Reed [EMAIL PROTECTED] wrote: I would argue for disallowing the all-jammed-together case, lest we run into longest-match arguments where foobar:baz is foobar: baz but foo:barbaz is foo :barbaz. Yuck. Uh, that doesn't make sense. Longest match arguments are leftmost, so if you consider the indirect object : to be part of the variable before it (I wouldn't), then you would always get the foobar: baz / foo: barbaz interpretation. I don't know about the all jammed together case, but mangle $foo : a is not ambiguous because : a is not a pair: there is no whitespace allowed between the colon and the name on that style of pair. Luke
[perl #42236] [PATCH] Codingstd/whitespace fixes (keyword one-space open-paren)
# New Ticket Created by Shawn M Moore
# Please include the string: [perl #42236]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=42236
Hi,
I'm bored, so I'm going through and fixing some failing tests in t/codingstd/
At the moment I'm working on c_parens.t. Here's one that fixes the
majority of the failures in the first third of the tests, which looks
that code matches the pattern
C-keyword exactly-one-space open-parenthesis
I only fixed the ones that were mostly obvious. How is sizeof supposed
to be treated? It's a keyword, yes, but most C code I've seen has no
space between the sizeof and (. So I didn't touch those failures. I
also didn't change things where spacing created a layout, such as in
typedef void(*push_number_f)(Parrot_Interp, IMAGE_IO*, FLOATVAL);
typedef INTVAL (*shift_integer_f) (Parrot_Interp, IMAGE_IO*);
I can try to write something to make the above case pass (look for a
parenthesis in the same column a line above or below), but that'll
come later.
make test obviously returned no new failures; prove
t/codingstd/c_paren.t had a reduction of 40 files to 33. A lot of
these failures are sizeof or layout related, honest!
Affected files (yay diffstat):
compilers/imcc/imc.h |2 -
compilers/imcc/imcc.y | 16 +++---
compilers/pirc/src/pirlexer.c | 34 ++---
compilers/pirc/src/pirparser.c | 30 +-
include/parrot/encoding.h |2 -
include/parrot/packfile.h |4 +--
include/parrot/smallobject.h |2 -
languages/cola/cola.y | 42 ++---
languages/lua/pmc/luastring.pmc|2 -
languages/pugs/pmc/pugscapture.pmc |2 -
languages/tcl/src/pmc/tcllist.pmc |2 -
src/inter_call.c |6 ++---
12 files changed, 72 insertions(+), 72 deletions(-)
Shawn M Moore
Index: src/inter_call.c
===
--- src/inter_call.c (revision 17872)
+++ src/inter_call.c (working copy)
@@ -754,7 +754,7 @@
/* verify that a name exists */
INTVAL sig = st-dest.sig = SIG_ITEM(st-dest.u.op.signature, i);
-if(sig PARROT_ARG_NAME)
+if (sig PARROT_ARG_NAME)
{
INTVAL arg_sig;
int last_name_pos;
@@ -772,7 +772,7 @@
/* if this named arg is already filled, continue*/
if (st-named_done (1 n_named)) {
arg_sig = st-dest.sig = SIG_ITEM(st-dest.u.op.signature, i+1);
-if(arg_sig PARROT_ARG_OPT_FLAG)
+if (arg_sig PARROT_ARG_OPT_FLAG)
i++; /* skip associated opt flag arg as well */
continue;
}
@@ -782,7 +782,7 @@
store_arg(st, idx);
arg_sig = st-dest.sig = SIG_ITEM(st-dest.u.op.signature, i+1);
-if(arg_sig PARROT_ARG_OPT_FLAG) {
+if (arg_sig PARROT_ARG_OPT_FLAG) {
i++;
idx = st-dest.u.op.pc[i];
CTX_REG_INT(st-dest.ctx, idx) = 0;
Index: include/parrot/smallobject.h
===
--- include/parrot/smallobject.h (revision 17872)
+++ include/parrot/smallobject.h (working copy)
@@ -18,7 +18,7 @@
struct Small_Object_Pool *, void *);
typedef void * (*get_free_object_fn_type)(Interp *,
struct Small_Object_Pool *);
-typedef void (*alloc_objects_fn_type)(Interp *,
+typedef void (*alloc_objects_fn_type)(Interp *,
struct Small_Object_Pool *);
#if PARROT_GC_GMS
Index: include/parrot/encoding.h
===
--- include/parrot/encoding.h (revision 17872)
+++ include/parrot/encoding.h (working copy)
@@ -34,7 +34,7 @@
struct string_iterator_t; /* s. parrot/string.h */
-typedef void(*encoding_iter_init_t)(Interp *, STRING *src,
+typedef void (*encoding_iter_init_t)(Interp *, STRING *src,
struct string_iterator_t *);
struct _encoding {
Index: include/parrot/packfile.h
===
--- include/parrot/packfile.h (revision 17872)
+++ include/parrot/packfile.h (working copy)
@@ -56,7 +56,7 @@
typedef struct PackFile_Segment * (*PackFile_Segment_new_func_t)
(Interp *, struct PackFile *, const char *, int add);
-typedef void (*PackFile_Segment_destroy_func_t) (Interp *,
+typedef void (*PackFile_Segment_destroy_func_t) (Interp *,
struct PackFile_Segment *);
typedef size_t (*PackFile_Segment_packed_size_func_t)(Interp *,
struct PackFile_Segment *);
@@ -64,7 +64,7 @@
struct PackFile_Segment *, opcode_t *dest);
typedef opcode_t *
[perl #42236] [PATCH] Codingstd/whitespace fixes (keyword one-space open-paren)
On Fri Mar 30 23:36:45 2007, [EMAIL PROTECTED] wrote: Hi, I'm bored, so I'm going through and fixing some failing tests in t/codingstd/ At the moment I'm working on c_parens.t. Here's one that fixes the majority of the failures in the first third of the tests, which looks that code matches the pattern C-keyword exactly-one-space open-parenthesis I only fixed the ones that were mostly obvious. How is sizeof supposed to be treated? It's a keyword, yes, but most C code I've seen has no space between the sizeof and (. So I didn't touch those failures. I also didn't change things where spacing created a layout, such as in typedef void(*push_number_f)(Parrot_Interp, IMAGE_IO*, FLOATVAL); typedef INTVAL (*shift_integer_f) (Parrot_Interp, IMAGE_IO*); I can try to write something to make the above case pass (look for a parenthesis in the same column a line above or below), but that'll come later. make test obviously returned no new failures; prove t/codingstd/c_paren.t had a reduction of 40 files to 33. A lot of these failures are sizeof or layout related, honest! Affected files (yay diffstat): compilers/imcc/imc.h |2 - compilers/imcc/imcc.y | 16 +++--- compilers/pirc/src/pirlexer.c | 34 ++--- compilers/pirc/src/pirparser.c | 30 +- include/parrot/encoding.h |2 - include/parrot/packfile.h |4 +-- include/parrot/smallobject.h |2 - languages/cola/cola.y | 42 ++--- languages/lua/pmc/luastring.pmc|2 - languages/pugs/pmc/pugscapture.pmc |2 - languages/tcl/src/pmc/tcllist.pmc |2 - src/inter_call.c |6 ++--- 12 files changed, 72 insertions(+), 72 deletions(-) Shawn M Moore Thanks! It's great to have someone help out :-) Eventually all applied in r17893. Paul
[perl #40755] [TODO] Tcl - make 'splitchars' variable the default whitespace splitchars in runtime/builtin/split.pir
# New Ticket Created by Paul Cochrane # Please include the string: [perl #40755] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40755 In the file languages/tcl/runtime/builtin/split.pir, replace the splitchars variable with the default whitespace splitchars. This ticket is in response to cage task #39704.
Re: a smarter form of whitespace
Patrick R. Michaud wrote:
On Tue, Jul 04, 2006 at 12:57:16PM -0700, Allison Randal wrote:
--
token start { ^emptyline*$ }
regex emptyline { ^^ $$ \n }
token ws { [sp | \t]* }
--
The above grammar doesn't have a grammar statement; as a result
the regexes are being installed into the '' namespace.
The original did have a 'grammar' statement, I just didn't paste it into
the email.
$ cat xyz.pir
.sub main :main
load_bytecode 'PGE.pbc'
load_bytecode 'ar.pir'
load_bytecode 'dumper.pbc'
load_bytecode 'PGE/Dumper.pbc'
$P0 = find_global 'XYZ', 'start'
$P1 = $P0(\n\n\n\n\n\n\n, 'grammar' = 'XYZ')
What the original didn't have is the 'grammar' named argument when
calling the start rule. When I replace the previous line with:
$P1 = $P0(\n\n\n\n\n\n\n)
then your sample code exhibits the same problem. I assume this means
that the reason overriding ws wasn't working is because it was calling
the default version of ws in the root namespace. But, if it was
defaulting to the root namespace, why was it able to find any of the
rules? Shouldn't it have complained that it couldn't find emptyline?
Thanks,
Allison
Re: a smarter form of whitespace
On Tue, Jul 04, 2006 at 12:57:16PM -0700, Allison Randal wrote: I'm writing a parser for a language that treats a double newline as a statement terminator. It works if I make every rule a 'regex' (to turn off smart whitespace). But I want spaces and tabs to act as smart whitespace, and newlines to act as literal whitespace. I've overloaded ws to match only spaces and tabs, but the grammar still consumes newlines where it shouldn't consume newlines. For a simple repeatable example, take the following grammar: Overloading ws and other builtins was fixed in parrot and pugs approaching midnight (hackathon time) on 2006-06-29. If your parrot and pugs are both more recent than that, I'm not sure where the bug is. -kolibrie
Re: a smarter form of whitespace
On Thu, Jul 06, 2006 at 12:29:12AM -0700, Allison Randal wrote: $ cat xyz.pir .sub main :main load_bytecode 'PGE.pbc' load_bytecode 'ar.pir' load_bytecode 'dumper.pbc' load_bytecode 'PGE/Dumper.pbc' $P0 = find_global 'XYZ', 'start' $P1 = $P0(\n\n\n\n\n\n\n, 'grammar' = 'XYZ') What the original didn't have is the 'grammar' named argument when calling the start rule. When I replace the previous line with: $P1 = $P0(\n\n\n\n\n\n\n) then your sample code exhibits the same problem. I assume this means that the reason overriding ws wasn't working is because it was calling the default version of ws in the root namespace. But, if it was defaulting to the root namespace, why was it able to find any of the rules? Shouldn't it have complained that it couldn't find emptyline? At the moment (and this may be incorrect), PGE looks for named rules via inheritance, and if not found that way it looks in the available symbol tables using the find_name opcode. So, the match was able to find the rules because they are in the current namespace, but when it came time to find the rule for ?ws there was a ws method available (the default) and so that one was used. Again, this may not be the correct behavior; I've been using S12 as the guide here, in that a method call first considers methods from the class hierarchy and fails over to subroutine dispatch. Pm
Re: a smarter form of whitespace
Nathan Gray wrote: Overloading ws and other builtins was fixed in parrot and pugs approaching midnight (hackathon time) on 2006-06-29. If your parrot and pugs are both more recent than that, I'm not sure where the bug is. I have the latest checkout of Parrot (I'm not using Pugs). It may not be a bug. The design question is: should ws match a newline even when it's been overloaded to match only spaces and tabs? (I'm thinking No, but could be wrong.) Allison
Re: a smarter form of whitespace
On Tue, Jul 04, 2006 at 12:57:16PM -0700, Allison Randal wrote:
--
token start { ^emptyline*$ }
regex emptyline { ^^ $$ \n }
token ws { [sp | \t]* }
--
The above grammar doesn't have a grammar statement; as a result
the regexes are being installed into the '' namespace.
If I match this against a string of 7 newlines, it returns 7 emptyline
matches, and each match is a single newline. This is the behavior I want
for newlines.
I tried it with a grammar statement and it seems to work:
$ cat ar.pg
grammar XYZ;
token start { ^emptyline*$ }
rule emptyline { ^^ $$ \n }
token ws { [sp | \t]* }
$ ./parrot compilers/pge/pgc.pir ar.pg ar.pir
$ cat xyz.pir
.sub main :main
load_bytecode 'PGE.pbc'
load_bytecode 'ar.pir'
load_bytecode 'dumper.pbc'
load_bytecode 'PGE/Dumper.pbc'
$P0 = find_global 'XYZ', 'start'
$P1 = $P0(\n\n\n\n\n\n\n, 'grammar' = 'XYZ')
'_dumper'($P1)
.end
$ ./parrot xyz.pir
VAR1 = PMC 'XYZ' = \n\n\n\n\n\n\n @ 0 {
emptyline = ResizablePMCArray (size:7) [
PMC 'XYZ' = \n @ 0,
PMC 'XYZ' = \n @ 1,
PMC 'XYZ' = \n @ 2,
PMC 'XYZ' = \n @ 3,
PMC 'XYZ' = \n @ 4,
PMC 'XYZ' = \n @ 5,
PMC 'XYZ' = \n @ 6
]
}
$
-
Pm
a smarter form of whitespace
I'm writing a parser for a language that treats a double newline as a
statement terminator. It works if I make every rule a 'regex' (to turn
off smart whitespace). But I want spaces and tabs to act as smart
whitespace, and newlines to act as literal whitespace. I've
overloaded ws to match only spaces and tabs, but the grammar still
consumes newlines where it shouldn't consume newlines. For a simple
repeatable example, take the following grammar:
--
token start { ^emptyline*$ }
regex emptyline { ^^ $$ \n }
token ws { [sp | \t]* }
--
If I match this against a string of 7 newlines, it returns 7 emptyline
matches, and each match is a single newline. This is the behavior I want
for newlines.
I would like to add smart whitespace matching for spaces and tabs. But,
if I change emptyline to a 'rule' and match it against the same string
of 7 newlines, it returns a single emptyline match and the matched
string is 7 newlines. I've tried several variations on the ws rule,
but it seems to boil down to: no matter what the ws rule matches, if
:sigspace is on, it treats newlines as ignorable whitespace.
Is this a bug or a feature?
Thanks,
Allison
Re: [perl #37104] [PATCH] docs - spelling, markup and whitespace fixes
Joshua Hoblitt (via RT) [EMAIL PROTECTED] wrote: @@ -95,10 +97,17 @@ =head2 PMCs + .mine +PMC stands for Parrot Magic Cookie. PMCs represent any complex data structure +or type, including aggregate data types (arrays, hash tables, etc). A PMC can +implement its own behavior for arithmetic, logical and string operations +performed on it, allowing for language-specific behavior to be introduced. PMCs +=== PMC stands for Parrot Magic Cookie. PMCs represent any complex data structure or type, including aggregate data types (arrays, hash tables, etc). A PMC can implement its own behavior for arithmetic, logical and string operations performed on it, allowing for language-specific behavior to be introduced. PMCs + .r9142 can be built in to the Parrot executable or dynamically loaded when they are needed. HmmmI'm thinking these lines shouldn't be there:- + .mine + .r9142 ? Jonathan
Re: [perl #37104] [PATCH] docs - spelling, markup and whitespace fixes
Jonathan Worthington schrieb: Joshua Hoblitt (via RT) [EMAIL PROTECTED] wrote: HmmmI'm thinking these lines shouldn't be there:- + .mine + .r9142 Yes, sure. I must have missed an conflict when svn had to do some merging. The svn litter is removed in r9158. CU, Bernhard
Re: [PATCH] docs - spelling, markup and whitespace fixes
Joshua Hoblitt schrieb: I've tried submitting this patch to RT twice now without any success so I'm resorting to sending it directly to the mailing list. -J Hi, thanks a lot for your patch. I also think that the problem with RT were because of the size of the attachment. TNX, Bernhard
Re[2]: Whitespace
: so why not 'print($x)' == 'print ($x)' ;-) Plus we got rid of Perl-5's no-op unary +, so instead we're using whitespace to force it to be a list operator. Thanks! I've got the idea. I'd better refuse parenthesis than a space here. I think I'll never drop space in a function call if it can be overcome :-) -- ___ Andrew, [EMAIL PROTECTED] ___
Re: Whitespace
On Thu, Aug 04, 2005 at 09:29:21PM +0400, Andrew Shitov wrote: : in fact, that is exactly : : (print.getArgument(3) * 3); the same as above. : : so why not 'print($x)' == 'print ($x)' ;-) Because most people's expectations diverge from yours, actually, and we got tired of answering the FAQ. On top of which, we think it's probably easier to retrain you than the typical newbie. :-) Plus we got rid of Perl-5's no-op unary +, so instead we're using whitespace to force it to be a list operator. But the overriding reason is that we're trying to be consistent about using whitespace to distinguish postfix operators from binary operators or terms when it's ambiguous. We also consisently allow dot to force it the other way even in the presence of whitespace. If you were to add a ++ binary operator, it would be distinguished from postfix ++ by whitespace. But .++ would be the postfix anyway. Larry
Whitespace (Was: [RELEASE] Pugs 6.2.9 released!)
I am glad to announce Pugs 6.2.9, released during Ingy's OSCON talk:
http://pugscode.org/dist/Perl6-Pugs-6.2.9.tar.gz
SIZE = 1439642
SHA1 = efd32419dcddba596044a42564936888a28b3c69
Following last month's plan, this release features a Perl6/PIL to javascript
code generator, written in Perl 5, currently passing 64% of the test suite.
We also see the beginning of a code generator from PIL to perl5, and a
self-representing Perl 6 object model prototype. The new PIL design and
runcore is also progressing nicely, which should give a more robust
specification to Perl 6's compile time and runtime semantics.
A live CD is available as usual, courtesy of Ingo Blechschmidt:
http://linide.sf.net/pugs-livecd-6.2.9.iso
Ingy's slides are under the Pugs tree as
docs/talks/oscon-apocalypse.spork and
online at http://www.kwiki.org/apocalypse/start.html in HTML.
All in all, it's a lot of fun. Check out the two movies we made for the
OSCON talk as well:
http://no.perlcabal.org/~autrijus/oscon05-autrijus.mp4
http://no.perlcabal.org/~autrijus/oscon05-stevan.mp4
Change the .mp4 to .swf or .wmv for alternate video formats.
Very simple question:
why do we have to give up a space when calling functions under Pugs?
A need to type open('file.txt') instead of open ('file.txt') makes
me perplexing (not perl-flexing ;-) Our recent discussions in 'zip with()'
gave no answer.
--
___
Andrew, [EMAIL PROTECTED]
___
Re: Whitespace (Was: [RELEASE] Pugs 6.2.9 released!)
why do we have to give up a space when calling functions under Pugs?
A need to type open('file.txt') instead of open ('file.txt') makes
me perplexing (not perl-flexing ;-) Our recent discussions in 'zip with()'
gave no answer.
Not sure whether it's enough of an answer, but see:
http://dev.perl.org/perl6/doc/design/syn/S04.html#Statement_parsing
Cheers,
Carl
Re[2]: Whitespace (Was: [RELEASE] Pugs 6.2.9 released!)
why do we have to give up a space when calling functions under Pugs? Not sure whether it's enough of an answer, but see: http://dev.perl.org/perl6/doc/design/syn/S04.html#Statement_parsing it says: if $term ($x) # syntax error (two terms in a row) if this cause an error, why not treat '$term ($x)' as a function call. At least when $term is not some abstract variable but valid name of simple function. -- ___ Andrew, [EMAIL PROTECTED] ___
Re: Re[2]: Whitespace (Was: [RELEASE] Pugs 6.2.9 released!)
why do we have to give up a space when calling functions under Pugs? Not sure whether it's enough of an answer, but see: http://dev.perl.org/perl6/doc/design/syn/S04.html#Statement_parsing it says: if $term ($x) # syntax error (two terms in a row) if this cause an error, why not treat '$term ($x)' as a function call. At least when $term is not some abstract variable but valid name of simple function. (I have nothing to do with the design process, so this is just my take on it)... I get the impression that driving these sort of decisions, is the historical problem we've had with only `perl` being able to parse Perl. Syntax is getting tightened up a little, with the result that perl6 programs are much more easily read, with the intention of allowing different compiler implementations. Also, we can only know if $term contains a valid subroutine name at runtime, and perl6 aims to allow very separate compilation and runtime phases (and syntax errors need to be figured out at compilation time). Carl
Re: Whitespace (Was: [RELEASE] Pugs 6.2.9 released!)
On Thu, Aug 04, 2005 at 10:55:12AM +0400, Andrew Shitov wrote:
why do we have to give up a space when calling functions under Pugs?
A need to type open('file.txt') instead of open ('file.txt') makes
me perplexing (not perl-flexing ;-) Our recent discussions in 'zip with()'
gave no answer.
This is so:
print (1+2)*3;
can print 9, instead of 3.
However, all three forms below should still work:
open('file.txt');
open ('file.txt');
open 'file.txt';
Thanks,
/Autrijus/
pgpOUEocut2jd.pgp
Description: PGP signature
Re: Whitespace (Was: [RELEASE] Pugs 6.2.9 released!)
Thus spake Autrijus: This is so: print (1+2)*3; can print 9, instead of 3. Just a newbie question: what would print (1+2)x3; print (or do)? And is print .(1+2)*3 allowed? brano tichý
Re: Whitespace (Was: [RELEASE] Pugs 6.2.9 released!)
I've just realised I quoted the wrong doc earlier, I meant to link to:
http://dev.perl.org/perl6/doc/design/syn/S12.html#Methods
.doit ()# ILLEGAL (two terms in a row)
.doit .() # okay, no arguments, same as .doit()
I had wrongly thought this also applied to subroutine calls, and that
the OP's open ('file.txt'); was illegal. I stand corrected!
Cheers,
Carl
Re: Whitespace (Was: [RELEASE] Pugs 6.2.9 released!)
On Thu, 4 Aug 2005 20:21:18 +0800, Autrijus Tang [EMAIL PROTECTED]
wrote:
On Thu, Aug 04, 2005 at 10:55:12AM +0400, Andrew Shitov wrote:
why do we have to give up a space when calling functions under Pugs?
A need to type open('file.txt') instead of open ('file.txt') makes
me perplexing (not perl-flexing ;-) Our recent discussions in 'zip with()'
gave no answer.
This is so:
print (1+2)*3;
can print 9, instead of 3.
Just out of curiousity, what would
print (1 + 2) * 3;
print?
FWIW I would *expect* print (1+2)*3; to print '3'
However, all three forms below should still work:
open('file.txt');
open ('file.txt');
open 'file.txt';
Thanks,
/Autrijus/
--
H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/)
using Perl 5.6.2, 5.8.0, 5.8.5, 5.9.2 on HP-UX 10.20, 11.00 11.11,
AIX 4.3 5.2, SuSE 9.2 9.3, and Cygwin. http://www.cmve.net/~merijn
Smoking perl: http://www.test-smoke.org,perl QA: http://qa.perl.org
reports to: [EMAIL PROTECTED],perl-qa@perl.org
Re: Whitespace
print (1+2)*3; can print 9, instead of 3. I'd prefer always have '3' (as a result of sum 1 + 2) here. A C-programmer would tread this like (print (1 + 2) * 3); # prints int, then returns void print (or do)? And is print .(1+2)*3 allowed? in fact, that is exactly (print.getArgument(3) * 3); the same as above. so why not 'print($x)' == 'print ($x)' ;-) -- Andrew.
