RE: Revised Perl++ Wiki Proposal / $1k bounty
> From: Michael Mathews [mailto:[EMAIL PROTECTED] > On 20/06/06, Conrad Schneiker <[EMAIL PROTECTED]> wrote: > > I propose to install twiki (http://www.twiki.org/) on Feather. > This is > > a GPL'd Perl-based industrial-strength wiki. This would serve as > the > > general Perl 6 wiki, aka Perl++. > > > > The source code would be placed in the Pugs .../other/... subtree > for > > us to incrementally convert parts of it to Perl 6, and to also > > add/change functionality. A perpetual beta version of this would > also > > be available on Feather. From time to time this beta version would > > replace the pervious Perl++ wiki code. In the mean time, we would > have > > the initial Perl++ wiki. > > Before you sent that I registered a project on Source Forge for > this, > half-thinking I would want to work on it but also open it up to the > entire community. Reason being that Source Forge has well- > established, > robust community project management features already available (I > have > another project there that's nearing it's 10,000th download). > > If you want a place to keep/hack-on P6 wiki code I'd propose that > http://sourceforge.net/projects/p6wiki be the place. Anyone who > wants > can have admin/developer permissions -- just ask. > > Feather would still be required to demo/test/run the latest > perpetual > beta release. What say you, Conrad? Well first of all, thanks for the offer, and I appreciate the initiative. However, I had several reasons for suggesting (and strongly preferring) that Perl++ be under the Pugs tree: (1) The proposed wiki interface to the Pugs doc tree will require some collaboration with @Pugs. This is something that I think would be very valuable, so I want to make things maximally convenient for @Pugs to deal with. (This also gives @Pugs a built-in final say of last resort over required mechanisms and policies for updating Pugs svn tree docs from Perl++.) (2) People who have to get Pugs commit bits would be somewhat more likely to write Pugs tests (or update docs) for discovered Perl 6 issues, and it is near-maximally convenient to do so, since they would already be working in the same virtual office, so to speak. (3) Changes to the Pugs tree get a certain amount of useful scrutiny, and requiring people to get Pugs commit bits provides a useful minimal threshold, IMHO. (4) As an early project that will have a continually increasing fraction of Perl 6 content (and thus serve as a substantial evolving showcase for Perl 5 to Perl 6 migration), I wanted Perl++ to be readily available to Pugs users as working example code. (Something that comes with distribution is about as convenient as you can get, and it provides an ever-present temptation for exploring and hacking.) Providing a general purpose tool and strategy for accelerating the creation of various useful forms of user-oriented Perl 6 documentation is a huge priority for me. For the time being, starting out with Perl++ in the Pugs svn tree seems to be a semi-optimal point of maximum leverage for achieving this. I think this might also draw more people into Perl 6 development-related activities as well. Best regards, Conrad Schneiker http://perl.net.au/wiki/Perl_6_Users_FAQ (Moved from AthenaLab to Perl 6 Wiki.) www.AthenaLab.com (Nano-electron-beam and micro-neutron-beam technology.)
Re: lvalue functions and lvalue parameters
Jonathan Scott Duff wrote:
>> sub cond(Bool $c, $a, $b) is rw {
>> if $c return $a else return $b;
>> }
>>
>> Will this fail because $a and $b are not rw? If so, will it fail at run-
>> or compile-time? What about this:
>>
> That looks like it should be a compile-time failure to me.
>
Depends on the interpreter of course, but ideally, yes, compile time.
>> sub cond(Bool $c, $a is copy, $b is copy) is rw {
>> if $c return $a else return $b;
>> }
>>
>> Is it allowed, and if so is the behaviour to return a writeable copy of
>> $a or $b? I imagine that in any case
>>
> I'd expect a compile-time failure here too, or at the very least a
> warning. Besides, returning a local copy each time hardly seems
> useful, except perhaps as a way to leak memory.
>
It doesn't have to be a real copy, that's up to the implementation to
apply whatever COW mechanism it likes. The type of $a and $b in this
case is compatible with the return type of the function, so it should be
fine.
This example is a bit useless - cond($x, $a, $b) = $foo won't store the
result anywhere. So this could be a warning along the lines of "useless
use of variable in void context" (but more tailored to this condition)
>> sub cond(Bool $c, $a is rw, $b is rw) is rw {
>> if $c return $a else return $b;
>> }
>>
>> will do what I want.
>>
> That is what I would expect too.
>
Right.
>> my Int $a is constant = 0;
>> my Int $b is constant = 0;
>> (cond(True, $a,$b))++;
>>
>
> We have a "constant" declarator now, so that would be
>
> constant Int $a = 0;
> constant Int $b = 0;
> (cond(True, $a,$b))++;
>
> and that should fail at compile time because the compiler knows that
> $a and $b are constant and can't be rw.
>
Indeed it should, with the same disclaimer as above re: compile/runtime
Sam.
Exceptions, dynamic scope, Scheme, and Lisp: A modest proposal
WRT exception handling, I think the lisp condition/handler model is a good
starting point. It's simple enough to explain and use, and static models
can easily be implemented in terms of it.
But I really don't like one thing about the CL handler model: it conflates
non-local transfers of control with "this exception is now handled". So (1)
every continuation invocation has to check to see whether an exception is
live so it can be marked dead, which complicates what should be as efficient
as possible, and (2) creative condition handlers can't use continuations as
an implementation tool.
But I see a way out; see below.
On Thu, Jun 15, 2006 at 12:03:56AM -0400, Bob Rogers wrote:
>3. FWIW, the Scheme dynamic-wind feature requires an action to be
> invoked when re-entering the context as well as leaving it. But this is
> probably not relevant, as a real Scheme implementation would probably
> not need Parrot continuations or actions in any case.
Huh, that's odd, coming from you. Having just spent the better part of my
evening wrapping my head around call/cc and dynamic-wind, I'm about to
modify pdd23 to replace push_handler with:
$P0 = newclosure sub_to_call_when_entering_scope
$P1 = newclosure sub_to_call_when_leaving_scope
$P2 = newclosure sub_to_call_when_scope_is_finally_inaccessible
push_dynscope $P0, $P1, $P2 # [*]
...
pop_dynscope # [**]
So, having chosen Scheme as a good model for scope and continuation
handling, wouldn't a Scheme compiler want to take advantage of that?
And getting back to exceptions, I'm seeing something that's pretty much like
the CL model, where the 'push_eh' opcode takes a _closure_, and the list of
handlers is its own array in the interpreter, not in the generic control
stack, and which is called at 'throw' time in the dynamic context of the
'throw'. For conventional static languages like Perl 6 (:-)), the handler
would pretty much report that the exception was handled (e.g. with a
'caught' opcode) and then invoke a continuation which had been taken by the
Perl 6 compiler to point to the 'catch' code.
(Given the dynscope feature, it would be possible to do all of this without
Parrot's help, which is a good sign for the design of dynscope; but I think
Parrot should go ahead and help out to make it run quickly.)
Now how would a CL compiler use this? I ask, and also answer:
If dynamic-wind is implemented (see below), it seems to me that a CL
compiler could wrap each handler in a dynamic scope in such a way as to trap
a non-local transfer distinctly from a return, and in the former case,
automatically invoke the hypothetical Parrot "caught" opcode. So CL users
get full CL semantics, and everybody gets a faster continuation.invoke()
operation.
It seems so obvious that I'd suggest that's how it works, except for some
reason I can't fathom, CL doesn't support continuations...?
>On the other hand, since static exception blocks haven't been implemented
>yet, it's not too late to ditch the whole change as a bad job, if that's
>the right decision for Lisp and other languages. Lispers are people too.
> :-)
>
> You mean -+<{gasp}>+- I can come out of my closet now?
Join us out here, in the *bigger* closet!
I'm glad you kept CL and Scheme in view. After today, modeling
continuations and condition handling without reference to Scheme and Lisp
seems as foolish as modeling text searching without reference to Perl.
[*] I think a version of push_dynscope that accepts three sub labels
directly could also be OK, but since often one or more of them will be
NULL, it's probably a waste.
[**] The opposite of "push" is "pop", dammit! Not "clear". Sheesh.
--
Chip Salzenberg <[EMAIL PROTECTED]>
Fwd: threading creation syntax proposal
On 6/20/06, Jonathan Worthington <[EMAIL PROTECTED]> wrote: "Charles Reiss" <[EMAIL PROTECTED]> wrote: > > Since I don't think the three-tiered threading system is going to be > implemented very soon, I'd like to propose that thread creation > instead be done with one new method of a ParrotThread object: > > =item C arguments...)> > Maybe we should go for a name that's more descriptive of what's happening, such as "new_thread"? I'd prefer 'run' myself. However, I'm not too sure whether this is the best answer. Maybe it would be better to create a thread object for a thread that you intend to spawn, just as you instantiate any other PMC, perhaps with some flags and the sub being given as arguments to the constructor. Then perhaps use the invoke v-table methods, invoking it like a sub, to actually spawn the new thread. This way the thread object is around to call methods on to get its status, change its priority etc. This would probably be a nice interface to provide for the common case. There is a question of how it will interact with thread destruction: either we will need a way to keep information about a thread around well after it is destroyed (even if as little as enough to reserve its thread ID) until we can be sure that references to its wrapper objects are gone or we will need to specify that rather unexpected behavior can happen when attempts are made to use the thread wrapper after the underlying thread has been detached or joined in another thread (this unexpected behavior including the operations affecting an unrelated thread). The latter behavior is certainly the easier to implement, but if we did, I'd be concerned about users not noticing the caveat, which is one reason why I was reluctant to propose not using numerical thread ids (which should at least suggest to users that they may be reused or become invalid). The greater intuitiveness is probably worth it, however. [snip] -- Charles
Re: Couldn't understand the following message from Devel::Cover ...
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Paul Johnson wrote:
> On Fri, Jun 16, 2006 at 12:43:11PM +0530, Rajanikanth Dandamudi wrote:
>
>> Hi All,
>>
>> Can some one help me understand why I am getting the following message
>> on the following perl program :
>>
>> perl program
>>
>> #!/usr/local/bin/perl
>>
>> %hsh = (
>> ABC => -abc,
>> DEF => -def,
>>);
>>
>> for $key (keys %hsh){
>> print "Key = $key Value = $hsh{$key}\n";
>> }
>> =
>>
>> command used : perl -MDevel::Cover
>>
>> output:
>> ===
>> Devel::Cover 0.55: Collecting coverage data for branch, condition,
>> statement, subroutine and time.
>> Pod coverage is unvailable. Please install Pod::Coverage from CPAN.
>> Selecting packages matching:
>> Ignoring packages matching:
>> /Devel/Cover[./]
>> Ignoring packages in:
>> .
>> /proj/dite/WorkArea/Raja/perl/lib
>> /proj/dite/WorkArea/Raja/perl/lib/5.8.8
>> /proj/dite/WorkArea/Raja/perl/lib/5.8.8/i686-linux
>> /proj/dite/WorkArea/Raja/perl/lib/site_perl
>> /proj/dite/WorkArea/Raja/perl/lib/site_perl/5.8.8
>> /proj/dite/WorkArea/Raja/perl/lib/site_perl/5.8.8/i686-linux
>> Key = ABC Value = -abc
>> Key = DEF Value = -def
>> Devel::Cover: Can't find file "../../lib/Storable.pm": ignored.
>> Devel::Cover: Writing coverage database to
>> /sp/dftm/Activities/MemoryBIST/pbist/flow/data/cover_db/runs/1150441786.22790.00593
>> --- -- -- -- -- --
>> --
>> File stmt bran condsub time
>> total
>> --- -- -- -- -- --
>> --
>> ...6905/LearnPerl/Hash_Example_2.pl 100.0n/an/an/a 100.0
>> 100.0
>> Total100.0n/an/an/a 100.0
>> 100.0
>> --- -- -- -- -- --
>> --
>> =
>>
>> I couldn't understand what the following message means :
>>
>> Devel::Cover: Can't find file "../../lib/Storable.pm": ignored.
>>
>> Even though this is being ignored here, this is causing problems down
>> the line. Can you help me on what this means and how to overcome this ?
>
> What it means is that when Devel::Cover went to examine all the data it
> had collected and map it back to reality, it went looking for the source
> code to Storable. When perl first loaded Storable it was found in the
> relative directory "../../lib/Storable.pm". What that was relative to,
> we don't really know. Perl doesn't store that information.
>
> Devel::Cover tries very hard to find that information (I won't go into
> the details, but it is messy), but doesn't always succeed. In
> particular, this warning is fairly common, and I haven't been able to
> track it down, though I suspect it has something to do with Storable
> being used by Devel::Cover itself and so it is loaded before
> Devel::Cover's hacks get a chance to kick in.
>
> What this means in practice is that you won't get a coverage report for
> Storable. But it's pretty unlikely you wanted one anyway, so this
> shouldn't be a great problem. So I am interested in what problems this
> causes down the line. To stop the warning I suggest the following
> options:
>
> 1. Fix Devel::Cover. Go on, please. You know you want to ;-)
> 2. Hack the source to disable the warning.
> 3. Filter the output.
> 4. Pretend you didn't see it.
>
> Most people take the fourth option since it really shouldn't cause any
> further problems.
>
fwiw:
Devel::Cover 0.55: Collecting coverage data for branch, condition, pod,
statement, subroutine and time.
Selecting packages matching:
Ignoring packages matching:
/Devel/Cover[./]
Ignoring packages in:
.
/usr/lib64/perl5/5.8.8
/usr/lib64/perl5/5.8.8/x86_64-linux
/usr/lib64/perl5/site_perl
/usr/lib64/perl5/site_perl/5.8.8
/usr/lib64/perl5/site_perl/5.8.8/x86_64-linux
/usr/lib64/perl5/vendor_perl
/usr/lib64/perl5/vendor_perl/5.8.8
/usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux
Key = ABC Value = -abc
Key = DEF Value = -def
Devel::Cover: Writing coverage database to
/home/cover_db/runs/1150852181.9923.33847
- -- -- -- -- -- --
- --
File stmt bran condsubpod time
total
- -- -- -- -- -- --
- --
test 100.0n/an/an/an/a 100.0
100.0
Total 100.0n/an/an/an/a 100.0
100.0
- -- -- -- -- -- --
- --
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)
iD8DBQFEmJy1q1ztTp5/Ti4RAjeWAJ40MyYNGhWidkG4MjQJLP867pt75wCfUdqw
6GQXJcScJKB3FGtrKyuaGgA=
=YkPW
-END PGP SIGNATURE-
Re: threading creation syntax proposal
"Charles Reiss" <[EMAIL PROTECTED]> wrote: Since I don't think the three-tiered threading system is going to be implemented very soon, I'd like to propose that thread creation instead be done with one new method of a ParrotThread object: =item Carguments...)> Maybe we should go for a name that's more descriptive of what's happening, such as "new_thread"? However, I'm not too sure whether this is the best answer. Maybe it would be better to create a thread object for a thread that you intend to spawn, just as you instantiate any other PMC, perhaps with some flags and the sub being given as arguments to the constructor. Then perhaps use the invoke v-table methods, invoking it like a sub, to actually spawn the new thread. This way the thread object is around to call methods on to get its status, change its priority etc. I guess invoking an already started thread again would be an exception... Jonathan
Re: Revised Perl++ Wiki Proposal / $1k bounty
Michael Mathews skribis 2006-06-20 18:00 (+0100): > Before you sent that I registered a project on Source Forge for this, > half-thinking I would want to work on it but also open it up to the > entire community. Reason being that Source Forge has well-established, > robust community project management features already available (I have > another project there that's nearing it's 10,000th download). Not everyone agrees that Sourceforge is so great. I, for one, will not use it. And no, I'm not going to discuss this again, sorry. If there's anything important that sourceforge does that feather doesn't provide yet, please work with me to change that. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: lvalue functions and lvalue parameters
I don't have any real answers, but I'll weigh in with my opinion
anyway :-)
On Tue, Jun 20, 2006 at 10:59:01AM +0100, Daniel Hulme wrote:
> I've just thought of an interesting interaction with lvalue functions
> and call by foo. What if I want to write, say, an lvalue ?? !! function
> thus
>
> sub cond(Bool $c, $a, $b) is rw {
> if $c return $a else return $b;
> }
>
> Will this fail because $a and $b are not rw? If so, will it fail at run-
> or compile-time? What about this:
That looks like it should be a compile-time failure to me.
> sub cond(Bool $c, $a is copy, $b is copy) is rw {
> if $c return $a else return $b;
> }
>
> Is it allowed, and if so is the behaviour to return a writeable copy of
> $a or $b? I imagine that in any case
I'd expect a compile-time failure here too, or at the very least a
warning. Besides, returning a local copy each time hardly seems
useful, except perhaps as a way to leak memory.
> sub cond(Bool $c, $a is rw, $b is rw) is rw {
> if $c return $a else return $b;
> }
>
> will do what I want.
That is what I would expect too.
> my Int $a is constant = 0;
> my Int $b is constant = 0;
> (cond(True, $a,$b))++;
We have a "constant" declarator now, so that would be
constant Int $a = 0;
constant Int $b = 0;
(cond(True, $a,$b))++;
and that should fail at compile time because the compiler knows that
$a and $b are constant and can't be rw.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
[svn:perl6-synopsis] r9716 - doc/trunk/design/syn
Author: larry Date: Tue Jun 20 11:38:41 2006 New Revision: 9716 Modified: doc/trunk/design/syn/S12.pod Log: s/property/attribute/ from cognominal++ Modified: doc/trunk/design/syn/S12.pod == --- doc/trunk/design/syn/S12.pod(original) +++ doc/trunk/design/syn/S12.podTue Jun 20 11:38:41 2006 @@ -12,7 +12,7 @@ Maintainer: Larry Wall <[EMAIL PROTECTED]> Date: 27 Oct 2004 - Last Modified: 3 Jun 2006 + Last Modified: 20 Jun 2006 Number: 12 Version: 16 @@ -403,8 +403,9 @@ to submethods. Ordinary methods should stick to the C<$.foo> form. Because C<$.foo>, C<@.foo>, C<%.foo>, C<&.foo> are just shorthands of -C with different contexts, the class does not need to declare C as a property -- a C declaration can work just as well. +C with different contexts, the class does not need to declare +C as an attribute -- a C declaration can work +just as well. The dot form can take an argument list as well. These are all equivalent:
Re: ~~ with *
On Mon, Jun 19, 2006 at 08:51:24AM -0600, Eric wrote:
: Just my two cents, but whenever i see "when True {...}" I expect $_
: to be true, so that i can do when True and when False. And I if see
: when followed by a comparison i expect the when to be true when the
: comparison is true. To me its kind of like, if you only have one
: operand then use the given subject, if you have two operands then they
: don't need a subject. So the given $_ topic would fill in only in the
: cases where you needed a topic. Of course that might not realy make
: since for given/when and its smart matching magic. But then maybe we
: just don't want to be able to say "when $a == $b" and thats just
: invalid since it would be clearer written as an if.
After much mulling, I've I've left booleans in a priviledged state of
assuming {...} around themselves. (Wrapping in {...} is the generic
method of suppressing comparison to $_, though ? and true() also work
for that.) You can always write
given $boolean {
when .true {...}
when .not {...}
}
to mean the other thing. Or horrors, maybe even just use an "if"...
Larry
[svn:perl6-synopsis] r9715 - doc/trunk/design/syn
Author: larry
Date: Tue Jun 20 11:37:51 2006
New Revision: 9715
Modified:
doc/trunk/design/syn/S03.pod
doc/trunk/design/syn/S04.pod
Log:
Smart match moved to S03.
Smart match clarifications.
Modified: doc/trunk/design/syn/S03.pod
==
--- doc/trunk/design/syn/S03.pod(original)
+++ doc/trunk/design/syn/S03.podTue Jun 20 11:37:51 2006
@@ -12,9 +12,9 @@
Maintainer: Larry Wall <[EMAIL PROTECTED]>
Date: 8 Mar 2004
- Last Modified: 16 Jun 2006
+ Last Modified: 20 Jun 2006
Number: 3
- Version: 41
+ Version: 42
=head1 Changes to existing operators
@@ -318,11 +318,12 @@
=item * C<^^> is the high-precedence version of C.
=item * C<=~> becomes the "smart match" operator C<~~>, with a whole new set
-of semantics. Anywhere you used C<=~> before you now use C<~~>, but C<~~> is
-much more general now. See S04 for details. (To catch "brainos",
-the Perl 6 parser defines an C<< infix:<=~> >> macro which always fails at
-compile time with a message directing the user either to use C<~~> or C<~=>
instead,
-or to put a space between if they really wanted to assign a stringified value.)
+of semantics. Anywhere you used C<=~> before you now use C<~~>, but C<~~>
+is much more general now. See "Smart matching" below for details. (To catch
+"brainos", the Perl 6 parser defines an C<< infix:<=~> >> macro which always
+fails at compile time with a message directing the user either to use C<~~>
+or C<~=> instead, or to put a space between if they really wanted to assign
+a stringified value.)
=item * "Unary" C<.> calls its single argument (which must a postfix operator)
on C<$_>. (It's not really a unary operator, so we put it in quotes.)
@@ -406,6 +407,105 @@
=back
+=head1 Smart matching
+
+Here is the current table of smart matches.
+The list is intended to reflect forms that can be recognized at
+compile time. If none of these forms is recognized at compile time, it
+falls through to do MMD to C<< infix:<~~>() >>, which presumably
+reflects similar semantics, but can finesse things that aren't exact
+type matches. Note that all types are scalarized here. Both C<~~>
+and C/C provide scalar contexts to their arguments.
+(You can always hyperize C<~~> explicitly, though.) So both C<$_>
+and C<$x> here are potentially references to container objects.
+And since lists promote to arrays in scalar context, there need be no
+separate entries for lists.
+
+$_ $xType of Match ImpliedMatching Code
+== = ==
+Any Code:($) scalar sub truth match if $x($_)
+HashHash hash keys identical match if $_.keys.sort »eq«
$x.keys.sort
+Hashany(Hash) hash key intersectionmatch if $_{any(Hash.keys)}
+HashArray hash value slice truth match if $_{any(@$x)}
+Hashany(list) hash key slice existence match if exists $_{any(list)}
+Hashall(list) hash key slice existence match if exists $_{all(list)}
+HashRegex hash key grepmatch if any($_.keys) ~~ /$x/
+HashAny hash entry existence match if exists $_{$x}
+Hash.{Any}hash element truth* match if $_{Any}
+Hash. hash element truth* match if $_
+Array Array arrays are comparablematch if $_ »~~« $x
+Array any(list) list intersectionmatch if any(@$_) ~~ any(list)
+Array Regex array grep match if any(@$_) ~~ /$x/
+Array Num array contains numbermatch if any($_) == $x
+Array Str array contains stringmatch if any($_) eq $x
+Array .[number] array element truth* match if $_[number]
+Num NumRange in numeric range match if $min <= $_ <= $max
+Str StrRange in string range match if $min le $_ le $max
+Capture Signature parameter bindingmatch if $cap can bind to $sig
+Any Code:()simple closure truth*match if $x() (ignoring $_)
+Any Class class membership match if $_.does($x)
+Any Role role playing match if $_.does($x)
+Any Num numeric equality match if $_ == $x
+Any Str string equality match if $_ eq $x
+Any .method method truth*match if $_.method
+Any Regex pattern matchmatch if $_ ~~ /$x/
+Any subst substitution match* match if $_ ~~ subst
+Any boolean simple expression truth* match if true given $_
+Any undef undefinedmatch unless defined $_
+Any Whatever default match anything
+Any Any run-time dispatchmatch if infix:<~~>($_, $x)
+
+Matches marked with * are non-reversible, typically because C<~~> takes
+its left side as the topic for the right side, and sets the topic to a
+p
threading creation syntax proposal
Below is a proposal to change the syntax for creation of threads. The primary change is a move away from the original interface which had three thread-creation functions: thread1, thread2, and thread3. These were supposed to create threads in one of three types, see, e.g., Dan's proposal at http://www.nntp.perl.org/group/perl.perl6.internals/19876 The various types of threads were never really implemented. The only difference between them was that type-2 and type-3 threads would call clone_interpreter() [in parrotinterpreter.pmc] which, somewhat unexpectedly, only copied over the runops core choice and the interpreter flags -- presumably, it should be made to copy over more data in the future. Code would always be shared with the parent interpreter under the scheme. Since I don't think the three-tiered threading system is going to be implemented very soon, I'd like to propose that thread creation instead be done with one new method of a ParrotThread object: =item C Spawn a new thread. C is or'd together constants available from C. Now, only one constant is defined: =over 4 =item PARROT_THREAD_CLONE Specifies that the created thread shall call clone_interpreter() to 'clone' state from the parent thread into the child thread. =cut C is the subroutine to run in the new thread. The remaining arguments (any number is premitted) will be used as arguments to the subroutine. The arguments shall be cloned into the new interpreter unless they are shared PMCs. After this method returns, the ParrotThread PMC shall become Undef. [Rationale: ParrotThread inherits from ParrotInterpreter -- sensibly -- but manipulating the interpreter in a seperate thread is dangerous, especially since the interpreter shall be destroyed when the other thread is joined or exits after it is 'detached'. An obvious alternative is to morph the ParrotThread PMC into the thread ID which I think would be unexpectedly magical. The use of thread IDs instead of some 'thread handle' PMC represents no change from the original implementation. If we do create a core running-thread PMC type, it will probably end up just wrapping a thread ID and so its only advantage is likely to be the syntax with which thread-manipulating methods are called.] The returned thread ID may be used with various methods on the ParrotInterpreter object obtained by the getinterp opcode to manipulate the running thread. =cut Comments welcome. -- Charles Reiss
Re: Revised Perl++ Wiki Proposal / $1k bounty
On 20/06/06, Conrad Schneiker <[EMAIL PROTECTED]> wrote: I propose to install twiki (http://www.twiki.org/) on Feather. This is a GPL'd Perl-based industrial-strength wiki. This would serve as the general Perl 6 wiki, aka Perl++. The source code would be placed in the Pugs .../other/... subtree for us to incrementally convert parts of it to Perl 6, and to also add/change functionality. A perpetual beta version of this would also be available on Feather. From time to time this beta version would replace the pervious Perl++ wiki code. In the mean time, we would have the initial Perl++ wiki. Before you sent that I registered a project on Source Forge for this, half-thinking I would want to work on it but also open it up to the entire community. Reason being that Source Forge has well-established, robust community project management features already available (I have another project there that's nearing it's 10,000th download). If you want a place to keep/hack-on P6 wiki code I'd propose that http://sourceforge.net/projects/p6wiki be the place. Anyone who wants can have admin/developer permissions -- just ask. Feather would still be required to demo/test/run the latest perpetual beta release. What say you, Conrad? --michael
Revised Perl++ Wiki Proposal / $1k bounty
Here's my latest proposal. Feedback welcome. I propose to install twiki (http://www.twiki.org/) on Feather. This is a GPL'd Perl-based industrial-strength wiki. This would serve as the general Perl 6 wiki, aka Perl++. The source code would be placed in the Pugs .../other/... subtree for us to incrementally convert parts of it to Perl 6, and to also add/change functionality. A perpetual beta version of this would also be available on Feather. From time to time this beta version would replace the pervious Perl++ wiki code. In the mean time, we would have the initial Perl++ wiki. The previously proposed bounty would then instead be offered for the following subproject. Create a subsection of the Perl++ wiki that mirrored the Pugs svn doc tree. Provide a means of hacking on the docs through the Perl++ wiki. Implement whatever protocol the @Larry people on #perl6 deem appropriate for handing commit bit access issues. I think that that this simplification and convenience would greatly expand participation in generating Perl 6 documentation. Best regards, Conrad Schneiker http://perl.net.au/wiki/Perl_6_Users_FAQ (Moved from AthenaLab to Perl 6 Wiki.) www.AthenaLab.com (Nano-electron-beam and micro-neutron-beam technology.)
lvalue functions and lvalue parameters
I've just thought of an interesting interaction with lvalue functions
and call by foo. What if I want to write, say, an lvalue ?? !! function
thus
sub cond(Bool $c, $a, $b) is rw {
if $c return $a else return $b;
}
Will this fail because $a and $b are not rw? If so, will it fail at run-
or compile-time? What about this:
sub cond(Bool $c, $a is copy, $b is copy) is rw {
if $c return $a else return $b;
}
Is it allowed, and if so is the behaviour to return a writeable copy of
$a or $b? I imagine that in any case
sub cond(Bool $c, $a is rw, $b is rw) is rw {
if $c return $a else return $b;
}
will do what I want. I suppose the issue comes down to the scope of
modifiers like rw. In the first example, $a and $b are constant in the
scope of the function, but they aren't written in the scope of the
function. They are then passed to the caller which may then try to write
them, but will they remember that they are rw in the caller's scope?
Furthermore, what if they aren't rw in the caller's scope?
my Int $a is constant = 0;
my Int $b is constant = 0;
(cond(True, $a,$b))++;
What goes on here, for any of the cond definitions? Do any of them
result in breaking the constancy of $a? I'm not sure, but I think my
vote is for contestant number one to fail at compile-time, number two to
generate new, writeable copies, and number three to give the returned
lvalue the same writeability as its caller.
Come to that, what is the behaviour of constant variables being rw'ed in
parameter lists?
sub rwify($a is rw) { $a += 19; }
my Int $a is constant = 23;
rwify $a;
say "The meaning of life is $a";
I would imagine it should fail on the function call, but I'm open to
other suggestions.
--
Humpty Dumpty sat on the wall, Humpty Dumpty had a great fall,
All the King's horses and all the King's men | http://surreal.istic.org/
Couldn't put Humpty together again. | powered by cat and ^d
Perhaps they shouldn't have given the horses the first go.
signature.asc
Description: Digital signature
