ut;'
> 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
\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`
ains on that Str. And:
>
> $ raku -e 'put "1\n2\n3"' | raku -e 'put lines.Str'
> 1 2 3
>
> There's your horizontal whitespace.
>
>
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 'put "1\
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
>
> > > { $++ * ($ *= -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
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 see
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
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
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
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
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
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.
n 2017)
Changed paths:
M S05-regex.pod
Log Message:
---
S05-regex.pod: clairify that trailing whitespace is significant w/ :s
fix 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
# 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
statements end
# 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
-12-29 (Tue, 29 Dec 2015)
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
ndentation 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 ins
# 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.
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
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
)
Changed paths:
M S99-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.
# URL: https://rt.perl.org/Ticket/Display.html?id=124213
Ven m: class T{}; class S is T{}
camelia rakudo-moar 2b303a:
paths:
M S17-concurrency.pod
Log Message:
---
Fix typos and whitespace
)
Changed paths:
M S99-glossary.pod
Log Message:
---
* whitespace
* spelling
* reordering some entries for clarity
* grammar
* fix POD-os
* americanize
* capitalization consistency
2014)
Changed paths:
M S32-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:
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
--
# 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
:
{
$_ = 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
paths:
M S17-concurrency-jnthn.pod
Log Message:
---
[new 17] whitespace fixes
and close a dangling quote
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
.
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
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!===
# 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.
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:
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
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
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
paths:
M S02-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: OUTPUT«120»
JimmyZ
?
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
# 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
# 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; [+]
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
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
I think whitespace before a leading/trailing ^/$ needs to be discounted.
Dwimmery and elegance demand.
+1
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
...
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
# 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
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.
# 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
# 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
# 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
# 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
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
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...
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
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,
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
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
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
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
($.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
# 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
Thanks. Applied as r27734.
kid51
/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
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.
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
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
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
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
# 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/
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
variable with the default whitespace splitchars.
This ticket is in response to cage task #39704.
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
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
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,
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
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'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
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
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
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 think I'll never
drop space in a function call if it can
. 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
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,
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:
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?
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,
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.
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ý
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
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
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
1 - 100 of 179 matches
Mail list logo
