John Meacham wrote (... but I've reordered things):
My only real 'must-have' is that the 4 modes all can be explicitly and
unambiguously specified. I have opinions on the syntax/hints but
that is
more flexable.
I basically agree (the syntax discussion will take place in the years
after th
On Mon, Apr 03, 2006 at 02:00:33PM -0400, Wolfgang Thaller wrote:
> Sorry for the length of this. There are three sections: the first is
> about how I don't like for "nonconcurrent" to be the default, the
> second is about bound threads and the third is about implementing
> concurrent reentra
Sorry for the length of this. There are three sections: the first is
about how I don't like for "nonconcurrent" to be the default, the
second is about bound threads and the third is about implementing
concurrent reentrant on top of state threads.
no, state-threads, a la NSPR, state-threads
f x xs = let g y = x+y in map !! g xs
I'm imagining that this !! would not evaluate x, in much the same way as
!!(const 42 undefined)
==>
42
The program generating the deepSeq argument is free to use laziness
as much as it wants, just the (non functional parts of the) resul
John Meacham wrote:
> On Mon, Apr 03, 2006 at 05:22:34PM +0200, Benjamin Franksen wrote:
>> On Monday 03 April 2006 08:38, John Meacham wrote:
>>> On Sat, Apr 01, 2006 at 07:31:05AM -0500, David Roundy wrote:
I'd like to be sure that asynchronous exceptions can get into the
standard. They
On Mon, Apr 03, 2006 at 05:22:34PM +0200, Benjamin Franksen wrote:
> On Monday 03 April 2006 08:38, John Meacham wrote:
> > On Sat, Apr 01, 2006 at 07:31:05AM -0500, David Roundy wrote:
> > > I'd like to be sure that asynchronous exceptions can get into the
> > > standard. They require concurrency,
On Monday 03 April 2006 08:38, John Meacham wrote:
> On Sat, Apr 01, 2006 at 07:31:05AM -0500, David Roundy wrote:
> > I'd like to be sure that asynchronous exceptions can get into the
> > standard. They require concurrency, but I'm not sure that they're
> > included in John's page.
>
> I am assumi
On Apr 3, 2006, at 7:16 AM, Simon Peyton-Jones wrote:
Interesting idea.
What would you expect to happen here?
f x xs = let g y = x+y in map !! g xs
Here I'm evaluating the function g hyperstrictly before the call to
map.
Does x, the free variable in g's function closure, get evalu
On 4/3/06, John Meacham <[EMAIL PROTECTED]> wrote:
> the tasks for which state-threads work well for are IO bound
> multiplexing tasks, pthreads are better for CPU-bound tasks.
Why not make this explicit?
forkCPU :: IO () -> IO ()
On systems incapable of preemption, forkCPU = id. The semantics o
On Sun, Apr 02, 2006 at 11:38:23PM -0700, John Meacham wrote:
> On Sat, Apr 01, 2006 at 07:31:05AM -0500, David Roundy wrote:
> > I'd like to be sure that asynchronous exceptions can get into the
> > standard. They require concurrency, but I'm not sure that they're
> > included in John's page.
>
Interesting idea.
What would you expect to happen here?
f x xs = let g y = x+y in map !! g xs
Here I'm evaluating the function g hyperstrictly before the call to map.
Does x, the free variable in g's function closure, get evaluated?
>From an implementation point of view, you could imag
| By the way, the description in the GHC User's Guide 7.4.12.2:
|
| newtype T v1...vn = T' (S t1...tk vk+1...vn) deriving (c1...cm)
|
| is too restrictive in requiring that S must be a type constructor of
| the same arity as T, forbidding things like
|
| newtype Wrap m a = Wrap (m a
On Mon, Apr 03, 2006 at 11:38:08AM +0100, Ross Paterson wrote:
> On Fri, Mar 31, 2006 at 01:15:03PM -0800, John Meacham wrote:
> > On Fri, Mar 31, 2006 at 04:21:26PM +0100, Simon Marlow wrote:
> > > Great. Apart from my misgivings about allowing cooperative scheduling
> > > at all, here's a few co
GHC 6.4 has rather conservative constraints on instances to guarantee
termination. GHC 6.5 has more liberal constraints; see
http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki/FlexibleInstances
Unfortunately instances generated by newtype-deriving need not satisfy
either of these cons
Hello John,
Monday, April 3, 2006, 12:53:05 PM, you wrote:
>> new stacks can be allocated by alloca() calls. all these
>> alloca-allocated stack segments can be used as pool of stacks assigned
>> to the forked threads. although i don't tried this, my own library
>> also used processor-specific met
On Fri, Mar 31, 2006 at 01:15:03PM -0800, John Meacham wrote:
> On Fri, Mar 31, 2006 at 04:21:26PM +0100, Simon Marlow wrote:
> > Great. Apart from my misgivings about allowing cooperative scheduling
> > at all, here's a few comments on the proposal:
>
> much much preferable to a standard that no
On Sat, Apr 01, 2006 at 02:30:30PM +0400, Bulat Ziganshin wrote:
> new stacks can be allocated by alloca() calls. all these
> alloca-allocated stack segments can be used as pool of stacks assigned
> to the forked threads. although i don't tried this, my own library
> also used processor-specific me
On 31 March 2006 13:41, John Meacham wrote:
> I have tried to summarize the current thinking into a proposal on the
> wiki.
>
>
http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki/Concurrenc
y
>
> I split it into 3 parts.
>
> the standard - all haskell' compilers must implement
>
> o
18 matches
Mail list logo
