Re: relationship between slurpy parameters and named args?
Stuart Cook <[EMAIL PROTECTED]> writes: > On 29/12/05, Austin Frank <[EMAIL PROTECTED]> wrote: >> So, is there a conceptual connection between imposing named argument >> interpretation on pairs in an arg list and slurping up the end of a >> parameter list? Are there other meanings of prefix:<*> that relate to >> one or the other of these two meanings? > > The missing link is that prefix:<*> in an argument list also causes > things like arrays to be treated as a sequence of separate parameters, > rather than as a single array parameter. See "Flattening argument > lists" in S06. > > (This was the original meaning of prefix:<*> in arglists; the > named-pair behaviour was added later, when pair values ceased to have > named behaviour automatically.) Personally, I think that prefix * in an arglist should only flatten array arguments if there is only one array. And if it doesn't, how do I declare parameter that is 'a slurpy list of arrays' or 'the rest of the arguments, without flattening'. If I *really* want aggressive flattening then I can call, say, @slurpy_param.flatten -- Piers Cawley <[EMAIL PROTECTED]> http://www.bofh.org.uk/
[perl #38072] [PATCH] TCL - make [string compare] work
# New Ticket Created by Alberto Simoes
# Please include the string: [perl #38072]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=38072 >
Note that this patch does not fixes the failing tests added by Coke on
last commit, as I'm not sure I agree with his changes.
--
Alberto Simões - Departamento de Informática - Universidade do Minho
Campus de Gualtar - 4710-057 Braga - Portugal
Index: languages/tcl/t/cmd_string.t
===
--- languages/tcl/t/cmd_string.t(revision 10785)
+++ languages/tcl/t/cmd_string.t(working copy)
@@ -3,10 +3,11 @@
use strict;
use lib qw(tcl/t t . ../lib ../../lib ../../../lib);
-use Parrot::Test tests => 115;
+use Parrot::Test tests => 133;
use Parrot::Config;
use Test::More;
+
language_output_is("tcl",<
Re: relationship between slurpy parameters and named args?
On 12/30/05, Piers Cawley <[EMAIL PROTECTED]> wrote: > Stuart Cook <[EMAIL PROTECTED]> writes: > > > On 29/12/05, Austin Frank <[EMAIL PROTECTED]> wrote: > >> So, is there a conceptual connection between imposing named argument > >> interpretation on pairs in an arg list and slurping up the end of a > >> parameter list? Are there other meanings of prefix:<*> that relate to > >> one or the other of these two meanings? > > > > The missing link is that prefix:<*> in an argument list also causes > > things like arrays to be treated as a sequence of separate parameters, > > rather than as a single array parameter. See "Flattening argument > > lists" in S06. > > > > (This was the original meaning of prefix:<*> in arglists; the > > named-pair behaviour was added later, when pair values ceased to have > > named behaviour automatically.) > > Personally, I think that prefix * in an arglist should only flatten > array arguments if there is only one array. And if it doesn't, how do > I declare parameter that is 'a slurpy list of arrays' or 'the rest > of the arguments, without flattening'. If I *really* want aggressive > flattening then I can call, say, @slurpy_param.flatten Does this imply that [EMAIL PROTECTED] === @slurpy.flatten ? Or, put another way, can't we just say that prefixed * is symbolic notation for flatten() in the same way that postfixed [] is symbolic notation for slice()? Rob
Re: Most Perl6 developers running linux on i386?
Perl6ers, What is the most commonly used development platform (os and machine) by folks on this group? PeterS Steve Peters wrote: On Wed, Dec 28, 2005 at 09:50:49PM -0500, Peter Schwenn wrote: I've spent a couple of days trying out Cygwin, MinGW, PXPerl, and other Windows based contexts, in order to build Pugs w/Embedded Parrot. I've learned a lot about configuration and little else. Would I be right in supposing that most people working on Perl6 and Parrot development, and spend relatively little time jiggering configs and makes, are working under Linux on i386 machines? (excluding a few who have had plenty of time to get a VS6/7 or Cygwin or ... environment straightened out.) These problems have come and gone over the years as people have taken up the challenge of making Parrot compile and pass its tests on their system. I believe, however, that we've only seen the tip of the iceberg as I don't recall complaints or patches regarding Parrot compiles on z/OS, VMS, BeOS, or some of the other OS's that Perl 5 currently supports. My hope and expectation is that as th various Perl 6 projects start to look more like the end product, more of these issues will come up. I also expect that more active developers will be picked up along the way to deal wtih these problems. So, for me, I'm concerned, but I surely expect that none of these problems on Win32 based systems current is an indication of the level of support to expect from these systems in the future. Steve Peters [EMAIL PROTECTED]
Re: Most Perl6 developers running linux on i386?
On 12/30/05, Peter Schwenn <[EMAIL PROTECTED]> wrote: > What is the most commonly used development platform (os and machine) by > folks on this group? > i can't answer that. i can tell you i use i386-win32-msvc, and sometimes i386-linux-gcc. i know some others are using x86_64-linux-gcc, ppc-darwin-gcc, and others, but they should speak for themselves. i can point you to the results from the smoke reports (http://smoke.parrotcode.org/smoke/) which should show you the most successful platforms testing parrot. there are a number of platforms consistently reporting 99+% success in the test suite, which should give some idea as to their fitness for developing parrot. hope that helps. ~jerry
[RFC] Dynamic binding patch
The attached patch is functionally complete, but I still have a few
loose ends to nail down, so I thought it would be a good time to post it
for review. The issues are as follows:
1. It needs more higher-level documentation. Is compiler_faq.pod
the best place for this?
2. Binding 'foo' to a null PMC should cause find_global to err out
with "Global "foo" not found", but this is not happening.
3. There are no tests for threads or stack-unwinding continuations.
(Yes, I am procrastinating.)
Others issues are marked with dated comments between '[' and ']'.
Comments and criticisms are most welcome -- I haven't much experience
with hacking C. TIA,
-- Bob Rogers
http://rgrjr.dyndns.org/
Index: src/ops/var.ops
===
--- src/ops/var.ops (revision 10791)
+++ src/ops/var.ops (working copy)
@@ -199,6 +199,45 @@
goto NEXT();
}
+=item B(in STR, in PMC)
+
+Bind the PMC $2 as global symbol $1 in the current context. If $2 is a Null
+PMC, then the global is effectively made locally unbound. The newly-created
+dynamic binding will be used by C and C in the
+current dynamic environment only, i.e. this call and all calls made from it.
+[should expand on this. -- rgr, 28-Dec-05.]
+
+Note that there is no C op, as dynamic binding only
+makes sense with respect to an execution context.
+
+=item B(in STR, in STR, in PMC)
+
+Bind the PMC $3 as symbol $2 of namespace $1 in the current context.
+The binding is created whether or not namespace $1 exists already.
+
+=item B(in INT)
+
+Remove zero or more dynamic bindings created in the current
+execution context. The integer value must not be more than
+the number of bindings established during the current call.
+
+=cut
+
+op bind_global(in STR, in PMC) {
+Parrot_bind_global(interpreter, NULL, $1, $2);
+goto NEXT();
+}
+
+op bind_global(in STR, in STR, in PMC) {
+Parrot_bind_global(interpreter, $1, $2, $3);
+goto NEXT();
+}
+
+op unbind_globals(in INT) {
+Parrot_unbind_globals(interpreter, $1);
+goto NEXT();
+}
+
=back
=cut
Index: src/ops/ops.num
===
--- src/ops/ops.num (revision 10791)
+++ src/ops/ops.num (working copy)
@@ -1212,3 +1212,11 @@
find_global_p_p_sc 1182
find_name_p_s 1183
find_name_p_sc 1184
+bind_global_s_p1185
+bind_global_sc_p 1186
+bind_global_s_s_p 1187
+bind_global_sc_s_p 1188
+bind_global_s_sc_p 1189
+bind_global_sc_sc_p1190
+unbind_globals_i 1191
+unbind_globals_ic 1192
Index: src/register.c
===
--- src/register.c (revision 10791)
+++ src/register.c (working copy)
@@ -131,6 +131,7 @@
ctx->bp = interpreter->ctx.bp;
ctx->bp_ps = interpreter->ctx.bp_ps;
ctx->prev = NULL;
+ctx->dynamic_bindings = NULL;
}
#else
@@ -172,6 +173,7 @@
* extenders) are assuming the presence of these registers
*/
Parrot_alloc_context(interpreter, num_regs);
+CONTEXT(interpreter->ctx)->dynamic_bindings = NULL;
}
#endif
@@ -348,6 +350,7 @@
/* returning from main */
return;
}
+Parrot_free_dynamic_bindings(interpreter, ctx, 99);
CONTEXT(ctx)->prev = NULL;
used_ctx_mem = (char *)ctx.bp + sizeof(struct parrot_regs_t);
Index: src/global.c
===
--- src/global.c(revision 10791)
+++ src/global.c(working copy)
@@ -27,34 +27,79 @@
/*
=item C
+Parrot_find_global(Parrot_Interp interpreter, STRING *namespace, STRING
*globalname)>
-If C is NULL search global stash. If C is NULL, return the
-stash PMC.
+Look for a global named C in the namespace named C,
+looking first in the context's dynamic bindings. If C is NULL, then
+search the global stash. Return NULL if the global isn't found.
-Return NULL if the global isn't found or the global.
+If C is NULL, then the dynamic binding search is skipped, and the
+stash PMC itself is returned..
+Note that if the named global has been shadowed by C in some
+calling context, then C will fetch the value from the
+innermost such binding. This, too, could be NULL.
+
=item C
-If the global exists, return it. If not either throw an exception or return an
-C depending on the interpreter's error settings.
+If the global exists (i.e. C returns something other than
+NULL), return it. If not, then either throw an exception or return an
C,
+depending on the interpreter's error settings.
=cut
*/
+static Parrot_DBE *
+find_dynamic_binding(Interp *interpreter, STRING *namespace,
+ STRING *globalname)
+{
+parrot_context_t *ctx = CONTEXT(interpreter->ctx);
[perl #38073] [TODO] Tcl - expr methods with <> 1 arg.
# New Ticket Created by Will Coleda # Please include the string: [perl #38073] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=38073 > $ tclsh % expr atan2(2,3) 0.588002603548 % expr fmod(2.3,.2) 0.1 % expr hypot(3.1,4.1) 5.14003891036 % expr rand() 0.116507004069 Right now, expr only supports single-arg arguments.
[perl #38075] [TODO] Tcl - expr ?:
# New Ticket Created by Will Coleda # Please include the string: [perl #38075] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=38075 > tcl's expr currently only supports unary and binary ops. Adding ternary support can be faked by having both '?' and ':' be binary ops that get processed slightly differently, or perhaps adding a new lib/tclternaryops.pir file/class. See && and || in binary ops for dealing with conditional eval.
[perl #38076] [TODO] - tcl expression compilation
# New Ticket Created by Will Coleda # Please include the string: [perl #38076] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=38076 > [expr] currently generates quite a bit of code for something like: expr 1*2*3*4*5 Since all of those operators are constant, it should be possible to have that expr call be distilled to: .sub foo :anon $P0 = new TclInt $P0 = 120 .return($P0) .end Should probably convert [expr] to be inlined before implementing this.
[perl #38077] [TODO] implement 'pwd' for parrot
# New Ticket Created by Will Coleda # Please include the string: [perl #38077] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=38077 > There is currently no way to determine your current directory from within parrot. A method on a System PMC might be nice.
[perl #38078] [TODO] implement 'chdir' for parrot
# New Ticket Created by Will Coleda # Please include the string: [perl #38078] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=38078 > There is currently no way to change your current directory from within parrot. A method on a System PMC might be nice.
[perl #38079] [TODO] Tcl - implement [pwd]
# New Ticket Created by Will Coleda # Please include the string: [perl #38079] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=38079 > http://www.tcl.tk/man/tcl8.5/TclCmd/pwd.htm
[perl #38080] [TODO] Tcl - implement [cd]
# New Ticket Created by Will Coleda # Please include the string: [perl #38080] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=38080 > http://www.tcl.tk/man/tcl8.5/TclCmd/cd.htm
[perl #38074] [TODO] Tcl - expr - unknown math functions
# New Ticket Created by Will Coleda # Please include the string: [perl #38074] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=38074 > $ tclsh # RIGHT % expr fink() unknown math function "fink" $ make tclsh #WRONG % expr fink() fink
[perl #38081] [TODO] Tcl - add TclComment compiler class
# New Ticket Created by Will Coleda # Please include the string: [perl #38081] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=38081 > Add compiled TclComment objects, which do nothing other than generate PIR comments with the same text. will require hooks in the parser, and a new lib/tclcomment.pir
[perl #38082] [TODO] Tcl - implement [pwd]
# New Ticket Created by Will Coleda # Please include the string: [perl #38082] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=38082 > http://www.tcl.tk/man/tcl8.5/TclCmd/pwd.htm
Re: [perl #38076] [TODO] - tcl expression compilation
On Dec 30, 2005, at 20:54, Will Coleda (via RT) wrote: [expr] currently generates quite a bit of code for something like: expr 1*2*3*4*5 Since all of those operators are constant, it should be possible to have that expr call be distilled to: .sub foo :anon $P0 = new TclInt $P0 = 120 .return($P0) .end Should probably convert [expr] to be inlined before implementing this. Yep. I think it should compile to (pseudocode): expr = find_name 'expr' # or whatever if expr == builtin_expr # dummy sub constant PMC t0 = 5*6 t1 = t0 * 4 t2 = t1 * 3 ... result = tn else result = expr(expr_string) That is: - let Parrot do the work of constant propagation - don't call a function for compilable code, when not needed - inline it my 2 c leo
[perl #38084] [TODO] Tcl - inline [proc]
# New Ticket Created by Will Coleda # Please include the string: [perl #38084] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=38084 > proc already does compile, but immediately executes the sub. should instead pass along the generated code for deferred compilation. NB: all compilation in tcl currently assumes that the end result will wrap the generated code into a single sub: we must extend the compilation process to allow for the specification of deferred code. (This should get its own ticket.)
[perl #38086] [TODO] Tcl - inline [expr]
# New Ticket Created by Will Coleda # Please include the string: [perl #38086] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=38086 > While expr is already acting as a compiler, it immediately executes the generated PIR (ala [proc]) It should instead return the text of the PIR .sub it generates and have that tacked on to the end of the compilation process.
[perl #38087] [TODO] Tcl -inline [puts]
# New Ticket Created by Will Coleda
# Please include the string: [perl #38087]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=38087 >
convert [puts] to an inlined variant. This would be a good inline to
experiment with some optimizations: For example, if someone calls:
puts -nonewline {Hello World}
That can be pretty well optimized, as opposed to:
set a "-nonewline"
set b "Hello [set c World]"
puts $a $b
[perl #38063] [TODO] Tcl: Correctly convert to a number or string in [expr]
This is done as of r10803.
[perl #38088] [TODO] Tcl - Format PIR output from --pir
# New Ticket Created by Matt Diephouse # Please include the string: [perl #38088] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=38088 > While not necessary, it'd be nice from a debugging standpoint to generate nicely formatted PIR when given the --pir option. The easiest way to do this is probably to write something that indents PIR code based on labels, so start_0: print "foo" start_1: print "blah" end_1: print "baz" end_0: is translated to start_0: print "foo" start_1: print "blah" end_1: print "baz" end_0: It would have to take the label names actually created by the compiler into account in order to do this correctly. Alternatively, one could custom-indent code as it was created. But this would require flag checking and sub/method calls, which will slow things down. -- matt diephouse http://matt.diephouse.com
[perl #38089] Tcl - Fix makefile dependencies
# New Ticket Created by Matt Diephouse # Please include the string: [perl #38089] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=38089 > The PMC dependencies in the makefile should be more explicit. *something* is causing things to get rebuilt unecessarily each time "make tclsh" is run. It is very likely due to the build_dynclasses targets that don't specify explicit dependencies. -- matt diephouse http://matt.diephouse.com
[perl #38090] [TODO] Tcl - Use new argument handling from inside [proc]s
# New Ticket Created by Matt Diephouse
# Please include the string: [perl #38090]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=38090 >
Most builtins take a varying number of arguments, so it's hard to use
this there, but for procs without {args} arguments, this error handling
can be help eliminate a chunk of the wrapper script. Throw an exception
*inside* the sub, catch it, and then throw the appropriate tcl exception
about the wrong # of args. See Leo's mail to the p6i list titled:
pdd03 and Overflow/Underflow - r10269
--
matt diephouse
http://matt.diephouse.com
Re: [RFC] Dynamic binding patch
On Dec 30, 2005, at 17:50, Bob Rogers wrote: The attached patch is functionally complete, but I still have a few loose ends to nail down, so I thought it would be a good time to post it for review. The issues are as follows: 1. It needs more higher-level documentation. Is compiler_faq.pod the best place for this? 2. Binding 'foo' to a null PMC should cause find_global to err out with "Global "foo" not found", but this is not happening. 3. There are no tests for threads or stack-unwinding continuations. (Yes, I am procrastinating.) I think I've missed to answer the last one WRT that - sorry. Anyway, here are some comments: - the patch looks really great and seems to cover all aspects to get this running (just a minor nitpick: src/register.c:init_context() is a common place to copy inherited context items) - the patch seems to miss the 'other part' of 'local' i.e. restoring the old contents of a variable, like e.g. described in 'perldoc perlsub' - (whatever the reason is that it's doced there ;) - that is, Perl5 'local' is much more related to Perl6 'let' or 'temp', it's not just hiding a variable, it looks to me much more like undoing temporary damage, which looks to me like STM (w/o the needed synchronization bits) - if the intent is just to temporarly hide a name, then it should be ok (but not refer to 'local' at all) I think it needs more thoughts and more (common) infrastructure . leo
[FYI] smoke testing
Please have a look at http://ali.as/pita/ [PITA - The Perl Image Testing Architecture] and how we can use this for further/additional Parrot platform testing. Thanks, leo
Building the documentation that will ship with Perl 6 and Pugs
[Note: Posted to both perl6-language and perl6-documentation. Since perl6-documentation is no longer advertised, I assume follow ups should be posted to perl6-language only]. When Audrey gave a recent talk to Sydney.pm, she pointed out some deficiencies in the current Pugs/Perl 6 documentation and asked if I could help. Hence this email. In particular, she noted: * It is way too hard for newbies to come up to speed with p6 and Pugs because the documentation is scattered all over the shop and much of it (e.g. the Apocalypses and Exegeses) is dangerously out of date. * http://dev.perl.org/perl6/ needs updating. * http://www.pugscode.org/ needs updating. * It would be good to now start building the documentation that will eventually ship with Perl6 and Pugs. [Note that Pugs is just one implementation of Perl 6 the language (albeit the leading candidate for "Reference Implementation") thus there is a need for some Pugs-specific documentation.] Needless to add, she proposed that this documentation be built in the Pugs svn repository using the Pugs "anarchic" [TM] development model. After re-acquainting myself with Perl 6/Pugs and researching some Perl 6 documentation history, here are my thoughts: * I'm hopeful that the p6 spec has become stable enough that it now makes sense to press forward with p6 documentation. [It seems the lack of stability of the spec was one reason the "Perl 6 Documentation Project" stalled (list archives: http://www.nntp.perl.org/group/perl.perl6.documentation)]. * Having said that, I feel the Perl 6 spec itself properly belongs with @Larry and any (highly-skilled) volunteers they invite to help them. I doubt the Pugs development model will work well for this owing to the phenomenal skill level and precision required (just a personal opinion, I'm interested to hear what @Larry thinks). * I feel the Pugs model may work well for the non-formal-spec part (e.g. perlintro, pugsintro, tutorials, ...) of the documentation that will ship with Perl 6 and Pugs. Accordingly, that effort has already been started (mainly by Skud, so far) in the Pugs svn repository: http://svn.perl.org/perl6/pugs/trunk/docs/p6doc/. Call to Arms Volunteers are sought for building the documentation that will ship with Perl 6 and Pugs. This documentation lives in the Pugs svn repository under docs/p6doc/. This documentation is being written in POD. If you want to contribute to this effort, hang around on the #perl6 IRC channel and ask someone for a committer bit. How should the documentation be organised? == Opinions are welcome on this. Certainly, there is much prior art on how to document a computer language. I feel we should essentially follow the p5 model, stealing good ideas from other languages (especially Ruby and Python) where appropriate. In particular, Ruby's PickAxe book seems a sound model for documenting the new p6 OO libraries. Though Audrey suggested modelling the documentation around p5's 'perldoc perl' command, I personally prefer the (similar) organisation at http://perldoc.perl.org/. References == * The Perl 6 Synopses, Apocalypses and Exegeses at: http://dev.perl.org/perl6/ (they are also stored in http://svn.perl.org repository). The Synopses are the most important of the three since they are the only ones being kept up to date. Some bits from current Pugs docs/ directory that might be useful: * docs/quickref/ (Juerd) * docs/articles/tpr.pod (gaal) draft (unpublished) TPR Pugs article * docs/other/porting_howto (iblech) How to port p5 modules to p6 * docs/notes/docs_evil_plan.txt (asavige) * examples/ directory (especially Ovid's cookbook) Some bits of Pugs docs/ directory needing more work: * 01Overview.html * 02Architecture.pod * 03Evaluator.pod * Pugs Apocrypha * Perl6::Bible (http://search.cpan.org/dist/Perl6-Bible/). * "Perl 6 Documentation Project" http://www.nntp.perl.org/group/perl.perl6.documentation * Rod Adams S29 at http://www.rodadams.net/Perl/S29.html * http://perldoc.perl.org/ * p5 'perldoc perl' command * The camel book * Python documentation http://www.python.org/ * PickAxe Reference section (for Perl Library Reference) * Parrot documentation (www.parrotcode.org) Send instant messages to your online friends http://au.messenger.yahoo.com
[perl #38083] [TODO] adjust parrot test harness to fill I/N registers with garbage by default
# New Ticket Created by jerry gay # Please include the string: [perl #38083] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=38083 > adjust the parrot test harness to fill I/N registers with garbage by default. in other words, enable parrot's -D40 flag. see tcl's test harness for an example. this is low hanging fruit for a coder competent in perl. ~jerry
[perl #38085] [TODO] Tcl - inline [set]
# New Ticket Created by Will Coleda # Please include the string: [perl #38085] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=38085 >
[perl #38098] [TODO] Tcl - expr - new in and ni operators
# New Ticket Created by Matt Diephouse # Please include the string: [perl #38098] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=38098 > There are two new [expr] operators in Tcl 8.5 that need to be added to partcl: in and ni. Description at: http://tcl.tk/man/tcl8.5/TclCmd/expr.htm -- matt diephouse http://matt.diephouse.com
Re: [RFC] Dynamic binding patch
From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Sat, 31 Dec 2005 01:17:39 +0100
On Dec 30, 2005, at 17:50, Bob Rogers wrote:
>The attached patch is functionally complete, but I still have a few
> loose ends to nail down, so I thought it would be a good time to post
> it
> for review. The issues are as follows:
>
>1. It needs more higher-level documentation. Is compiler_faq.pod
> the best place for this?
>
>2. Binding 'foo' to a null PMC should cause find_global to err out
> with "Global "foo" not found", but this is not happening.
>
>3. There are no tests for threads or stack-unwinding continuations.
> (Yes, I am procrastinating.)
I think I've missed to answer the last one WRT that - sorry. Anyway,
here are some comments:
No prob; thanks for your review.
- the patch looks really great and seems to cover all aspects to get
this running (just a minor nitpick: src/register.c:init_context() is a
common place to copy inherited context items)
Yes, thank you; that does seem to be the logical place. I think I had
passed this over because of the init_context call at src/register.c:325
(as patched) which doesn't pass the caller's context. But this
particular call looks like bit rot; it's only enabled if CHUNKED_CTX_MEM
is true. Should I flush it?
- the patch seems to miss the 'other part' of 'local' i.e. restoring
the old contents of a variable . . .
It never actually has to restore anything, because the old contents are
still in the appropriate stash. The new dynamic bindings shadow the old
one(s), and are undone simply by virtue of returning from the sub. This
is why the coroutine test case works the way it does. (FWIW, the
implementation uses what we old Lispers call "deep binding," mixed with
"shallow binding" (checking the stash) if a dynamic binding is not
found.)
. . . like e.g. described in 'perldoc perlsub' - (whatever the reason
is that it's doced there ;)
At a guess, I'd say that's the bucket into which all discussion of
scoping has been tossed.
- that is, Perl5 'local' is much more related to Perl6 'let' or 'temp',
it's not just hiding a variable, it looks to me much more like undoing
temporary damage, which looks to me like STM (w/o the needed
synchronization bits)
Actually, if I understand STM correctly, the dynamic_bindings stack
functions very much like a "memory log", except that it only applies to
find_global and store_global, which makes it cheaper. But you're right;
this is only part of what "local" can do.
- if the intent is just to temporarly hide a name, then it should be ok
(but not refer to 'local' at all)
I think it needs more thoughts and more (common) infrastructure .
leo
Hmmm [he mumbles as he studies "perldoc perlsub", for the first time in
ages . . . ]
It's true, this patch doesn't address dynamic binding of Perl5
typeglobs and arbitrary references (i.e. "local $SIG{INT} = ..."). But
it does implement all of the rest of the functionality of Perl5 "local",
it seems to me. So, if you prefer, one could just call it "dynamic
variable binding" instead of the more general "dynamic binding."
In any case, I agree that it needs more thought. Here's a sampling
off the top of my head:
1. Dynamic binding of typeglobs. I haven't noticed a Parrot concept
of "symbol table entry"; in particular, Matt's namespace proposal
doesn't mention one. Consequently, I am assuming
that each Per[56] typed variable is named with its sigil and treated
separately for purposes of *_global operations. Therefore, it should be
both necessary and sufficient for "local *foo = ..." to expand into code
that binds each sigil separately. True? How else could you do it?
2. Dynamic binding of hash and array elements. The "perlsub"
example of this (the paragraph starts with "It's also worth taking a
moment to explain what happens ...") pretty much requires that this be
done via "temporary damage" (aka shallow binding) -- I can't think of
any other way to mutate $ary[5] and then restore @ary as described.
This has the drawbacks cited in the "Dynamic binding" proposal I posted
last Friday, but that's just too bad, as there isn't a choice.
Consequently, I would argue that these require a separate mechanism.
Now, if you buy both of these arguments, then that suggests I should
finish the patch as designed, and design the rest of "local" support
separately. If not, though, I may not have time to finish a more
general design during my window of opportunity, in which case finishing
the patch as designed may still be a good strategy.
But I will go back to the drawing board, and post more later . . .
-- Bob
Re: A couple of questions
On Mon, 2005-12-26 at 00:40 +0100, Leopold Toetsch wrote:
> On Dec 25, 2005, at 23:48, Steve Gunnell wrote:
[snip]
>
> > When using the Read/Readline opcodes how do we specify what encoding is
> > to be assumed for the incoming string?
>
> There is one output encoding filter currently:
>
>pout = getstdout
>push pout, 'utf8'
>
> The same should work with an import filter, that is a (TODO) read
> method implemented in src/io/io_utf8.c or similar.
> Patches welcome.
[snip]
Does this look like a suitable implementation of PIO_utf8_read?
---
static size_t
PIO_utf8_read(theINTERP, ParrotIOLayer *l, ParrotIO *io, STRING *s)
{
size_t got;
got = PIO_read_down(interpreter, l->down, io, s);
s->charset = Parrot_unicode_charset_ptr;
s->encoding = Parrot_utf8_encoding_ptr;
return got;
}
---
I'm making the assumption here that I'm reading something that is
already utf8 not something that needs converting.
I assume that it is safer to preform the mods in this order in case a
lower level replaces "s" without copying its attributes?
I also had a look at PIO_utf8_peek but the lower levels like
PIO_buf_peek seem hard coded to return 1 byte and we might need up to 3
to return an utf8 character.
Any comments?
Cheers,
Steve Gunnell
