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. So
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 current
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
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
| 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
|
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
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
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 to
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 create a
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 just
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 not
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
| 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
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
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.
Unfortunately it
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
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
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 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
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
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're
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
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 see what
| 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
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
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
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 f)
Under
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 similar
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
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 newtype
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
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
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 solved.
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:
I was
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 qualifications:
35 matches
Mail list logo
