[perl #73214] [BUG] Potentially annoying that goal failure is indicated by throwing an exception in Rakudo
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #73214]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=73214 >
rakudo: say '(foo' ~~ / '(' ~ ')' [foo] /
rakudo 5e5969: OUTPUT«Unable to parse _block48, couldn't find
final ')' [...]
why does everything in regexes indicate falure with a
False-valued $/, except for goals, which indicate failure by throwing
an exception?
maybe should return failure instead of throwing exception
yes, please.
my real-world situation to back this up is a test file with a
grammar parse wrapped in a method call which checks whether the syntax
of an expression is correct. I only expect the method call to return a
Bool, not to blow up.
I'll have to think a bit about how to pull that off. But
feel free to file this as a ticket :)
gladly.
* masak submits rakudobug
well, I can certainly get it to fail the match. I'm not
sure where the message goes, though.
[perl #73218] [BUG] Can't return from within a try block in Rakudo
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #73218]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=73218 >
rakudo: sub foo() { try { return 42 }; return 5 }; say foo
rakudo 5e5969: OUTPUT«5»
o.O
ok, so I know about the returns-are-exceptions idea, but surely... :/
* masak submits rakudobug
My reading of S04 is that try blocks don't catch return exceptions by default.
Re: I can install padre from CPAN
Also tested the install from SVN [1] and it also worked like a charm. WARNING !! only install from SVN if instructed or you feel lucky [1] http://padre.perlide.org/trac/wiki/Download#Moredetailedinstructionformanualinstallation 2010/2/21 Víctor A. Rodríguez (Bit-Man) : > Hello everybody, > > some time ago I asked for help o installing Padre, and Gabor Szabo > kindly helped me (and many others, I guess) creating Padre Stand Alone > for Linux, an experimental Padre distro. > > Yesterday i found how to install Padre from CPAN [1]. Thanks to Pete > for the blog entry !! > > [1] http://perlwannabe.vox.com/library/post/installing-padre-from-cpan.html > -- Víctor A. Rodríguez (http://www.bit-man.com.ar) El bit Fantasma (Bit-Man) - Programming: love it or leave it. Perl Mongers Capital Federal (http://cafe.pm.org/) GNU/Linux User Group - FCEyN - UBA (http://glugcen.dc.uba.ar/)
[perl #73236] [BUG] LTA error messages on literals with too many decimals in Rakudo
# New Ticket Created by "Carl Mäsak" # Please include the string: [perl #73236] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=73236 > rakudo: say 0. # also by diakopterbot rakudo 6867a5: OUTPUT«No applicable candidates found to dispatch to for 'infix:' [...] rakudo: say 0.000 rakudo 6867a5: OUTPUT«Nominal type check failed for parameter '$b'; expected Int but got Num instead [...] * masak submits rakudobug Here it's just a question of catching the error sooner and emitting a nice error message. At least until we can actually handle arbitrarily long decimal expansions.
[perl #73232] [BUG] LTA error message when declaring dot-twigil variables outside of a class scope in Rakudo
# New Ticket Created by "Carl Mäsak" # Please include the string: [perl #73232] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=73232 > std: my Any %.x=3,%.x; std 29917: OUTPUT«ok 00:01 109m» rakudo: my Any %.x=3,%.x; rakudo 6867a5: OUTPUT«Lexical 'self' not found [...] * masak submits LTA rakudobug In my opinion, it should give an error already at the wonky declaration.
[perl #73238] [BUG] Rakudo treats 2^64-1 in hex or octal form as -1
# New Ticket Created by "Carl Mäsak" # Please include the string: [perl #73238] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=73238 > rakudo: say 0x # diakopterbot rakudo 6867a5: OUTPUT«-1» ok * masak submits rakudobug rakudo: say 0o77 rakudo 6867a5: OUTPUT«-1»
[perl #73244] [PATCH] implement grammars
# New Ticket Created by Bruce Keeler
# Please include the string: [perl #73244]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=73244 >
The attached patch is also available in the 'grammar' branch of my
github fork (bkeeler/rakudo). I'll keep that branch up to date to make
sure it applies cleanly.
Notes:
* regex_declarator now calls regex_def, which is prototyped over
'rule', 'token' and 'regex'. This matches STD.pm
* The form of passing arguments to subrules now
uses the Rakudo arglist rule, and so can take arbitrary
expressions. The form cannot at preset use the
rakudo arglist, as EXPR tries to eat the closing angle. The colon
form is limited to a list of simple literals.
* builtins/Grammar.pir has been rewritten as core/Grammar.pm
* Signatures may be applied to regexes. Parameters may be
referenced in closures within the regex.
* Named regexes may not be declared outside of a grammar or class.
* The form of calling subrules in another grammar does
not work. This will require changes to the regex engine.
Unfortunately, this holds up a number of tests that would
otherwise pass.
* S05-grammar/action-stubs.t and S05-grammar/methods.t now pass, as
well as two new test files S05-grammar/protos.t and
S05-grammar/signatures.
* I attempted to factor out common code between regex_def and
method_def, but ran into problems and backed out. I'll take
another crack at this sometime soon.
From 1d3b996dee09880c20dbe40dab96158ba1dfe220 Mon Sep 17 00:00:00 2001
From: Bruce Keeler
Date: Sun, 28 Feb 2010 20:36:20 -0800
Subject: [PATCH] Implementation of grammars
---
build/Makefile.in |2 +-
src/Perl6/Actions.pm | 186 +++-
src/Perl6/Grammar.pm | 44 ---
src/builtins/Grammar.pir | 94 --
src/core/Grammar.pm| 16
src/metamodel/ClassHOW.pir |3 +-
t/spectest.data|6 +-
7 files changed, 206 insertions(+), 145 deletions(-)
delete mode 100644 src/builtins/Grammar.pir
create mode 100644 src/core/Grammar.pm
diff --git a/build/Makefile.in b/build/Makefile.in
index edfb97c..5a7a98b 100644
--- a/build/Makefile.in
+++ b/build/Makefile.in
@@ -98,7 +98,6 @@ BUILTINS_PIR = \
src/builtins/EMPTY.pir \
src/builtins/ParrotIter.pir \
src/builtins/List.pir \
- src/builtins/Grammar.pir \
src/builtins/Parcel.pir \
src/builtins/Bool.pir \
src/builtins/Int.pir \
@@ -190,6 +189,7 @@ CORE_SOURCES = \
src/core/Block.pm \
src/core/Regex.pm \
src/core/Junction.pm \
+ src/core/Grammar.pm \
src/core/system.pm \
src/cheats/match-bool.pm \
src/cheats/setup-io.pm \
diff --git a/src/Perl6/Actions.pm b/src/Perl6/Actions.pm
index 5c65c0a..3ee710a 100644
--- a/src/Perl6/Actions.pm
+++ b/src/Perl6/Actions.pm
@@ -1035,33 +1035,135 @@ method method_def($/) {
make $past;
}
-method regex_declarator($/, $key?) {
-if $key ne 'open' {
-# Create regex code object.
-# XXX TODO: token/regex/rule differences, signatures, traits.
-my $past := Regex::P6Regex::Actions::buildsub($.ast);
-$past := create_code_object($past, 'Regex', 0, '');
-
-# Install in lexpad or namespace. XXX Need & on start of name?
-my $name := ~$;
-if $*SCOPE ne 'our' {
-@BLOCK[0][0].push(PAST::Var.new( :name($name), :isdecl(1),
- :viviself($past),
:scope('lexical') ) );
-@BLOCK[0].symbol($name, :scope('lexical') );
-}
+our %REGEX_MODIFIERS;
+method regex_declarator:sym($/, $key?) {
+if ($key) {
+my %h;
+%REGEX_MODIFIERS := %h;
+} else {
+make $.ast;
+}
+}
-# Otherwise, package scoped; add something to loadinit to install them.
-else {
-@PACKAGE[0].block.loadinit.push(PAST::Op.new(
-:pasttype('bind'),
-PAST::Var.new( :name($name), :scope('package') ),
-$past
-));
-@BLOCK[0].symbol($name, :scope('package') );
+method regex_declarator:sym($/, $key?) {
+if ($key) {
+my %h;
+%h := 1;
+%REGEX_MODIFIERS := %h;
+} else {
+make $.ast;
+}
+}
+
+method regex_declarator:sym($/, $key?) {
+if ($key) {
+my %h;
+%h := 1; %h :=1;
+%REGEX_MODIFIERS := %h;
+} else {
+make $.ast;
+}
+}
+
+method regex_def($/, $key?) {
+my $name := ~$[0];
+my @MODIFIERS := Q:PIR {
+%r = get_hll_global ['Regex';'P6Regex';'Actions'], '@MODIFIERS'
+};
+my $past;
+if $key eq 'open' {
+@MODIFIERS.unshift(%REGEX_MODIFIERS);
+# The following is so that can work
+Q:PIR {
+$P0 = find_lex '$name'
+set_hll_global ['Regex';'P6Regex';'Acti
[perl #73230] [BUG] Strange error when doing positional (.[]) indexing on a Hash object in Rakudo
# New Ticket Created by "Carl Mäsak" # Please include the string: [perl #73230] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=73230 > rakudo: my Hash $x; $x[1] # by diakopterbot rakudo 6867a5: OUTPUT«No applicable candidates found to dispatch to for '_block12568'current instr.: 'perl6;Perl6Role;!select' pc 9770 (src/gen/RoleToClassApplier.pir:574)» * masak submits rakudobug alpha: my Hash $x; $x[1] alpha 30e0ed: ( no output ) o.O locally, alpha says "Could not build C3 linearization: ambiguous hierarchy". I recognize that error. it's in some other bug ticket. but this is a new issue, so new ticket it is.
Re: Perl6 confused about module name
Hi Bruce, On Tue, Mar 2, 2010 at 17:48, Bruce Keeler wrote: > On 3/2/10 2:53 AM, Carl Mäsak wrote: >> >> Victor (>): >> >>> >>> Why it asks for Opendir.pir instead of Opendir.pm ? >>> Any clue ? >>> >> >> Short answer: Rakudo has regressed and doesn't support loading .pm >> modules at the moment. You're probably on the Amsterdam (February) >> release. I suggest using the Minneapolis (January) release until >> Rakudo regains this functionality. >> > > Another possibility might be to compile Opendir.pm down to pir using > > ./perl6 --target=pir Opendir.pm > > I'll give this one a try. Thanks ! -- Víctor A. Rodríguez (http://www.bit-man.com.ar) El bit Fantasma (Bit-Man) - Programming: love it or leave it. Perl Mongers Capital Federal (http://cafe.pm.org/) GNU/Linux User Group - FCEyN - UBA (http://glugcen.dc.uba.ar/)
[perl #73234] [BUG] Null PMC access when invoking the type objects Block, Code, Sub, Method, Multi, or Routine
# New Ticket Created by "Carl Mäsak" # Please include the string: [perl #73234] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=73234 > rakudo: say Block ~~ Code rakudo 6867a5: OUTPUT«1» rakudo: Block.() rakudo 6867a5: OUTPUT«Null PMC access in invoke() [...] * masak submits rakudobug rakudo: Code.() rakudo 6867a5: OUTPUT«Null PMC access in invoke() [...] rakudo: Sub.() rakudo 6867a5: OUTPUT«Null PMC access in invoke() [...] rakudo: Method.() rakudo 6867a5: OUTPUT«Null PMC access in invoke() [...] rakudo: Multi.() rakudo 6867a5: OUTPUT«Null PMC access in invoke() [...] rakudo: Routine.() rakudo 6867a5: OUTPUT«Null PMC access in invoke() [...]
[perl #73236] [BUG] LTA error messages on literals with too many decimals in Rakudo
rakudo: say 0. 00 rakudo 5e5969: OUTPUT«Divide by zerocurrent instr.: 'infix:' [...] nice! 3 different bugs the exact error changes with the number of extra 0's you have! rakudo: say 0.000 0010 # hee hee rakudo 5e5969: OUTPUT«Nominal type check failed for parameter '$a'; expected Int but got Num instead [...] omg first $b, now $a! 4 different bugs
Re: Perl6 confused about module name
Thanks Carl, On Tue, Mar 2, 2010 at 07:53, Carl Mäsak wrote: > Victor (>): >> Why it asks for Opendir.pir instead of Opendir.pm ? >> Any clue ? > > Short answer: Rakudo has regressed and doesn't support loading .pm > modules at the moment. You're probably on the Amsterdam (February) > release. I suggest using the Minneapolis (January) release until > Rakudo regains this functionality. I'm building nightly from nightly git updates, then I'll need to change the way it wprks :-P Thanks again ! -- Víctor A. Rodríguez (http://www.bit-man.com.ar) El bit Fantasma (Bit-Man) - Programming: love it or leave it. Perl Mongers Capital Federal (http://cafe.pm.org/) GNU/Linux User Group - FCEyN - UBA (http://glugcen.dc.uba.ar/)
r29930 - docs/Perl6/Spec
Author: masak
Date: 2010-03-03 15:16:22 +0100 (Wed, 03 Mar 2010)
New Revision: 29930
Modified:
docs/Perl6/Spec/S03-operators.pod
Log:
[S03] typo, discovered by particle++
Modified: docs/Perl6/Spec/S03-operators.pod
===
--- docs/Perl6/Spec/S03-operators.pod 2010-03-03 07:37:31 UTC (rev 29929)
+++ docs/Perl6/Spec/S03-operators.pod 2010-03-03 14:16:22 UTC (rev 29930)
@@ -2617,7 +2617,7 @@
when all(:r,:w,:x)
The pair forms are useful only for boolean tests because the method's
-value is evaluated as a boolen, so the
+value is evaluated as a Bool, so the
method form must be used for any numeric-based tests:
if stat($filename).s > 1024 {...}
Re: Building Rakudo under Windows 7 / 32bit
On Tue, Mar 2, 2010 at 10:26 PM, Ronald Schmidt wrote: > > Please try removing the parrot and parrot_install directories and try > the --gen-parrot option again and let me know if that changes the > failure mode. > > > > No luck. > > I removed both directories, reset the build\PARROT_VERSION to 44371, ran > "perl Configure.pl --gen-parrot" followed by "mingw32-make". When that > failed I updated the content of the build\PARROT_VERSION file to 44592 and > repeated the procedure of running "perl Configure.pl --gen-parrot" and > "mingw32-make" with the same results. The error consistently is: > > C:\Temp\rakudo\parrot_install\bin\parrot.exe src\gen\perl6.pbc --target=pir > \ > src\gen\core.pm > src\gen\core.pir > mingw32-make: *** [perl6.pbc] Error -1073741819 > > Thanks, > Ron > > I am running a Dell Optiplex Intel Core 2 Duo E4500 with 2GB ram and no > special virtual memory settings. > > > Thanks for checking. I wonder if this is related to my issue here: http://trac.parrot.org/parrot/ticket/1489 -- Will "Coke" Coleda
r29931 - docs/Perl6/Spec
Author: lwall
Date: 2010-03-03 18:34:04 +0100 (Wed, 03 Mar 2010)
New Revision: 29931
Modified:
docs/Perl6/Spec/S02-bits.pod
Log:
[S02] remove 1/2 and +2-3i literal forms, now rely on angle dwimmery for
literals,
or constant folding otherwise.
Modified: docs/Perl6/Spec/S02-bits.pod
===
--- docs/Perl6/Spec/S02-bits.pod2010-03-03 14:16:22 UTC (rev 29930)
+++ docs/Perl6/Spec/S02-bits.pod2010-03-03 17:34:04 UTC (rev 29931)
@@ -13,8 +13,8 @@
Created: 10 Aug 2004
-Last Modified: 27 Feb 2010
-Version: 206
+Last Modified: 3 Mar 2010
+Version: 207
This document summarizes Apocalypse 2, which covers small-scale
lexical items and typological issues. (These Synopses also contain
@@ -133,7 +133,7 @@
=item *
-Except within a string literal, a C<#> character always introduces a comment in
+Except within a quote literal, a C<#> character always introduces a comment in
Perl 6. There are two forms of comment based on C<#>. Embedded
comments require the C<#> to be followed by a backtick (C<`>) plus one
or more opening bracketing characters.
@@ -3013,25 +3013,27 @@
=item *
Rational literals are indicated by separating two integer literals
-(in any radix) with a slash. Whitespace is not allowed on either
-side of the slash:
+(in any radix) with a slash, and enclosing the whole in angles:
-1/2 # one half literal Rat
-1 / 2 # 1 divided by 2 (also produces a Rat by constant folding)
+<1/2> # one half literal Rat
-Note that this essentially overrides precedence to produce a term, so:
+Whitespace is not allowed on either side of the slash or it will
+be split under normal quote-words semantics:
-1/2 * 3/4
+< 1 / 2 > # ('1', '/', '2')
+< 1/2 > # okay, same as <1/2>
-means
+Because of constant folding, you may often get away with leaving
+out the angles:
-(1 / 2) * (3 / 4)
+1/2 # 1 divided by 2
-rather than
+However, in that case you have to pay attention to precedence and
associativity.
+The following does I cube C<2/3>:
-((1 / 2) * 3) / 4
+2/3**3 # 2/(3**3), not (2/3)**3
-Decimal fractions not using "e" notation are also stored as C values:
+Decimal fractions not using "e" notation are also treated as literal C
values:
6.02e23.WHAT # Num
1.23456.WHAT # Rat
@@ -3040,15 +3042,19 @@
=item *
Complex literals are similarly indicated by writing an addition or subtraction
of
-two real numbers without spaces:
+two real numbers (again, without spaces around the operators) inside angles:
-5.2+1e42i
-3-1i
+<5.2+1e42i>
+< -3-1i >
As with rational literals, constant folding would produce the same
complex number, but this form parses as a single term, ignoring
surrounding precedence.
+(Note that these are not actually special syntactic forms: both
+rational and complex literal forms fall out naturally from the semantic
+rules of qw quotes described below.)
+
=item *
Characters indexed by hex numbers can be interpolated into strings
@@ -3143,11 +3149,13 @@
The purpose of this would be to facilitate compile-time analysis of
multi-method dispatch, when the user prefers angle notation as the
most readable way to represent a list of numbers, which it often is.
+The form with a single value serves as the literal form of numbers
+such as C and C that would otherwise have to be constructed.
It also gives us a reasonable way of visually isolating any known
literal format as a single syntactic unit:
<-1+2i>.polar
-(-1+2i).polar # same, but less clearly a literal
+(-1+2i).polar # same, but only by constant folding
The degenerate case C<< <> >> is disallowed as a probable attempt to
do IO in the style of Perl 5; that is now written C. (C<<
continuation markers for long literals (was Re: r29931 - docs/Perl6/Spec)
pugs-comm...@feather.perl6.nl wrote: Modified: docs/Perl6/Spec/S02-bits.pod Log: [S02] remove 1/2 and +2-3i literal forms, now rely on angle dwimmery for literals, or constant folding otherwise. I find this an interesting change, and I can see how it would simplify some things, even though I would miss the old behavior. But this reminds me of what I see as a tangential issue, which I want to raise. How would Perl 6 support someone wanting to write a numeric literal that is so long that they would want to split it over multiple source code lines, such as a very long integer that takes a few hundred or thousand characters to write, or an X/Y rational composed of 2 such integers, but they want to keep their source code under the 80 chars per line mark. I'm not currently aware that Perl 6 provides some kind of "continuation marker" that one could put between pieces of such a literal, so that they could split those pieces otherwise with whitespace but then the parser would treat the code as if said whitespace wasn't there, but I think Perl 6 should have this. It would need to work both outside any quoting constructs as well as inside any angle dwimmery. On one hand I would think the mnemonics of "~", which are stitching things together, would work great for a continuation marker, but that "~" seems to already be established in Perl 6 as indicating a string data context, such that it is used for casting things into Str or catenating 2 strings. However, I will use "~" below for the sake of illustration. my $some_pi = 3.141592653589793238462643383279 ~ 5028841971693993751058209749445923078164 ~ 0628620899862803482534211706798214808651 ~ 3282306647093844609550582231725359408128; my $a_rat = <48111745028410270193 ~ 8521105559/64462294895493038196 ~ 442881097566593344612847564823>; As a slight extension to this, one should be able to use that same continuation character between 2 consecutive string literals so that they are parsed as if they were one string literal, so that one could also split those over source code lines, without the vaguarities of source code line endings affecting the value of the string like a here-doc or literal line breaks would. I grant that this could be redundant with regular constant folding of the already defined "~" operator, but using the continuation marker instead for this could spare concern about precedence issues same as <1/2> does versus 1/2 after today's changes. my $a_string = 'hello this world' ~ ' how are you today'; Now I think in the wider world some precedent exists for using the logical-not character ¬ as a continuation marker, but that isn't an ASCII symbol and we would want something ASCII for the continuation marker. Also I think using the backslash for such a marker would be a bad idea. While this isn't an operator per se, if it had to be put in the precedence table, I would think it would have the highest possible precedence; it would be eliminated during one of the earliest parsing phases, during tokenization I believe, and then all the other parsing rules would come into effect following that elimination, except for the big one that any literal continuation chars inside a quoted string are taken as normal characters as usual. So can we please have this continuation marker thing, and what do you think it should look like? Thank you in advance. -- Darren Duncan
Re: continuation markers for long literals (was Re: r29931 - docs/Perl6/Spec)
Doesn't unspace work for this? On Wednesday, March 3, 2010, Darren Duncan wrote: > pugs-comm...@feather.perl6.nl wrote: > > Modified: > docs/Perl6/Spec/S02-bits.pod > Log: > [S02] remove 1/2 and +2-3i literal forms, now rely on angle dwimmery for > literals, > or constant folding otherwise. > > > > I find this an interesting change, and I can see how it would simplify some > things, even though I would miss the old behavior. > > But this reminds me of what I see as a tangential issue, which I want to > raise. > > How would Perl 6 support someone wanting to write a numeric literal that is > so long that they would want to split it over multiple source code lines, > such as a very long integer that takes a few hundred or thousand characters > to write, or an X/Y rational composed of 2 such integers, but they want to > keep their source code under the 80 chars per line mark. > > I'm not currently aware that Perl 6 provides some kind of "continuation > marker" that one could put between pieces of such a literal, so that they > could split those pieces otherwise with whitespace but then the parser would > treat the code as if said whitespace wasn't there, but I think Perl 6 should > have this. It would need to work both outside any quoting constructs as well > as inside any angle dwimmery. > > On one hand I would think the mnemonics of "~", which are stitching things > together, would work great for a continuation marker, but that "~" seems to > already be established in Perl 6 as indicating a string data context, such > that it is used for casting things into Str or catenating 2 strings. > However, I will use "~" below for the sake of illustration. > > my $some_pi = 3.141592653589793238462643383279 > ~ 5028841971693993751058209749445923078164 > ~ 0628620899862803482534211706798214808651 > ~ 3282306647093844609550582231725359408128; > my $a_rat = <48111745028410270193 > ~ 8521105559/64462294895493038196 > ~ 442881097566593344612847564823>; > > As a slight extension to this, one should be able to use that same > continuation character between 2 consecutive string literals so that they are > parsed as if they were one string literal, so that one could also split those > over source code lines, without the vaguarities of source code line endings > affecting the value of the string like a here-doc or literal line breaks > would. I grant that this could be redundant with regular constant folding of > the already defined "~" operator, but using the continuation marker instead > for this could spare concern about precedence issues same as <1/2> does > versus 1/2 after today's changes. > > my $a_string = 'hello this world' > ~ ' how are you today'; > > Now I think in the wider world some precedent exists for using the > logical-not character ¬ as a continuation marker, but that isn't an ASCII > symbol and we would want something ASCII for the continuation marker. Also I > think using the backslash for such a marker would be a bad idea. > > While this isn't an operator per se, if it had to be put in the precedence > table, I would think it would have the highest possible precedence; it would > be eliminated during one of the earliest parsing phases, during tokenization > I believe, and then all the other parsing rules would come into effect > following that elimination, except for the big one that any literal > continuation chars inside a quoted string are taken as normal characters as > usual. > > So can we please have this continuation marker thing, and what do you think > it should look like? > > Thank you in advance. > > -- Darren Duncan > > -- Mark J. Reed
Re: continuation markers for long literals (was Re: r29931 - docs/Perl6/Spec)
Mark J. Reed wrote: Doesn't unspace work for this? It would seem that S02 says otherwise: Although we say that the unspace hides the whitespace from the parser, it does not hide whitespace from the lexer. As a result, unspace is not allowed within a token. So, assuming that an integer literal at least, and maybe also an angle dwimmery, is a single token, then that wouldn't work. If unspace did the job, I should be able to say this: my $foo = 3.1415926535897\ 93238462643383279; or: my $foo = 3.1415926535897\ 93238462643383279; and it would be interpreted the same ways as if I said: my $foo = 3.141592653589793238462643383279; Now I think there are good reasons for unspace not being allowed in a token, in which case we'd need some other syntax for the continuation marker that I want. As for supporting long rational literals expressed as X/Y, I can live with being required to say "(136\ 5634/42442\ 555)" and depend on constant folding rather than "<136\ 5634/42442\ 555>" doing the same, if that would make things easier. However, the likes of this needs to work: my $bar = :8<55084\ 4222\ 7677>; ... same as this does: my $baz = 564345\ 242432; Thank you. -- Darren Duncan
Re: continuation markers for long literals (was Re: r29931 - docs/Perl6/Spec)
Surely this is not a common-enough requirement to warrant a special syntax. At 80-columns, you can represent integers up to ninety-nine quinvigintillion, nine hundred ninety-nine quattuorvigintillion, nine hundred ninety-nine trevigintillion, nine hundred ninety-nine duovigintillion, nine hundred ninety-nine unvigintillion, nine hundred ninety-nine vigintillion, nine hundred ninety-nine novemdecillion, nine hundred ninety-nine octodecillion, nine hundred ninety-nine septendecillion, nine hundred ninety-nine sexdecillion, nine hundred ninety- nine quindecillion, nine hundred ninety-nine quattuordecillion, nine hundred ninety-nine tredecillion, nine hundred ninety-nine duodecillion, nine hundred ninety-nine undecillion, nine hundred ninety-nine decillion, nine hundred ninety-nine nonillion, nine hundred ninety-nine octillion, nine hundred ninety-nine septillion, nine hundred ninety-nine sextillion, nine hundred ninety-nine quintillion, nine hundred ninety- nine quadrillion, nine hundred ninety-nine trillion, nine hundred ninety- nine billion, nine hundred ninety-nine million, nine hundred ninety-nine thousand, and nine hundred ninety-nine. Surely that's enough for the vast majority of users, isn't it? And if you *do* need anything bigger (perhaps to represent the burgeoning U.S. national debt) then there's always some variation on: my $debt = +( 123456789012345678901234567890123456789012345678901234 ~ 567890123456789012345678901234567890123456789012345678 ~ 901234567890123456789012345678901 ); or even: my $debt = +( 123_456_789_012_345_678_901_234_567_890_123_456_789_012_345_678_901_234 ~ 567_890_123_456_789_012_345_678_901_234_567_890_123_456_789_012_345_678 ~ 901_234_567_890_123_456_789_012_345_678_901 ); if you like to group your thousands for better readability. With adequate constant folding, both of those are still compile-time constants. Damian
Re: continuation markers for long literals (was Re: r29931 - docs/Perl6/Spec)
On Wed, Mar 3, 2010 at 6:26 PM, Darren Duncan wrote:
> Mark J. Reed wrote:
>>
>> Doesn't unspace work for this?
>
> It would seem that S02 says otherwise:
>
> Although we say that the unspace hides the whitespace from the parser, it
> does not hide whitespace from the lexer. As a result, unspace is not
> allowed within a token.
D'oh, indeed. Never mind.
>On Wed, Mar 3, 2010 at 7:00 PM, Damian Conway wrote:
> At 80-columns, you can represent integers up to ninety-nine
> quinvigintillion, [...]
Assuming the short scale. On the long scale, that's ninety-nine
tredecillion, nine hundred ninety-nine thousand nine hundred
ninety-nine duodecillion, etc. :)
> there's always some variation on:
>
> my $debt = +(
> 123456789012345678901234567890123456789012345678901234
> ~ 567890123456789012345678901234567890123456789012345678
> ~ 901234567890123456789012345678901
> );
Serviceable, but feels a bit hackish. Reminds me of faking P5 qw in
PHP by using split(' ', 'words like this'). But with a reasonably
intelligent compiler, as you say, at least it still compiles to a
literal.
I note that Rakudo alpha turns the above into Inf, which seems apropos. :)
--
Mark J. Reed
Re: continuation markers for long literals (was Re: r29931 - docs/Perl6/Spec)
Damian Conway wrote: Surely this is not a common-enough requirement to warrant a special syntax. At 80-columns, you can represent integers up to Surely that's enough for the vast majority of users, isn't it? Well, 80 columns was an example, albeit the most common, but the principle idea was to support writing code that fit into very narrow spaces (such as may result from having the 80-col constraint plus a whole bunch of code indent levels) while being able to keep the code easily readable and nicely formatted. I also figured that this would be a fairly simple thing to do. Part of the idea was that one could also wrap any long identifiers as well to fit in a narrow space. Now, granted that expressing every thing which might become long as a string literal could probably work, it seemed somewhat inelegant, though maybe the problem is uncommon enough that this is an acceptable sacrifice. And if you *do* need anything bigger (perhaps to represent the burgeoning U.S. national debt) then there's always some variation on: my $debt = +( 123456789012345678901234567890123456789012345678901234 ~ 567890123456789012345678901234567890123456789012345678 ~ 901234567890123456789012345678901 ); or even: my $debt = +( 123_456_789_012_345_678_901_234_567_890_123_456_789_012_345_678_901_234 ~ 567_890_123_456_789_012_345_678_901_234_567_890_123_456_789_012_345_678 ~ 901_234_567_890_123_456_789_012_345_678_901 ); if you like to group your thousands for better readability. With adequate constant folding, both of those are still compile-time constants. That sounds half-reasonable, though it would seem to me that you'd have to quote each piece of the number to make it work right if you were using anything other than base 10. And we're assuming that +(...) isn't producing a Num instead of an Int or Rat as the case may be, as if the rules for +(...) were the same as the parser's rules for what kind of number it makes. So if we leave things as is, then hopefully the examples you raised will be commonly supported as compile-time constants in Perl 6 implementations. -- Darren Duncan
Re: continuation markers for long literals (was Re: r29931 - docs/Perl6/Spec)
On Wed, Mar 03, 2010 at 05:39:58PM -0800, Darren Duncan wrote: : Damian Conway wrote: : >Surely this is not a common-enough requirement to warrant a special : >syntax. : > : >At 80-columns, you can represent integers up to : : >Surely that's enough for the vast majority of users, isn't it? : : Well, 80 columns was an example, albeit the most common, but the : principle idea was to support writing code that fit into very narrow : spaces (such as may result from having the 80-col constraint plus a : whole bunch of code indent levels) while being able to keep the code : easily readable and nicely formatted. Dealing with antediluvian displays sounds like a good spot for that ancient technology, the preprocessor, : I also figured that this would be a fairly simple thing to do. Well, it will be simple, once we have macros; in fact, textual macros can be regarded simply as scoped preprocessors, with all the rights, privileges, and responsibilities pertaining thereto. I think macros will provide enough language support for this sort of "hard things should be possible" escape hatch. And remember you can always override the grammar if you have special reasons for doing so. That's what Perl 6 is all about. It's not about foreseeing every possible twinge of misgiving that anyone may come to feel in the next 100 years... Sure, we're trying to create a gigantic sweet spot in Perl 6, but Willy Wonka knows you can't have the whole world, and if you could, you can't have it now. :) Larry
