On Mon, Mar 27, 2006 at 03:36:55PM +0100, Simon Marlow wrote:
But before we get carried away figuring out all the pros and cons of
various options, let me point out once again that
This is just a marketing decision
Because
(a) we're going to standardise concurrency anyway
On Tue, Mar 28, 2006 at 10:25:04AM +0100, Simon Marlow wrote:
On 28 March 2006 00:24, Ross Paterson wrote:
How about STM (minus retry/orElse) and TVars as the portable
interface? They're trivial for a single-threaded implementation, and
provide a comfortable interface for everyone.
It
On 29 March 2006 11:00, Ross Paterson wrote:
On Tue, Mar 28, 2006 at 10:25:04AM +0100, Simon Marlow wrote:
On 28 March 2006 00:24, Ross Paterson wrote:
How about STM (minus retry/orElse) and TVars as the portable
interface? They're trivial for a single-threaded implementation, and
provide a
On 28 March 2006 00:24, Ross Paterson wrote:
On Mon, Mar 27, 2006 at 09:36:28AM +0100, Simon Marlow wrote:
The portable interface could be Control.Concurrent.MVar, perhaps.
As Malcolm pointed out, using MVars requires some care, even if you
were just aiming to be thread-safe.
I don't
On 28 March 2006 00:24, Ross Paterson wrote:
How about STM (minus retry/orElse) and TVars as the portable
interface? They're trivial for a single-threaded implementation, and
provide a comfortable interface for everyone.
It just occurred to me that STM isn't completely trivial in a
Simon Marlow [EMAIL PROTECTED] wrote:
(a) we're going to standardise concurrency anyway
Well, but that only begs the question, what *kind* of concurrency are we
going to standardise on? e.g. Will we admit all variations of scheduling
(co-operative, time-slice, and pre-emptive)?
(b) it is
On Tue, Mar 28, 2006 at 10:14:27AM +0100, Simon Marlow wrote:
On 28 March 2006 00:24, Ross Paterson wrote:
As Malcolm pointed out, using MVars requires some care, even if you
were just aiming to be thread-safe.
I don't really understand the problem, maybe I'm missing something. I
thought
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
On 26 March 2006 02:31, isaac jones wrote:
Possible Interests:
1. I can write tools like filesystems, web servers, and GUIs in
Haskell'
2. Libraries that I use are thread-safe
3. I can compile my code with any Haskell' compiler
4. Tools such as debuggers and tracers that claim to
On Mon, Mar 27, 2006 at 09:36:28AM +0100, Simon Marlow wrote:
On 26 March 2006 03:44, Ross Paterson wrote:
[...] the key point is that
a Haskell' module that does not use concurrency, but is thread-safe,
ought to work with non-concurrent implementations too.
To make that work, we'd
On 3/27/06, Ross Paterson [EMAIL PROTECTED] wrote:
How about STM (minus retry/orElse) and TVars as the portable interface?
They're trivial for a single-threaded implementation, and provide a
comfortable interface for everyone.
+1 on STM as the core interface. Why do you suggest omitting
On 2006-03-28, Taral [EMAIL PROTECTED] wrote:
On 3/27/06, Ross Paterson [EMAIL PROTECTED] wrote:
How about STM (minus retry/orElse) and TVars as the portable interface?
They're trivial for a single-threaded implementation, and provide a
comfortable interface for everyone.
+1 on STM as the
Hello Ross,
Saturday, March 25, 2006, 4:16:01 AM, you wrote:
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
On Sat, 2006-03-25 at 13:17 +0300, Bulat Ziganshin wrote:
Hello Ross,
Saturday, March 25, 2006, 4:16:01 AM, you wrote:
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
14 matches
Mail list logo
