[perl #50092] [TODO] pct - explicit transcode in PCT::Grammar::string_literal
# New Ticket Created by Patrick R. Michaud # Please include the string: [perl #50092] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=50092 > This is a placeholder ticket so we can show a dependency on #39930. In the "string_literal" rule of compilers/pct/src/PCT/Grammar.pir, I've just added an explicit transcode step for codepoints outside of the ascii range: ... $S1 = chr codepoint if codepoint < 128 goto literal_xdo_char_end_1 $I0 = find_charset 'unicode' trans_charset $S1, $I0 literal_xdo_char_end_1: concat literal, $S1 ... The reason for the explicit transcode is to allow the above to work even when ICU isn't present. By default, the 'chr' opcode returns an ascii string for codepoints 0-127, an iso-8859-1 string for 128-255, and unicode for everything 256 and above. However, as noted in RT#39930, Parrot is unable to concatenate iso-8859-1 strings to unicode strings when ICU isn't present. So, the above workaround automatically converts any non-ascii strings into unicode so that the resulting concatenation will work properly. When #39930 is resolved, we can eliminate the workaround. Pm
S29 doubts that need clarification
Hi all, I'm in the process of refactoring existing pugs test suite, for example t/builtins, into t/spec/S29-. Questions: - @array.uniq is not mentioned in S29. Should it be in S29/List? or S29/Array? - cis(), polar() and friends belong to S29/Num while they should probably belong to S29/Complex? Thanks! -- Cosimo
[perl #50074] [PATCH] [pct] Add pop() and shift() to PCT::Node
# New Ticket Created by Stuart Jansen
# Please include the string: [perl #50074]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=50074 >
This makes implementing lolcode ifthen support a tiny bit easier.
It looks like similiar support is already written for src/pmc/capture.pmc
---
compilers/pct/src/PCT/Node.pir| 20
docs/pdds/pdd26_ast.pod | 10 ++
languages/lolcode/src/parser/actions.pm | 11 ---
runtime/parrot/library/Parrot/Capture_PIR.pir | 14 ++
4 files changed, 48 insertions(+), 7 deletions(-)diff --git a/compilers/pct/src/PCT/Node.pir b/compilers/pct/src/PCT/Node.pir
index 1830868..43d7c10 100644
--- a/compilers/pct/src/PCT/Node.pir
+++ b/compilers/pct/src/PCT/Node.pir
@@ -106,10 +106,20 @@ children and attributes. Returns the newly created node.
Add C to the beginning of the invocant's list of children.
+=item shift()
+
+Remove the first child from the invocant's list of children.
+Returns the child.
+
=item push(child)
Add C to the end of the invocant's list of children.
+=item pop()
+
+Remove the last child from the invocant's list of children.
+Returns the child.
+
=cut
.sub 'unshift' :method
@@ -117,11 +127,21 @@ Add C to the end of the invocant's list of children.
unshift self, value
.end
+.sub 'shift' :method
+$P0 = shift self
+.return ($P0)
+.end
+
.sub 'push' :method
.param pmc value
push self, value
.end
+.sub 'pop' :method
+$P0 = pop self
+.return ($P0)
+.end
+
=item push_new(class, [child1, child2, ..., ] [attr1=>val1, attr2=>val2, ...])
diff --git a/docs/pdds/pdd26_ast.pod b/docs/pdds/pdd26_ast.pod
index 64ba0ac..738628d 100644
--- a/docs/pdds/pdd26_ast.pod
+++ b/docs/pdds/pdd26_ast.pod
@@ -61,10 +61,20 @@ Returns the newly created node.
Add C to the end of the node's array of children.
+=item pop()
+
+Remove the last child from the node's array of children.
+Returns the child.
+
=item unshift(child)
Add C to the beginning of the node's array of children.
+=item shift()
+
+Remove the first child from the node's array of children.
+Returns the child.
+
=item iterator( )
Return a newly initialized C for the node's list
diff --git a/languages/lolcode/src/parser/actions.pm b/languages/lolcode/src/parser/actions.pm
index 6c9b06c..3c14cc9 100644
--- a/languages/lolcode/src/parser/actions.pm
+++ b/languages/lolcode/src/parser/actions.pm
@@ -97,15 +97,12 @@ method function($/) {
make $past;
}
-# Because we must bind the first to IT, we can't immediately
-# add $expr to $past. The code would probably be more clear if PAST::Node
-# supported shift() in addition to unshift().
method ifthen($/) {
my $count := +$ - 1;
my $expr := $( $[$count] );
my $then := $( $[$count] );
$then.blocktype('immediate');
-my $past := PAST::Op.new( $then,
+my $past := PAST::Op.new( $expr, $then,
:pasttype('if'),
:node( $/ )
);
@@ -115,21 +112,21 @@ method ifthen($/) {
$past.push( $else );
}
while ($count != 0) {
-$past.unshift( $expr );
$count := $count - 1;
$expr := $( $[$count] );
$then := $( $[$count] );
$then.blocktype('immediate');
-$past := PAST::Op.new( $then, $past,
+$past := PAST::Op.new( $expr, $then, $past,
:pasttype('if'),
:node( $/ )
);
}
+$expr := $past.shift();
my $it := PAST::Var.new( :name( 'IT' ), :scope('lexical'), :viviself('Undef'));
-$past.unshift( $it );
my $bind := PAST::Op.new( :pasttype('bind'), :node( $/ ) );
$bind.push( $it );
$bind.push( $expr );
+$past.unshift( $it );
my $past := PAST::Stmts.new( $bind, $past, :node( $/ ) );
make $past;
}
diff --git a/runtime/parrot/library/Parrot/Capture_PIR.pir b/runtime/parrot/library/Parrot/Capture_PIR.pir
index 0c89adb..8647f53 100644
--- a/runtime/parrot/library/Parrot/Capture_PIR.pir
+++ b/runtime/parrot/library/Parrot/Capture_PIR.pir
@@ -44,6 +44,13 @@ version until the Capture PMC is working properly.
.end
+.sub 'shift_pmc' :vtable :method
+$P0 = self.'get_array'()
+$P0 = shift $P0
+.return ($P0)
+.end
+
+
.sub 'push_pmc' :vtable :method
.param pmc val
$P0 = self.'get_array'()
@@ -52,6 +59,13 @@ version until the Capture PMC is working properly.
.end
+.sub 'pop_pmc' :vtable :method
+$P0 = self.'get_array'()
+$P0 = pop $P0
+.return ($P0)
+.end
+
+
.sub 'get_string_keyed_int' :vtable :method
.param int key
$S0 = ''
[svn:parrot-pdd] r25121 - trunk/docs/pdds
Author: jkeenan Date: Mon Jan 21 19:26:51 2008 New Revision: 25121 Modified: trunk/docs/pdds/pdd09_gc.pod Log: Correct POD formatting errors in two locations: incorrect use of '=for' blocks. Modified: trunk/docs/pdds/pdd09_gc.pod == --- trunk/docs/pdds/pdd09_gc.pod(original) +++ trunk/docs/pdds/pdd09_gc.podMon Jan 21 19:26:51 2008 @@ -250,12 +250,9 @@ as being on the free list with the C. =for question - Are the PMCs in the arena examined back-to-front as well? How about Buffers? Order of destruction can be important. -=end for - =head3 Collecting buffers To collect buffers, each Buffer arena is examined from the most recently @@ -331,12 +328,9 @@ execution-time to accommodate different work loads. =for question - Does "execution-time" mean "before starting a runcore" or "at some point after starting a runcore"? -=end question - Each GC core provides a standard interface for interaction with the core. =head3 Initialization
Re: [perl #50066] [BUG] $LIBPARROT_STATIC macro not expanded properly when building pbc_to_exe
On 22/01/2008, chromatic <[EMAIL PROTECTED]> wrote: > On Monday 21 January 2008 08:58:25 Paul Cochrane wrote: > > > when building parrot on Solaris I get most of the way through the > > build, but right at the end, building pbc_to_exe fails with the > > following output: > > > It seems that the Makefile macro $(LIBPARROT_STATIC) isn't being > > expanded. I had a bit of a look around and found the following lines > > in config_lib.pasm (which is used for the configuration information > > necessary to build pbc_to_exe): > > > > set P0["libparrot"], "$(LIBPARROT_STATIC)" > > set P0["libparrot_ldflags"], "$(LIBPARROT_STATIC)" > > > > further digging showed that these values are set within > > config/inter/libparrot.pm, and the code in there seems perfectly sane > > (especially considering that the value would be later expanded by > > make). Unfortunately, from here I don't know where else to look to > > solve the problem, however it is stopping me from building parrot on > > the Solaris platform at present. > > Are you building Parrot as static or shared? What happens if you switch to > shared? I'm just using C to configure the build, and it's setting the build to be static. Using C doesn't make a difference as Configure still determines that it's not building a shared parrot. > Is LIBPARROT_STATIC defined correctly in your Makefile? LIBPARROT_STATIC = blib/lib/libparrot.a This looks good to me. This is the value I would expect the C configuration value to be expanded to in config_lib.pasm. However, LIBPARROT is in the Makefile: LIBPARROT = $(LIBPARROT_STATIC) Which I would guess comes directly from the configured value, and hence why the value is carried over to config_lib.pasm, although I'm confused as to why this issue of not having an expanded value only occurs on Solaris and not on other Unix based systems. Paul
Re: [perl #50066] [BUG] $LIBPARROT_STATIC macro not expanded properly when building pbc_to_exe
On Jan 22, 2008 2:38 AM, Paul Cochrane <[EMAIL PROTECTED]> wrote: > > On 22/01/2008, chromatic <[EMAIL PROTECTED]> wrote: > > On Monday 21 January 2008 08:58:25 Paul Cochrane wrote: > > > > > when building parrot on Solaris I get most of the way through the > > > build, but right at the end, building pbc_to_exe fails with the > > > following output: > > > > > It seems that the Makefile macro $(LIBPARROT_STATIC) isn't being > > > expanded. I had a bit of a look around and found the following lines > > > in config_lib.pasm (which is used for the configuration information > > > necessary to build pbc_to_exe): > > > > > > set P0["libparrot"], "$(LIBPARROT_STATIC)" > > > set P0["libparrot_ldflags"], "$(LIBPARROT_STATIC)" > > > > > > further digging showed that these values are set within > > > config/inter/libparrot.pm, and the code in there seems perfectly sane > > > (especially considering that the value would be later expanded by > > > make). Unfortunately, from here I don't know where else to look to > > > solve the problem, however it is stopping me from building parrot on > > > the Solaris platform at present. > > > > Are you building Parrot as static or shared? What happens if you switch to > > shared? > > I'm just using C to configure the build, and it's > setting the build to be static. Using C --parrot_is_shared> doesn't make a difference as Configure still > determines that it's not building a shared parrot. > > > Is LIBPARROT_STATIC defined correctly in your Makefile? > > LIBPARROT_STATIC = blib/lib/libparrot.a > > This looks good to me. This is the value I would expect the > C configuration value to be expanded to in config_lib.pasm. > However, LIBPARROT is in the Makefile: > > LIBPARROT = $(LIBPARROT_STATIC) > > Which I would guess comes directly from the configured value, and > hence why the value is carried over to config_lib.pasm, although I'm > confused as to why this issue of not having an expanded value only > occurs on Solaris and not on other Unix based systems. > it seems to me the issue is that nobody else builds static by default, or at all. so this code that's about a week old hasn't been tested via every code path, until you came along. it's rather annoying that some variables in Parrot::Config::Generated contain make-related variable expansion values, and others contain literal values, and that it's impossible to tell by the variable name which type the value may be. however, changing that means changing configure and a bunch of makefiles and code generators, which is no small task, so it has remained undone. sure would be nice, though, because then i'm sure the code you're running in pbc_to_exe would have worked for both static and shared builds of parrot. i'm still not sure what the best short-term solution is. i suppose we need to add a new variable during configure time, with the expanded value of LIBPARROT in it. we could call it LIBPARROT_X (_X for expanded,) but i'd rather put a suffix on variables containing makefile variable expansions, because they're less-frequently used, in my opinion. i'm interested in what other folks think on this matter. ~jerry
My valgrinder
uniqua:~ $ cat ~/bin/vgr #!/bin/sh make perl6 valgrind \ --suppressions=/home/andy/parrot/tools/dev/parrot.supp \ --num-callers=500 \ --leak-check=full \ --leak-resolution=high \ --show-reachable=yes \ ./parrot --leak-test languages/perl6/perl6.pbc -e 'say "Hello, world!"' 2>&1 | perl -p -e's/^==\d+==//' Dropping the leading process number leaves pure stack trace goodness, suitable for diffing between runs. -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: [perl #48971] Parrot build failure "no such instruction: `trap'"
New release 0.5.2 (r25150) still fails to build on PPC running OSX
10.5.1. Same version of perl as listed previously in the bug report.
The same error is issued:
...
perl tools/build/c2str.pl --all
src/string.c
src/ops/core_ops.c
src/ops/debug.ops: In function ‘Parrot_debug_break’:
src/ops/debug.ops:103: warning: null argument where non-null required
(argument 2)
src/ops/debug.ops:113: warning: null argument where non-null required
(argument 2)
src/ops/debug.ops: In function ‘Parrot_debug_break’:
src/ops/debug.ops:103: warning: null argument where non-null required
(argument 2)
src/ops/debug.ops:113: warning: null argument where non-null required
(argument 2)
{standard input}:83575:no such instruction: `trap'
lipo: can't open input file: /var/folders/z9/z9oKoAkrEqiMhue-QoqwG+++
+TI/-Tmp-//ccu2CUMR.out (No such file or directory)
make: *** [src/ops/core_ops.o] Error 1
Cheers,
Walter Szeliga
Re: [perl #50018] [BUG] rakudo segfaults after "No scope found for PAST::Var" error
Edwin Steiner (via RT) wrote: I found that rakudo segfaults when the following statements are executed interactively: Oops, I told RT but I didn't tell p6i: This is the same bug as #49758; merging tickets. -- Grr... don't get me started on Wagner. The man couldn't resolve a dominant seventh to a tonic with two musical dictionaries open to the word "resolution", and a copy of anything by Muddy Waters. - Eric the Read, in the monastery.
Strange casts in packfile/pf_items.c
Hello I'm trying to clean some warnings in parrot C source files and found this casts in packfile/pf_items.c: fetch_buf_le_8(u.buf, (unsigned char *) b); fetch_buf_be_8(u.buf, (unsigned char *) b); But the function definitions are (in src/byteorder.c): void fetch_buf_le_8(ARGOUT(unsigned char *rb), ARGIN(const unsigned char *b)) void fetch_buf_be_8(ARGOUT(unsigned char *rb), ARGIN(const unsigned char *b)) And 'b' in both calls is already const unsigned char *. Deleting the casts avoids the warnings, There is some obscure reason for those casts, or remains from an old situation? -- Salu2
[Re: [perl #49912] [BUG] Unable to Configure using Borland C]
Glimmerings of a hint of progress. Adding --miniparrot to the command line: C:\parrot>Configure.pl --cc=bcc32 --miniparrot bypasses the test that hangs. This enables "make" to fall on its face with the following message: C:\parrot>make MAKE Version 5.2 Copyright (c) 1987, 2000 Borland Error makefile 2306: Redefinition of target 'compilers\imcc\main.obj' *** 1 errors during make *** Any suggestions for further floundering would be welcome. -- Email and shopping with the feelgood factor! 55% of income to good causes. http://www.ippimail.com
[perl #50118] [TODO] convert Perl6Str to be just 'Str'
# New Ticket Created by Patrick R. Michaud # Please include the string: [perl #50118] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=50118 > Currently rakudo has a Perl6Str PMC type, which is then subclassed into a 'Str' class. We should just change Perl6Str to be 'Str' in the PMC type, and avoid the extra class. Pm
[perl #50056] [BUG] "Undefined symbols" on OS X
>From http://osdir.com/ml/lib.libtom/2005-01/msg00010.html: "By default common symbols are not included in static archive table of contents. If you use the ranlib(1) -c option you can get Linux behavior." And from 'man ranlib' on 10.4.11: -c Include common symbols as definitions with respect to the table of contents. This is seldom the intended behavior for linking from a library, as it forces the linking of a library member just because it uses an uninitialized global that is undefined at that point in the linking. This option is included only because this was the original behavior of ranlib. This option is not the default.
Re: S29 doubts that need clarification
On Mon, Jan 21, 2008 at 11:24:52PM +0100, Cosimo Streppone wrote: > Hi all, > > I'm in the process of refactoring existing pugs test suite, > for example t/builtins, into t/spec/S29-. > > Questions: > > - @array.uniq is not mentioned in S29. > Should it be in S29/List? or S29/Array? List, where you have already put it, I see. :) > - cis(), polar() and friends belong to S29/Num > while they should probably belong to S29/Complex? There are conflicting theories on this. S29 tends to be structured around which class the method would live in, so it has cis in Num and polar in Complex. Another theory is that documentation about exotic types like Complex should be all grouped in one spot regardless of which way the types are, since Num obviously has enough problems of its own without getting into Complex issues. :) I'd say for the test suite the latter theory would tend to keep everything from ending up in one huge Num test file. But it doesn't really matter. By the way, see http://www.perlmonks.org/?node_id=444996 on the difference between "doubt" and "question". In English it comes across as if you are "disbelieving" S29. Which maybe you are, but I doubt it. Anyway, it's one of those spots where cognates can lead you astray because of semantic shifts. Similarly, "demand" means something different to English and French speakers. (When the Norman conquerors came over and "asked" for something, not giving it to them was not considered an option. :) Larry
Re: [perl #50056] [BUG] "Undefined symbols" on OS X
On Tuesday 22 January 2008 15:20:25 Allison Randal via RT wrote: > From http://osdir.com/ml/lib.libtom/2005-01/msg00010.html: > > "By default common symbols are not included in static > archive table of contents. If you use the ranlib(1) -c > option you can get Linux behavior." > > And from 'man ranlib' on 10.4.11: > > -c Include common symbols as definitions with respect to the table > of contents. This is seldom the intended behavior for linking from a > library, as it forces the linking of a library member just because it > uses an uninitialized global that is undefined at that point in > the linking. This option is included only because this was the > original behavior of ranlib. This option is not the default. Are you building a static or a shared binary? Did this problem only show up after Coke switched the default to shared? -- c
[perl #49912] [BUG] Unable to Configure using Borland C
On Tue Jan 22 14:02:30 2008, ajr wrote: > > Any suggestions for further floundering would be welcome. > Well, here's one thought. You could try running Configure.pl with the addition of the --configure_trace option. Read the POD for Parrot::Configure::Trace to see how you would then be able to trace the evolution of specific values inside the Parrot::Configure object as you go through the 60+ config steps. Caveat: Every time I've used P::C::Trace, it's been on a configuration that completed successfully and hence resulted in a well-formed trace file at the end of configuration. Don't know how it will work if you get a failure *during* configuration as opposed to during 'make'.
[svn:perl6-synopsis] r14493 - doc/trunk/design/syn
Author: larry Date: Tue Jan 22 16:17:20 2008 New Revision: 14493 Modified: doc/trunk/design/syn/S03.pod Log: Clarification of timing and defaults for initializing various declarators Modified: doc/trunk/design/syn/S03.pod == --- doc/trunk/design/syn/S03.pod(original) +++ doc/trunk/design/syn/S03.podTue Jan 22 16:17:20 2008 @@ -12,9 +12,9 @@ Maintainer: Larry Wall <[EMAIL PROTECTED]> Date: 8 Mar 2004 - Last Modified: 2 Jan 2008 + Last Modified: 22 Jan 2008 Number: 3 - Version: 126 + Version: 127 =head1 Overview @@ -3580,8 +3580,7 @@ Variable declarators such as C now take a I as their argument. (The syntax of function signatures is described more fully in S06.) - -The parentheses around the signature may be omitted for a +As in the examples above, the parentheses around the signature may be omitted for a simple declaration that declares a single variable, along with its associated type, traits and the initializer: @@ -3590,7 +3589,28 @@ constant :($foo = 123); # same thing (full Signature form) constant ($foo) = 123; # wrong: constants cannot be assigned to -List-context assignment is supported for simple declarations: +Each declarator can take an initializer following an equals +sign (which should not be confused with a normal assignment, because +the timing of the initialization depends on the natural lifetime of the +container, which in turn depends on which declarator you use). + +my $foo = 1; # happens at the same time as normal assignment +our $foo = 1;# happens at INIT time +has $foo = 1;# happens at BUILD time +state $foo = 1; # happens at START time +constant $foo = 1; # happens at BEGIN time + +If you do not initialize a container, it starts out undefined at the +beginning of its natural lifetime. (In other words, you can't use +the old Perl 5 trick of "C" to get a static variable, +because a C variable starts out uninitialized every time through +in Perl 6 rather than retaining its previous value.) Native integer +containers that do not support the concept of undefined should be +initialized to 0 instead. (Native floating-point containers are +by default initialized to C.) Typed object containers start +out containing an undefined protoobject of the correct type. + +List-context pseudo-assignment is supported for simple declarations: constant @foo = 1,2,3; # okay: initializes @foo to (1,2,3) constant (@foo = 1,2,3);# wrong: 2 and 3 are not variable names
[perl #49912] [BUG] Unable to Configure using Borland C
On Tue Jan 22 14:02:30 2008, ajr wrote: > > Glimmerings of a hint of progress. > > Adding --miniparrot to the command line: > > C:\parrot>Configure.pl --cc=bcc32 --miniparrot > > bypasses the test that hangs. That's not too surprising, as a look into the configuration step classes will show. In config/init/miniparrot.pm, we find this documentation: "Modifies settings to match miniparrot (ANSI C Parrot)'s needs. This step primarily overwrites a lot of settings in the Configure database to disable JIT and match ANSI characteristics." And in many of the later config step classes, calling Configure.pl with --miniparrot short-circuits causes such classes to be essentially skipped. > This enables "make" to fall on its face with > the following message: > > C:\parrot>make > MAKE Version 5.2 Copyright (c) 1987, 2000 Borland > Error makefile 2306: Redefinition of target 'compilers\imcc\main.obj' > *** 1 errors during make *** > > Any suggestions for further floundering would be welcome. > Unfortunately, I have no experience with Borland specifically or C-compilers on Win32 more generally. Any of our Win32 gurus out there? kid51 > -- > > Email and shopping with the feelgood factor! > 55% of income to good causes. http://www.ippimail.com >
[perl #49912] [BUG] Unable to Configure using Borland C
On Tue Jan 22 14:02:30 2008, ajr wrote: > > Any suggestions for further floundering would be welcome. > Well, here's one thought. You could try running Configure.pl with the addition of the --configure_trace option. Read the POD for Parrot::Configure::Trace to see how you would then be able to trace the evolution of specific values inside the Parrot::Configure object as you go through the 60+ config steps. Caveat: Every time I've used P::C::Trace, it's been on a configuration that completed successfully and hence resulted in a well-formed trace file at the end of configuration. Don't know how it will work if you get a failure *during* configuration as opposed to during 'make'.
[perl #50056] [BUG] "Undefined symbols" on OS X
On Tue Jan 22 15:38:11 2008, [EMAIL PROTECTED] wrote: > > Are you building a static or a shared binary? Did this problem only > show up after Coke switched the default to shared? Shared. I don't know the exact timing of the change in relation to the failure starting. But, changing config/init/hints/darwin.pm back to static by default, with a 'realclean' recompile doesn't work either. Still get "Undefined symbols" errors: c++ -o pbc_to_exe pbc_to_exe.o -L/usr/local/lib -L/opt/local/lib -L/sw/lib -L/sw/lib -L/opt/local/lib -L/sw/lib $(LIBPARROT_STATIC) -lm -lgmp -lreadline /Users/allison/projects/svn/parrot/src/parrot_config.o sh: line 1: LIBPARROT_STATIC: command not found /usr/bin/ld: Undefined symbols: _PackFile_fixup_subs [...] collect2: ld returned 1 exit status linking failed current instr.: 'link_file' pc 752 (pbc_to_exe.pir:365) called from Sub 'main' pc 124 (pbc_to_exe.pir:32) It does work if I manually substitute "blib/lib/libparrot.a" for LIBPARROT_STATIC in the compile command-line: c++ -o pbc_to_exe pbc_to_exe.o -L/usr/local/lib -L/opt/local/lib -L/sw/lib -L/sw/lib -L/opt/local/lib -L/sw/lib blib/lib/libparrot.a -lm -lgmp -lreadline /Users/allison/projects/svn/parrot/src/parrot_config.o
[svn:perl6-synopsis] r14494 - doc/trunk/design/syn
Author: larry Date: Tue Jan 22 16:29:21 2008 New Revision: 14494 Modified: doc/trunk/design/syn/S03.pod Log: More tweaks, typos, clarification that "our" differs from in Perl 5 Modified: doc/trunk/design/syn/S03.pod == --- doc/trunk/design/syn/S03.pod(original) +++ doc/trunk/design/syn/S03.podTue Jan 22 16:29:21 2008 @@ -23,7 +23,7 @@ =head1 Operator precedence Not counting terms and terminators, Perl 6 has 23 operator precedence -levels (same as Perl 5, but differently arranged). Here we list the +levels (same as Perl 5, but differently arranged). Here we list the levels from "tightest" to "loosest", along with a few examples of each level: @@ -1348,7 +1348,7 @@ =item * -C<< infix:«p5=>» >>, the Perl 5 fatarrow +C<< infix:«p5=>» >>, the Perl 5 fatarrow This operator, which behaves exactly like the Perl 5 fatarrow in being equivalent to a comma, is purely for easier migration from Perl 5 @@ -3580,14 +3580,15 @@ Variable declarators such as C now take a I as their argument. (The syntax of function signatures is described more fully in S06.) -As in the examples above, the parentheses around the signature may be omitted for a + +The parentheses around the signature may be omitted for a simple declaration that declares a single variable, along with its associated type, traits and the initializer: -constant $foo = 123;# okay: initializes $foo to 123 -constant ($foo = 123); # same thing (with explicit parens) -constant :($foo = 123); # same thing (full Signature form) -constant ($foo) = 123; # wrong: constants cannot be assigned to +constant Dog $foo is woof = 123;# okay: initializes $foo to 123 +constant (Dog $foo is woof = 123); # same thing (with explicit parens) +constant :(Dog $foo is woof = 123); # same thing (full Signature form) +constant (Dog $foo is woof) = 123; # wrong: constants cannot be assigned to Each declarator can take an initializer following an equals sign (which should not be confused with a normal assignment, because @@ -3600,11 +3601,15 @@ state $foo = 1; # happens at START time constant $foo = 1; # happens at BEGIN time +(Note that the semantics of C are different from Perl 5, where the +initialization happens at the same time as a C. To get the same +effect in Perl 6 you'd have to say "c<(our $foo) = 1;>" instead.) + If you do not initialize a container, it starts out undefined at the beginning of its natural lifetime. (In other words, you can't use -the old Perl 5 trick of "C" to get a static variable, +the old Perl 5 trick of "C" to get a static variable, because a C variable starts out uninitialized every time through -in Perl 6 rather than retaining its previous value.) Native integer +in Perl 6 rather than retaining its previous value.) Native integer containers that do not support the concept of undefined should be initialized to 0 instead. (Native floating-point containers are by default initialized to C.) Typed object containers start
Re: [svn:perl6-synopsis] r14494 - doc/trunk/design/syn
Wait. There are two different phases called START and BEGIN? That's going to be a little confusing Which one comes first? Are there both END and STOP phases as well? On 1/22/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Author: larry > Date: Tue Jan 22 16:29:21 2008 > New Revision: 14494 > > Modified: >doc/trunk/design/syn/S03.pod > > Log: > More tweaks, typos, clarification that "our" differs from in Perl 5 > > > Modified: doc/trunk/design/syn/S03.pod > == > --- doc/trunk/design/syn/S03.pod (original) > +++ doc/trunk/design/syn/S03.pod Tue Jan 22 16:29:21 2008 > @@ -23,7 +23,7 @@ > =head1 Operator precedence > > Not counting terms and terminators, Perl 6 has 23 operator precedence > -levels (same as Perl 5, but differently arranged). Here we list the > +levels (same as Perl 5, but differently arranged). Here we list the > levels from "tightest" to "loosest", along with a few examples of > each level: > > @@ -1348,7 +1348,7 @@ > > =item * > > -C<< infix:«p5=>» >>, the Perl 5 fatarrow > +C<< infix:«p5=>» >>, the Perl 5 fatarrow > > This operator, which behaves exactly like the Perl 5 fatarrow in being > equivalent to a comma, is purely for easier migration from Perl 5 > @@ -3580,14 +3580,15 @@ > > Variable declarators such as C now take a I as their > argument. (The syntax of function signatures is described more fully in > S06.) > -As in the examples above, the parentheses around the signature may be > omitted for a > + > +The parentheses around the signature may be omitted for a > simple declaration that declares a single variable, along with its > associated type, traits and the initializer: > > -constant $foo = 123;# okay: initializes $foo to 123 > -constant ($foo = 123); # same thing (with explicit parens) > -constant :($foo = 123); # same thing (full Signature form) > -constant ($foo) = 123; # wrong: constants cannot be assigned to > +constant Dog $foo is woof = 123;# okay: initializes $foo to 123 > +constant (Dog $foo is woof = 123); # same thing (with explicit parens) > +constant :(Dog $foo is woof = 123); # same thing (full Signature form) > +constant (Dog $foo is woof) = 123; # wrong: constants cannot be > assigned to > > Each declarator can take an initializer following an equals > sign (which should not be confused with a normal assignment, because > @@ -3600,11 +3601,15 @@ > state $foo = 1; # happens at START time > constant $foo = 1; # happens at BEGIN time > > +(Note that the semantics of C are different from Perl 5, where the > +initialization happens at the same time as a C. To get the same > +effect in Perl 6 you'd have to say "c<(our $foo) = 1;>" instead.) > + > If you do not initialize a container, it starts out undefined at the > beginning of its natural lifetime. (In other words, you can't use > -the old Perl 5 trick of "C" to get a static variable, > +the old Perl 5 trick of "C" to get a static variable, > because a C variable starts out uninitialized every time through > -in Perl 6 rather than retaining its previous value.) Native integer > +in Perl 6 rather than retaining its previous value.) Native integer > containers that do not support the concept of undefined should be > initialized to 0 instead. (Native floating-point containers are > by default initialized to C.) Typed object containers start > -- Mark J. Reed <[EMAIL PROTECTED]>
Re: [svn:perl6-synopsis] r14494 - doc/trunk/design/syn
On Tue, Jan 22, 2008 at 07:47:15PM -0500, Mark J. Reed wrote: : Wait. There are two different phases called START and BEGIN? That's : going to be a little confusing Which one comes first? : Are there both END and STOP phases as well? BEGIN/CHECK/INIT/END are just as in Perl 5. For the rest, see: http://perlcabal.org/syn/S04.html#Closure_traits In short, closure blocks *typically* happen in this order: BEGIN (right now at compile time) UNITCHECK (at end of this compilation unit) CHECK (at end of main compilation) (compile time finishes) ...time passes... (run time starts) INIT (main starts running) ENTER (every block entry) START (first time through only) LEAVE (every block exit) (main finishes running) END See S04 for when the other more specialized closure blocks get called. Larry
[svn:perl6-synopsis] r14495 - doc/trunk/design/syn
Author: larry Date: Tue Jan 22 18:07:38 2008 New Revision: 14495 Modified: doc/trunk/design/syn/S04.pod Log: Clarify that START is allowed to use parameter values on first call while INIT is not. Modified: doc/trunk/design/syn/S04.pod == --- doc/trunk/design/syn/S04.pod(original) +++ doc/trunk/design/syn/S04.podTue Jan 22 18:07:38 2008 @@ -12,9 +12,9 @@ Maintainer: Larry Wall <[EMAIL PROTECTED]> Date: 19 Aug 2004 - Last Modified: 7 Dec 2007 + Last Modified: 22 Jan 2008 Number: 4 - Version: 62 + Version: 63 This document summarizes Apocalypse 4, which covers the block and statement syntax of Perl. @@ -999,6 +999,8 @@ last possible moment, then runs exactly once, and caches its value for all subsequent calls (assuming it wasn't called in void context, in which case the C is evaluated once only for its side effects). +In particular, this means that C can make use of any parameters +passed in on the first call, whereas C cannot. All of these trait blocks can see any previously declared lexical variables, even if those variables have not been elaborated yet when
Re: [svn:perl6-synopsis] r14494 - doc/trunk/design/syn
On Tue, Jan 22, 2008 at 05:55:35PM -0800, Larry Wall wrote: : http://perlcabal.org/syn/S04.html#Closure_traits Or since that's kind of hard to follow the text, you may prefer to read the original POD without the interpolated test results at: https://svn.perl.org/perl6/doc/trunk/design/syn/S04.pod Larry
