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: > > http://homepages.inf.ed.ac.uk/wadler/linksetaps/slides/peyton-jones.ppt > > 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 approach). 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 META.yml).
