Hey! Welcome back our show, gay camels[1] in denial! On todays show, those who can't shut up won't, and will send you another email!
Today's issues cover STM, and just that.
Perl6 should have some kind of
atomic {
...
}
going on, AFAIK.
We already know how to keep it happy: make the changes local, help
consistency checks be optimizable, blah blah blah. Haskell does it
with the fact that most of the code is pure, and that means you only
have to check for a few things. Haskell also has type purity, that
keeps IO out of the mess.
So, here is a bit of food for thought, on efficiency and usability
of STM in Perl6.
Usability of STM in perl can be enhanced on two aspects - TIMTOWDI,
so we can allow IO, or not allow it, without special magic -
everyone gets to choose, and another thing I have in mind is the
Transactional role...
DBI::Handle does Transactional;
To the STM rollbacker and type checker thingy this means that any IO
performed by DBI::Handle invoked code is OK - it can be reversed
using the Transactional interface it proposes.
Let's get carried away: The Exclusive role - an object which can
only atomically talk to one thread at a time, or the Pure role - a
read only object that can be omitted from journaling (remember the
pure function trait?).
Now to deal with efficiency...
First of all, to make it fast we have something almost as good as
functional purity - lexical scopes. And they are being pushed like
mad, too. As long as something was created within the current atomic
scope, and didn't leak out of the scope (detectable at compile time
for simple values), it's safe, and can be omitted from the journal.
What's troubling me is deeper data types. What are the semantics
Perl 6 will have WRT data cloning and threads? I think by now we
have a tight enough language that share by default can actually work
- we have lexical control over many things, no more globals for
lexical settings, and so forth. OTOH, we also have COW in parrot,
which suggests that duplicating everything is cheap (personally I'd
like to have both, and precise control over what the thread you are
creating will be).
If everything is copy by default, we only have to journal shared
data. We can optimize for this on the thread level - a copied thread
has cheaper STM later.
One more aspect we can propose is that if a function is known to be
unsafe, we can pessimize the STM operation - kind of like
sub foo : locked {
}
in perl 5 (i forget how it's actually written, but I remember I saw
it). Does anybody have any idea how we can guess this?
Anyway, I'm done with my brainstorming... Sorry for the post being
so chaotic.
Ciao!
[1] http://lambda.org/
--
() Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker &
/\ kung foo master: /me spreads pj3Ar using 0wnage: neeyah!!!!!!!!!!!
pgphgrAQBlnw9.pgp
Description: PGP signature
