"Simon Marlow" <[EMAIL PROTECTED]> writes:
> I think it would be a mistake to relegate concurrency to an addendum;
> it is a central feature of the language, and in fact is one area where
> Haskell (strictly speaking GHC) is really beginning to demonstrate
> significant advantages over other langu
On Tue, Mar 28, 2006 at 10:49:36AM +0100, Malcolm Wallace wrote:
> Tomasz Zielonka <[EMAIL PROTECTED]> wrote:
> > http://www.uncurry.com/repos/FakeSTM/
> >
> > Perhaps it could serve as a drop-in replacement for STM in haskell
> > compilers which don't implement STM directly.
>
> Nice idea.
On Tue, Mar 28, 2006 at 11:05:03AM +0100, Malcolm Wallace wrote:
> I was misled by several people's hand-waving assertion that, provided
> you used MVars "correctly", there would be no synchronisation problems.
> But no-one had yet defined what "correct" meant. I kind of assumed they
> meant you c
On Tue, 2006-03-28 at 11:05 +0100, Malcolm Wallace wrote:
(snip)
> * IORef is inherently thread-unsafe, and so we should eliminate IORefs
> from the language.
That's not quite true, as you can have an IORef guarded by an MVar. Why
would you want such a thing? For instance, you might write
On 27 March 2006 18:51, Neil Mitchell wrote:
> * Its simulated concurrency, if you have two processors, only one will
> ever be used. The only exception is FFI, where a number of FFI calls
> can run in parallel with some Haskell code. This means that no locking
> is needed on the global heap.
I
"Simon Marlow" <[EMAIL PROTECTED]> wrote:
> >> The portable interface could be Control.Concurrent.MVar, perhaps.
>
> I don't really understand the problem, maybe I'm missing something. I
> thought the idea would be that a thread-safe library would simply use
> MVar instead of IORef.
I was misle
Tomasz Zielonka <[EMAIL PROTECTED]> wrote:
> It may be relevant for this discussion: I believe I reimplemented STM,
> including retry and orElse, on top of old GHC's concurrency
> primitives.
>
> http://www.uncurry.com/repos/FakeSTM/
>
> Perhaps it could serve as a drop-in replacement for STM
> it's too hard to implement (and it's not always hard
> - the YHC guys
> managed it in a matter of days
Tom is the one who implemented it in Yhc, and details can be found
http://www.haskell.org/haskellwiki/Yhc/RTS/Concurrency
but some of the reasons that it was easier than in other compilers are
John Goerzen <[EMAIL PROTECTED]> wrote:
> On Fri, Mar 24, 2006 at 11:07:53AM +, Malcolm Wallace wrote:
> > I assume that since a non-concurrent implementation has
> > only one thread, that thread will be trying to MVar-synchronise with
> > something that does not exist, and hence
On Fri, Mar 24, 2006 at 02:47:09PM -, Simon Marlow wrote:
> I think it would be a mistake to relegate concurrency to an addendum; it
> is a central feature of the language, and in fact is one area where
> Haskell (strictly speaking GHC) is really beginning to demonstrate
> significant advantage
On Fri, Mar 24, 2006 at 11:07:53AM +, Malcolm Wallace wrote:
> threads, and I assume that since a non-concurrent implementation has
> only one thread, that thread will be trying to MVar-synchronise with
> something that does not exist, and hence be blocked for ever. I can
Not necessarily. An
Simon Marlow:
> On 24 March 2006 12:28, Ross Paterson wrote:
>
> > On Fri, Mar 24, 2006 at 11:30:57AM -, Simon Marlow wrote:
> >> So I believe the issue is mainly one of perspective. Until I wrote
> >> this email I hadn't thought of (4) and my preference was for (2),
> >> but now I quite like
On 24 March 2006 12:28, Ross Paterson wrote:
> On Fri, Mar 24, 2006 at 11:30:57AM -, Simon Marlow wrote:
>> So I believe the issue is mainly one of perspective. Until I wrote
>> this email I hadn't thought of (4) and my preference was for (2),
>> but now I quite like the idea of (4). We woul
On Fri, Mar 24, 2006 at 11:30:57AM -, Simon Marlow wrote:
> So I believe the issue is mainly one of perspective. Until I wrote this
> email I hadn't thought of (4) and my preference was for (2), but now I
> quite like the idea of (4). We would include concurrency in Haskell',
> but provide a
On 24 March 2006 09:55, Ross Paterson wrote:
> Do you envisage Haskell' implementations that do not support
> concurrency?
Clearly there will be some, the question is what status do they have.
It boils down to a choice between:
(1) Haskell' does not include concurrency. Concurrent programs
Ross Paterson <[EMAIL PROTECTED]> wrote:
> > http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki/Concurrency
>
> Do you envisage Haskell' implementations that do not support
> concurrency?
This is one of the outstanding questions in the proposal itself.
To aid discussion, here is what
On Wed, Mar 22, 2006 at 10:54:57AM -, Simon Marlow wrote:
> On 21 March 2006 23:51, isaac jones wrote:
> > Concurrency is summarized here:
> >
> http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki/Concurrency
>
> I have updated the concurrency page with a skeleton proposal.
Do you e
Simon Marlow:
> On 21 March 2006 23:51, isaac jones wrote:
>
> > Concurrency is summarized here:
> >
> http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki/Concurrenc
> y
>
> I have updated the concurrency page with a skeleton proposal.
Yes, good plan.
Manuel
On 21 March 2006 23:51, isaac jones wrote:
> Concurrency is summarized here:
>
http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki/Concurrenc
y
I have updated the concurrency page with a skeleton proposal.
Cheers,
Simon
___
Haskell-pr
On Tue, 2006-03-21 at 15:27 -0800, Ashley Yakeley wrote:
> isaac jones wrote:
>
> > The topics that John and I feel are critical, and rather unsolved,
> > are:
> > * The class system (MPTC Dilemma, etc)
> > * Concurrency
> > * (One more, perhaps standard libraries)
>
> Could you summarise the
isaac jones wrote:
The topics that John and I feel are critical, and rather unsolved,
are:
* The class system (MPTC Dilemma, etc)
* Concurrency
* (One more, perhaps standard libraries)
Could you summarise the current state of these?
--
Ashley Yakeley, Seattle WA
WWED? http://www.cs.utexas.
On 3/21/06, isaac jones <[EMAIL PROTECTED]> wrote:
> I'd like to ask folks to please bring currently open threads to a close
> and to document the consensus in tickets. Anyone can edit tickets, so
> please don't be shy.
Claus, can you document some of your FD work in the
FunctionalDependencies ti
22 matches
Mail list logo
