develooper Front page | perl.perl6.language | Postings from April 2005

Re: Sun Fortress and Perl 6

Thread Previous | Thread Next
Rafael Garcia-Suarez
April 27, 2005 01:33
Re: Sun Fortress and Perl 6
Message ID:
Autrijus Tang wrote in perl.perl6.language :
> 4. Software Transaction Memory
> Like GHC Haskell, Fortress introduces the `atomic` operator that takes a
> block, and ensures that any code running inside the block, in a
> concurrent setting, must happen transactionally -- i.e. if some
> precondition is modified by another thread before this block runs
> completely, then it is rolled back and tried again.  This slides covers
> some aspects of STM as used in GHC:
> In Fortress, there is also an `atomic` trait for functions, that
> declares the entire function as atomic.

Interesting; and this rolling-back approach avoids the deadlock issues
raised by the use of semaphores (like in Java's synchronization

But, as the slides point out, you can't do I/O or syscalls from an
atomic function; and in Haskell you can ensure that with the wise use of
monads. Perl 6 has no monads, last time I checked...

> 6. Database-indexed module management
> An embedded database (such as SQLite) can be used to track different
> revisions of installed modules on the local machine, manage upgrades,
> check api compatibility, and keep related logs; see Chapter 4 for
> details.  I have long wanted something like that for CPANPLUS, instead
> of the current, limited, nonversioned, unrevertable, partial information
> provided by .packlist files.

Plea : don't mess up with the job of the packagers and of the package
manangement systems. You can write one, or several, but you can't assume
they will be used, or that only one of them will be used at the same
time on the same system. I think that if somethings needs to be
standardised here is a complete, correct, useful metadata format (à la

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About