"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
es.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` newli
ts 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.
>
>
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.
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 'pu
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
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-asso
> >
> > > { $++ * ($ *= -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
re 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 solut
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
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 t
$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 di
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"
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) bu
nction 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.
S05-regex.pod
Log Message:
---
S05-regex.pod: clairify that trailing whitespace is significant w/ :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/r
# 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
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
# 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 Per
)
Changed paths:
M S99-glossary.pod
Log Message:
---
Typos, markup corrections, trailing 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 c14a
-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
# 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 er
.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.
=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
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
-glossary.pod
Log Message:
---
typos and whitespace fixes
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #124213]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=124213 >
m: class T{}; class S is T{}
rakudo-moar 2b303a: OUTPUT«===SORRY!===Cannot find method
-concurrency.pod
Log Message:
---
Fix typos and whitespace
nged paths:
M S99-glossary.pod
Log Message:
---
* whitespace
* spelling
* reordering some entries for clarity
* grammar
* fix POD-os
* americanize
* capitalization consistency
-setting-library/Containers.pod
Log Message:
---
just a tiny whitespace fix.
On Tue Nov 20 11:36:45 2012, FROGGS.de wrote:
> looks good nowadays:
>
> rakudo: sub Good ($time) { say "Good $time #perl6." }; Good now
> # discovered by tylercurtis
> rakudo bf472b: OUTPUT«Good Instant:1353440186.178945 #perl6.»
Test added in S02-literals/string-interpolation.t
--
Will "Cok
# New Ticket Created by Tobias Leich
# Please include the string: [perl #120895]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=120895 >
p: say qq:to/EOF/ ~~ /\t/;\thelloEOF# the tab is preserved
rakudo-parrot c14a84: OUT
dos:
{
$_ = "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
-concurrency-jnthn.pod
Log Message:
---
[new 17] whitespace fixes
and close a dangling quote
rakudo 45e8c4: OUTPUT«42alive»
w... wow.
r: sub infix:($l, $r) { $l !== $r }; say 5 isnot 42
rakudo 45e8c4: OUTPUT«===SORRY!===Two terms in a row [...]
apparently, arbitrary whitespace doesn't work too well.
r: sub infix:($l, $r) { $l !== $r }; say 5 is not 42
# looks like i
unted as <.ws>
moritz: right, but this one isn't leading, it's after the '^'.
r: grammar G { rule TOP { ^ }; rule foo { foo } };
say ?G.parse(" foo")
rakudo 96776b: OUTPUT«False»
and putting more stuff in between doesn't help either...
if no-one
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/"
>
unsubscribe
On Sat, Sep 1, 2012 at 3:30 AM, GlitchMr wrote:
> # New Ticket Created by GlitchMr
> # Please include the string: [perl #114692]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org:443/rt3/Ticket/Display.html?id=114692 >
>
>
> This code wor
# New Ticket Created by GlitchMr
# Please include the string: [perl #114692]
# in the subject line of all future correspondence about this issue.
# 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.
pri
moved 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' the
11, near
> "our sub xy"»
> rakudo: our sub xyz($x) { say $x }+ xyz 3
> rakudo ecacff: OUTPUT«3Method 'Num' not found for invocant
> of class 'Perl6Sub' [...]
> pmichaud: what's that last evaluation?
> pmichaud: where does Perl6Sub enter in
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
-bits.pod
Log Message:
---
fix podchecker whitespace warning
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: OUTP
s expected?
rakudo 8533c3: OUTPUT«120»
no, I think whitespace in operators is disallowed
rakudo:sub postfix:< >($a) { [*] 1..$a; }; say (* )(5); # SBC case
rakudo 8533c3: OUTPUT«120»
JimmyZ++ # whitespace op bug
* masak submits rakudobug
rakudo: say (* )(5)
rakudo 8533c3: OUTPUT«in
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #85506]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=85506 >
std: my $a = 42; say "$a []" [13:05]
std 4608239: OUTPUT«ok 00:01 122m»
rakudo: my
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #80330]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=80330 >
rakudo: my @a; [...@a
rakudo : ( no output )
rakudo: my @a; [+] @a
rakudo : ( no o
ood
now # discovered by tylercurtis
rakudo 7c74c0: OUTPUT«===SORRY!===Unable to parse blockoid,
couldn't find final '}' at line 22»
std: sub Good ($time) { say "Good $time #perl6." }; Good now
std 237d266: OUTPUT«ok 00:01 119m»
* masak submits rakudobug
I know wha
I think whitespace before a leading/trailing ^/$ needs to be discounted.
Dwimmery and elegance demand.
+1
do: our sub xyz($x) { say $x }+ xyz 3
rakudo ecacff: OUTPUT«3Method 'Num' not found for invocant
of class 'Perl6Sub' [...]
pmichaud: what's that last evaluation?
pmichaud: where does Perl6Sub enter into it?
masak: the + is acting like an infix:<+>
where it ou
>...
> 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
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 { ^ }
> > rule TOP {^ }
> It actually conforms the current spec. Each consecutive run of
# New Ticket Created by rir...@comcast.net
# Please include the string: [perl #75668]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=75668 >
In
commit a5467733bdab87210a4eae6d3af309a0c3041c87
I think it is a bug that these
Now fixed in 841262f. Assigning to moritz++ for test verification to
close ticket.
Pm
# New Ticket Created by Steven Albano
# Please include the string: [perl #73804]
# in the subject line of all future correspondence about this issue.
# 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 appe
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #73772]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=73772 >
rakudo: say < >.elems
rakudo db0f85: OUTPUT«Method 'elems' not found for invocant
of c
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #70606]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=70606 >
rakudo: "b" ~~ /b| /
rakudo 7347ec: Null PMC access in find_method('reduce') [...]
* m
# New Ticket Created by Matthew Walton
# Please include the string: [perl #66966]
# in the subject line of all future correspondence about this issue.
# 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 {
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
> wrote:
> > * The Unicode character name database [2] has parens in the
> > name property field for many characters
> >
> > 000A;;Cc;0;B;N;LINE FEED (LF)
>
> That's no
On Tue, Apr 28, 2009 at 2:27 PM, Patrick R. Michaud 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 th
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
> >
> >
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 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,
On Tue, Apr 28, 2009 at 10:22 AM, Larry Wall 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
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 - especi
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, # blaf
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 =>
his,
$.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.t
Thanks. Applied as r27734.
kid51
# New Ticket Created by "Ifejinelo Onyiah"
# Please include the string: [perl #54610]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=54610 >
The purpose of this patch is to allow parrot pass the "no t
# New Ticket Created by Patrick R. Michaud
# Please include the string: [perl #53464]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=53464 >
Modify PGE to trim extra whitespace around #= keys
(which really shouldn&#
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.
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 +36
es, 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
ed 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
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-m
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 whitesp
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 cod
# New Ticket Created by Shawn M Moore
# Please include the string: [perl #42236]
# in the subject line of all future correspondence about this issue.
# 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
ble with the default whitespace splitchars.
This ticket is in response to cage task #39704.
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
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
Patrick R. Michaud wrote:
On Tue, Jul 04, 2006 at 12:57:16PM -0700, Allison Randal wrote:
--
token start { ^*$ }
regex emptyline { ^^ $$ \n }
token ws { [ | \t]* }
--
The above grammar doesn't have a "grammar" statement; as a result
the regexes are being installed into the '' names
On Tue, Jul 04, 2006 at 12:57:16PM -0700, Allison Randal wrote:
> --
>
> token start { ^*$ }
>
> regex emptyline { ^^ $$ \n }
>
> token ws { [ | \t]* }
>
> --
The above grammar doesn't have a "grammar" statement; as a result
the regexes are being installed into the '' namespace.
> If
Nathan Gray wrote:
>
> Overloading 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
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
overl
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, Bernh
"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 f
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
>> : 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
ired 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 tryi
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.g
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 p
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 th
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ý
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
> > 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 ca
> 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
> 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://d
1 - 100 of 219 matches
Mail list logo
