John Meacham wrote
> [Rule 1]
> * in a cooperative implementation of threading, any thread with value
> _|_ may cause the whole program to have value _|_. In a preemtive one,
> this is not true.
> would the simple qualifier
> 'if there exists another runnable thread'
> solve the issues?
if
On Tue, Apr 11, 2006 at 09:05:12PM -0700, [EMAIL PROTECTED] wrote:
> > [Rule 1]
> > * in a cooperative implementation of threading, any thread with value
> > _|_ may cause the whole program to have value _|_. In a preemtive one,
> > this is not true.
>
> I'm afraid that claim may need qualific
On 4/11/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> > [Rule 1]
> > * in a cooperative implementation of threading, any thread with value
> > _|_ may cause the whole program to have value _|_. In a preemtive one,
> > this is not true.
>
> I'm afraid that claim may need qualifications:
> [Rule 1]
> * in a cooperative implementation of threading, any thread with value
> _|_ may cause the whole program to have value _|_. In a preemtive one,
> this is not true.
I'm afraid that claim may need qualifications:
1. if there is only one runnable thread, if it loops in pure code,
t
On Tuesday 11 April 2006 01:09 pm, isaac jones wrote:
> I'd like to ask the list to postpone discussion on exceptions and
> deepSeq until a later iteration. While these are two topics that are of
> deep importance to me, I would prefer to focus on the other two topics
> at hand until they are solv
Sorry for the long delay in responding to this message---this issue
takes all the brain cells I've got in one go.
Ordinarily I'd trim the forgoing discussion, but it was rusty enough
that I've retained it:
On Apr 4, 2006, at 7:12 AM, Simon Marlow wrote:
Jan-Willem - thanks for your thought
Yes, I realize than dynamic idempotence is not the same as
cycle detection. I still worry. :)
I think expectance is in the eye of the beholder. The reason
that (the pure subset of) pH was a proper implementation of
Haskell was because we were not over-specifying the semantics
originally. I wou
I'd like to be a bit more formal when it comes to the distinction
between cooperative and preemptive implementations of concurrency, here
is a first attempt.
1. termination,
In a concurrent implementation, a thread performing an infinite loop
with no IO or interaction with the outside world can p
On Tue, Apr 11, 2006 at 02:19:22PM +0100, Simon Peyton-Jones wrote:
> | > newtype Id = Id Int
> | > data Term = ...
> | > newtype Subst = Subst (IM.IntMap Term)
> |
> | ideally, we'd like an MapLike instance, but we'd have to tediously
> write
> | it ourselves. if we allow the supergeneralized new
I'd like to ask the list to postpone discussion on exceptions and
deepSeq until a later iteration. While these are two topics that are of
deep importance to me, I would prefer to focus on the other two topics
at hand until they are solved. That is, concurrency, and the class
system.
I'm still po
On 2006-04-11, Ross Paterson <[EMAIL PROTECTED]> wrote:
> On Tue, Apr 11, 2006 at 09:13:00AM +0100, Simon Marlow wrote:
>> - the default should be... concurrent reentrant, presumably, because
>>that is the safest. (so we need to invert the notation).
>
> I think the name "concurrent" has a si
On Mon, Apr 10, 2006 at 02:19:23PM -0700, John Meacham wrote:
> On Mon, Apr 10, 2006 at 02:58:20PM +0100, Simon Marlow wrote:
> > Suppose I want to do some action with a temporary file:
> >
> >bracket
> >newTempFile
> >(\f -> removeTempFile f)
> >(\f -> doSomethingWith
I like this idea. Needs fleshing out though.
| * you can only newtype derive the last argument to a MPTC.
| * you cannot co-derive an instance for multiple newtype renamings.
|
| it seems that both these can be solved when combined with the other
| proposed extension, allowing deriving clauses
On Mon, Apr 10, 2006 at 06:48:35PM +0100, Claus Reinke wrote:
> note also that we are talking about different things here: I am talking
> about FD consistency, you are talking about the FD consistency condition.
That would explain a few things.
> as this example shows once again, there are insta
| Well, my worry was partly about the suggested version of deepSeq that
| would not diverge on circular structures (since circular structures
| are just one way to implement "infinite" data structures).
Dynamic idempotence is not the same as detecting circular structures.
Deepseqing a circular str
On 11 April 2006 13:54, John Meacham wrote:
> On Tue, Apr 11, 2006 at 01:43:18PM +0100, Simon Marlow wrote:
>> yes, when I say "one throw" I was referring to the argument type, not
>> the return type. We should still have ioError - although it would
>> probably be better named throwIO:
>
> Ah, I
On Tue, Apr 11, 2006 at 01:43:18PM +0100, Simon Marlow wrote:
> yes, when I say "one throw" I was referring to the argument type, not
> the return type. We should still have ioError - although it would
> probably be better named throwIO:
Ah, I see what you mean now.
would it be possible to use T
On 11 April 2006 13:35, John Meacham wrote:
> On Tue, Apr 11, 2006 at 01:24:07PM +0100, Simon Marlow wrote:
>> Attached is another variant of the extensible exceptions idea, it
>> improves on the previous designs in a couple of ways: there's only
>> one catch & throw, regardless of what type you'
Simon Peyton-Jones wrote:
| Any function that is not defineable in (pure) Haskell should be viewed
| with utmost suspicion. The seq function is one of these. At least
| seq has simple denotational semantics, which can't be said for
deepSeq.
|
| I say, put deepSeq in a type class (which is what
On Tue, Apr 11, 2006 at 05:35:12AM -0700, John Meacham wrote:
> throw x >> return () -> _|_
hmm.. actually is this true? hmm.. seq and IO always mixed oddly.
John
--
John Meacham - ⑆repetae.net⑆john⑈
___
Haskell-prime mailing list
Haskell-prim
John Meacham <[EMAIL PROTECTED]> writes:
> forkIO action = forkIO' action' where
> action' = do
> myThreadId >>= onExit . throwTo PleaseExit
> action
This would be a memory leak: even after the thread finishes,
its onExit handler would remain registered.
On Tue, Apr 11, 2006 at 01:24:07PM +0100, Simon Marlow wrote:
> Attached is another variant of the extensible exceptions idea, it
> improves on the previous designs in a couple of ways: there's only one
> catch & throw, regardless of what type you're throwing or catching.
> There is an extensible
Attached is another variant of the extensible exceptions idea, it
improves on the previous designs in a couple of ways: there's only one
catch & throw, regardless of what type you're throwing or catching.
There is an extensible hierarchy of exceptions, and you can catch and
re-throw subclasses of
"Simon Marlow" <[EMAIL PROTECTED]> writes:
> How does "cancelling" a thread differ from sending it an exception?
It doesn't. By cancelling I mean just sending a particular async
exception.
> Can a thread be GC'd without being sent an exception first?
Yes, but I'm now changing this.
Unfortunate
| instance Eval (a -> b) where
|
You could say the same of instance Num Int, because Int is a primitive
type. But yes, seq on functions is not lambda-definable, and that is
indeed a qualitivative difference between seq and deepSeq I agree.
It's not worth making a meal of this. All
On Tue, Apr 11, 2006 at 12:15:57PM +0100, Simon Peyton-Jones wrote:
> | well, there is a difference there in that 'seq' is unimplementable in
> | haskell, so the design comitee had freedom to implement it however
> they
> | wanted.
>
> class Eval a where
> seq :: a -> b -> b
>
| well, there is a difference there in that 'seq' is unimplementable in
| haskell, so the design comitee had freedom to implement it however
they
| wanted.
class Eval a where
seq :: a -> b -> b
instance Eval (a,b) where
seq (_,_) b = b
instan
On Tue, Apr 11, 2006 at 08:54:32AM +0100, Simon Marlow wrote:
> now If I have a handler registered that throws an exception to the
> current thread, what happens? handleLoop is aborted, the exception is
> propagated to the top level of the thread, where the top-level exception
> handler calls exit
On Tue, Apr 11, 2006 at 09:53:54AM +0100, Simon Peyton-Jones wrote:
> Whether it should be in a class is a rather separate discussion. In a
> way we already sold out when we allowed seq to escape from the
> type-class world. Perhaps deepSeq is worse (because it traverses data
> structures) but no
On Tue, Apr 11, 2006 at 09:13:00AM +0100, Simon Marlow wrote:
> What are the conclusions of this thread?
>
> I think, but correct me if I'm wrong, that the eventual outcome was:
>
> - concurrent reentrant should be supported, because it is not
>significantly more difficult to implement than
On Tue, Apr 11, 2006 at 11:35:09AM +0100, Simon Marlow wrote:
> On 11 April 2006 11:08, Ross Paterson wrote:
>
> > On Tue, Apr 11, 2006 at 11:03:22AM +0100, Simon Marlow wrote:
> >> This is a rather useful extension, and as far as I can tell it
> >> doesn't have a ticket yet:
> >>
> >> http://
On 11 April 2006 11:08, Ross Paterson wrote:
> On Tue, Apr 11, 2006 at 11:03:22AM +0100, Simon Marlow wrote:
>> This is a rather useful extension, and as far as I can tell it
>> doesn't have a ticket yet:
>>
>> http://www.haskell.org//pipermail/libraries/2005-March/003494.html
>>
>> should I
On Tue, Apr 11, 2006 at 11:03:22AM +0100, Simon Marlow wrote:
> This is a rather useful extension, and as far as I can tell it doesn't
> have a ticket yet:
>
> http://www.haskell.org//pipermail/libraries/2005-March/003494.html
>
> should I create a ticket? Is there any reason it might be hard
This is a rather useful extension, and as far as I can tell it doesn't
have a ticket yet:
http://www.haskell.org//pipermail/libraries/2005-March/003494.html
should I create a ticket? Is there any reason it might be hard to
implement?
Cheers,
Simon
_
Hello John,
Tuesday, April 11, 2006, 2:43:49 AM, you wrote:
> true. in any case, deepseq is not always a win.
don't forget that Andy don't plan to apply deepSeq to any expression.
in his program, there is a LARGE datastructure with a couple of
unevaluated thunks what may be simplified by call to
Hello Ross,
Tuesday, April 11, 2006, 3:43:18 AM, you wrote:
> The favourite customer for FDs has been the monad transformer library.
> What other libraries should Haskell' support, and what are their
> requirements?
why you think that FD are required only for libs? :) i think it's
better to as
| Any function that is not defineable in (pure) Haskell should be viewed
| with utmost suspicion. The seq function is one of these. At least
| seq has simple denotational semantics, which can't be said for
deepSeq.
|
| I say, put deepSeq in a type class (which is what I've done when I
need
| it)
On Tue, Apr 11, 2006 at 09:13:00AM +0100, Simon Marlow wrote:
> - the default should be... concurrent reentrant, presumably, because
>that is the safest. (so we need to invert the notation).
I think the name "concurrent" has a similar problem to "safe": it reads
as an instruction to the impl
What are the conclusions of this thread?
I think, but correct me if I'm wrong, that the eventual outcome was:
- concurrent reentrant should be supported, because it is not
significantly more difficult to implement than just concurrent.
- the different varieties of foreign call should all b
On 10 April 2006 22:19, John Meacham wrote:
> On Fri, Apr 07, 2006 at 02:58:01PM +0100, Simon Marlow wrote:
>> According to your definition of exitWith above, I can't both raise an
>> exception *and* exit in the same thread. If I register an onExit
>> handler that throws an exception to the curren
On 10 April 2006 22:41, Andy Gill wrote:
> Why can't we just steal a bit in the (GHC)
> info table,
> rather than mess with LSB of pointers, or have two info tables?
Because you need one bit per constructor *instance*. eg. there are two
variants of Just: the normal one, and the deepSeq'd one. S
41 matches
Mail list logo
