Simon Marlow: > On 26 March 2006 03:44, Ross Paterson wrote: > > > On Sat, Mar 25, 2006 at 05:31:04PM -0800, isaac jones wrote: > >> I have no idea if it would work, but one solution that Simon didn't > >> mention in his enumeration (below) is that we could find a group of > >> people willing to work hard to implement concurrency in Hugs, for > >> example, under Ross's direction. > > > > I'm no expert on Hugs internals, and certainly not qualified to direct > > such an effort, but I don't have great hopes for it. Apart from the > > fact that Hugs is written in a legacy language and uses a quite a bit > > of global state, it also makes heavy use of the C stack, and any > > implementation that does that will have trouble, I think. > > Yes, I don't see an easy way to do it. You could have one OS thread per > Haskell thread (let the OS manage the separate C stacks), a giant lock > around the interpreter (to protect all the global state), and explicit > yield() from time to time to simulate pre-emption. This isn't too bad, > but you still have to implement GC somehow, and hence traverse all the > live C stacks, and that sounds tricky to me.
True, but so what? I mean, honestly, we should decide language features by their merit to applications and maturity. We should also take into account what the power/weight ratio of a feature is in terms of general implementation costs. But discussing the costs to one particular implementation that's already been stretched light years beyond what it originally was intended for, seems a bit much. Manuel _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
