Re: Synchronized / Thread syntax in Perl 6
On Tue, May 30, 2006 at 03:41:06PM -0600, John Drago wrote:
class Foo is synchronized {
...
}
our method Bar is synchronized {
...
}
class Baz {
has $.Bux is synchronized;
}
To everyone participating in this thread:
There has already been a draft spec for concurrency written, please see
http://svn.perl.org/perl6/pugs/trunk/docs/Perl6/Spec/Concurrency.pod .
It suggests is critical; for the first, and second, but I can't see
anything like the third. It also suggests that Perl6 will have
transactions and so will also have is atomic.
(There's a Google Summer of Code project to add software transactional
memory primitives to parrot.)
--
Benjamin Smith [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: new sigil
On Tue, Oct 25, 2005 at 02:02:58PM -0500, Jonathan Scott Duff wrote:
On Tue, Oct 25, 2005 at 12:18:41PM -0600, Luke Palmer wrote:
snip examples from luqui of type variables being used multiple times
with and without sigils
I don't think so. In the first example all the T (or ¢T) are the same
type after the first ¢T (where the type is bound). In the second one
you'd get two separate types ¢T and ¢U. But ¢U would probably get bound
to the same type as ¢T as that's the type of thing that it returns
(assuming perl can figure that out).
We have (or have had?) parameterised classes where you can specify
parameters to the class enclosed in [].
eg. class Foo[...] { ... }
So couldn't the same be used for functions? This way you wouldn't need
a special sigil for classes declared in such a way.
sub foo[Bar] (Bar $tab) { ... }
Since perl6 isn't really a static language, I don't think you need to be
allowed to have non-type variables in the [] (dependent-typing, or where
you can use primitive types like int in template parameters in C++),
since being parameters in [] means only that they're types, and not that
they are always bound at compile time.
(apologies for breaking the unicode)
--
Benjamin Smith [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Christ's College - Mathematics Part 1B
IRC: integral on irc.perl.org, and irc.freenode.net (channel: #perl)
Re: $1 change issues [was Re: syntax for accessing multiple versions of a module]
On Thu, Oct 20, 2005 at 06:39:34PM -0600, Luke Palmer wrote: On 10/20/05, Nate Wiger [EMAIL PROTECTED] wrote: Luke Palmer wrote: The fact that we use . instead of - (like every other language on the planet)? You're using my argument for me - thanks. See above. Huh? So you want to go back to Perl 5's arrow? *Anybody* coming to Perl 6 from some non-Perl 5 language is going to be more comfortable with dot. Unless it was Smalltalk, C++, Haskell etc. I really wish people wouldn't use the argument that . is used for method calls everywhere. It's not. Surely we have a much better argument in what we used - for instead? [1] Which will be, what, eight hours for a Perl 5 programmer? Have you ever spent a month trying to learn, oh, say, Haskell? Because people do that, too. There are more components to this that just the learning time for one person. There are project teams, sustaining engineering for existing projects, etc. And that's not even counting management tape. Real-world, profitable computing is a big, ugly, nasty beast. Basically that would mean that any team would never be able to change language, right? So there would be no difference if we wanted them to change to Perl 5, Perl 6 or Haskell, so it doesn't seem very useful to argue about this. -- Benjamin Smith [EMAIL PROTECTED], [EMAIL PROTECTED]
!!/nor and ??!! vs. ??::
Pugs currently implements infix:!! as an ugly version of the infix:nor operator. Are these in the spec? If so, how does !! interact with the second part of the new ??!! replacement for ??:: ? -- Benjamin integral Smith [EMAIL PROTECTED], [EMAIL PROTECTED]
Changed ??:: to ??!! in Pugs.
On Thu, Sep 08, 2005 at 05:04:15PM +, Luke Palmer wrote: On 9/8/05, Benjamin Smith [EMAIL PROTECTED] wrote: Pugs currently implements infix:!! as an ugly version of the infix:nor operator. Are these in the spec? No they are not. Destroy! In revisions , and -XXX, I proceeded to excise nor and !! and carry out the ??:: to ??!! change. Luckily it appears that nor has been neither tested nor used. I've tried to change all the code in the pugs tree to use ??!!, but I've very possibly missed something, so people need to check their code too. -- Benjamin integral Smith [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: Changed ??:: to ??!! in Pugs.
On Thu, Sep 08, 2005 at 07:17:47PM +0100, Benjamin Smith wrote: In revisions , and -XXX, I proceeded to excise nor and !! and carry out the ??:: to ??!! change. That's revisions 6848 and 6850-2. -- Benjamin integral Smith [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: Perl development server
On Mon, May 23, 2005 at 05:25:57PM +0200, Juerd wrote: Rob Kinyon skribis 2005-05-23 11:22 (-0400): I'd like one. Sure - just think of a nice catchy username! :) I'd like bsmith. Thanks :-) Maybe we should divvy these tasks out. It wouldn't do that have two people smoke-testing on the exact same machine or to have two SVN mirrors ... Good idea, will you take the task of managing these decisions? I'd like to volunteer to setup the SVN/SVK mirror. Software wise can I ask for: * svk * vim * screen * cron -- Benjamin Smith [EMAIL PROTECTED], [EMAIL PROTECTED] pgp1MJf5iemxM.pgp Description: PGP signature
Re: Perl development server
On Tue, May 24, 2005 at 11:12:58AM +0100, Benjamin Smith wrote: * svk * vim * screen * cron * haddock -- Benjamin Smith [EMAIL PROTECTED], [EMAIL PROTECTED] pgpB9Er7xurFe.pgp Description: PGP signature
BEGIN and lexical variables inside subroutines
sub foo { my $x; BEGIN { $x = 3 }; say $x }
foo; foo; foo;
Currently in perl5 and pugs this prints 3\n\n\n.
Should BEGIN blocks be able to modify values in lexical variables that
don't really exist yet? (People can use state after all to get a
variable which does exist early enough for them to modify.)
Is there some kind of prototype pad (and lexicals) available inside
the BEGIN block, rather than a full runtime pad?
--
Benjamin Smith [EMAIL PROTECTED], [EMAIL PROTECTED]
pgpE521lcB3Mw.pgp
Description: PGP signature
[PUGS] [PATCH] Tests for closure bug, and die bugs
This patch adds a test to t/06sub.t to check that a closure returned by
a subroutine can find the variable that it is closed on.
But in writing this test I found that if (die 'foo') { } doesn't die, so a
test for that has been added to t/base/if.t.
And finally my $foo; eval '$foo = die bool'; $foo; does die, but at
the $foo.
--
Benjamin Smith [EMAIL PROTECTED], [EMAIL PROTECTED]
Index: t/06sub.t
===
--- t/06sub.t (revision 194)
+++ t/06sub.t (working copy)
@@ -1,7 +1,7 @@
use v6;
my $loop = 1;
-say 1..10;
+say 1..12;
sub foobar ($var) {
return $var;
@@ -49,5 +49,20 @@
}
if (callerunderscore() eq -bar-) { say ok 10 } else { say not ok 10 #
TODO CALLER:: }
-
-
+# Check that closures are closed over variables they do use
+# if they don't undefined variable exceptions get thrown
+sub createclosure_sub () {
+ my $a = -wibble-;
+ return sub { $a };
+}
+sub createclosure_block () {
+ my $a = -quux-;
+ return { $a };
+}
+my $sub = createclosure_sub();
+my $block = createclosure_block();
+my $_ = not-wibble-or-quux;
+$_ = $sub.();
+if ($_ eq -wibble-) { say ok 11 } else { say not ok 11 }
+$_ = $block.();
+if ($_ eq -quux-) { say ok 12 } else { say not ok 12 }
Index: t/base/if.t
===
--- t/base/if.t (revision 194)
+++ t/base/if.t (working copy)
@@ -6,8 +6,15 @@
=cut
-say 1..2;
+say 1..3;
my $x = 'test';
if ($x eq $x) { say ok 1; } else { say not ok 1; }
if ($x ne $x) { say not ok 2; } else { say ok 2; }
+
+# die called in the condition part of an if statement should die immediately
+# rather than being evaluated as true
+my $foo = 1;
+eval 'if (die should die) { $foo = 3 } else { $foo = 2; }';
+say '# $foo = ' ~ $foo;
+if ($foo == 1) { say ok 3; } else { say not ok 3 }
Index: t/op/die.t
===
--- t/op/die.t (revision 194)
+++ t/op/die.t (working copy)
@@ -1,8 +1,15 @@
use v6;
-say 1..2;
+say 1..3;
if (eval 'die foo; 1') { say not ok 1 } else { say ok 1 };
my $error;
eval '$error = $!'; # pugs does not know $! yet
if ($error eq 'foo' ) { say ok 2 # TODO die } else { say not ok 2 # TODO
die }
+
+my $foo = -foo-;
+eval '$foo = die bar';
+$foo; # this is testing for a bug where an error is stored into $foo in
+ # the above eval; unfortunately the if below doesn't detect this on it's
+ # own, so this lone $foo will die if the bug is present
+if ($foo eq -foo-) { say ok 3 } else { say not ok 3 }
