April 2006 - Haskell-prime

RE: Exceptions
by Simon Marlow 11 Apr '06

11 Apr '06

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 you mean now. > > would it be possible to use Typeable1 to just catch 'ArithException a' > for any Typeable a? It seems like it should be, but I have not used > Typeable1 much. I tried it briefly and couldn't get it to work, but I'm no expert on the SYB stuff. You might need an Exception1 class to go with Typeable1, and that would be fairly ugly. Cheers, Simon

1 0

RE: Exceptions
by Simon Marlow 11 Apr '06

11 Apr '06

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 throwing or >> catching. There is an extensible hierarchy of exceptions, and you >> can catch and re-throw subclasses of exceptions. > > I made the catch and throw separate so the decision as to whether to > include imprecice exceptions and extensible extensions can be made > independently. > > that and > > throw x /= ioError x > > ioError x >> return () -> IO _|_ (only _|_ when IO action executed) > throw x >> return () -> _|_ > > ioError x `seq` () -> () > throw x `seq` () -> _|_ 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: http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Excep tion.html#v%3AthrowIO (the docs for throwIO also mention the strictness property you described above) Cheers, Simon

2 1

RE: Exceptions
by Simon Marlow 11 Apr '06

11 Apr '06

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 exceptions. So this design contains a dynamically-typed extensible hierarchy, but it's fairly lightweight. Adding a new leaf exception type requires 3 lines + 1 line for each superclass (just 1 line for a top level leaf, as before). Adding a new node requires about 10 lines + 1 line for each superclass, msotly boilerplate. Perhaps the type class hackers can do better than this! Cheers, Simon

2 2

RE: Signals + minimal proposal
by Simon Marlow 11 Apr '06

11 Apr '06

On 09 April 2006 16:02, Marcin 'Qrczak' Kowalczyk wrote: > "Simon Marlow" <simonmar(a)microsoft.com> writes: > >> That sounds hard to program with - surely you want to stop the >> program in order to clean up? Otherwise the program is going to >> continue working, generating more exit handlers, and we might never >> get to exit. > > Here is how I've done it in Kogut: > > An equivalent of Haskell's exitWith simply throws a predefined > exception. When an unhandled exception reaches the toplevel, this > exception is treated specially and is not printed with a stack trace. > Exceptions caused by system signals are special too. > > There is a central list of registered exit handlers. On program exit > each handler is run once. Handlers registered during this cleanup are > run too. Any exceptions thrown from handlers are caught and ignored. > This happens after printing a stack trace from an unhandled exception, > just before shutting down the runtime and exiting. > > One of exit handlers cancels all other threads (except those which > has been garbage collected) and waits until they finish. New threads > started during this cleanup are canceled too. Can a thread be GC'd without being sent an exception first? How does "cancelling" a thread differ from sending it an exception? Cheers, Simon

2 1

RE: deeqSeq proposal
by Simon Peyton-Jones 11 Apr '06

11 Apr '06

| 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 I'm saying is that there are two distinct decisions 1. Add seqFun :: (a->b) -> c -> c 2. Given (1), one could provide seq via a type-class, or without. H98 chooses the latter For deepSeq, (1) doesn't arise, but the same choice arises for (2), and with the same arguments for and against. See in particular John Hughes's impassioned pleas for not changing type signatures "all the way up" when adding a 'seq'. I don't think we disagree here. But equally I don't there's a clear "right" answer. Simon

1 0

RE: deeqSeq proposal
by Simon Peyton-Jones 11 Apr '06

11 Apr '06

| 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 instance Eval [a] where seq [] b = b seq (_:_) b = b etc Simon

2 1

RE: Signals + minimal proposal (was Re: asynchronous exceptions)
by Simon Marlow 11 Apr '06

11 Apr '06

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 thread, things go >> wrong if the current thread also calls exitWith. Also, you couldn't >> call exitWith while holding an MVar, if the handlers need access to >> the same MVar. > > hrm? nothing goes wrong. it is the same as calling 'throw' in the > current thread. Your code for exitWith: exitWith status = do takeMVar exitMVar -- winner takes all let handleLoop = do hs <- swapMVar handlerMVar [] sequence_ hs if null hs then return () else handleLoop handleLoop exitWith_ status 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 exitWith again, and promptly deadlocks because exitMVar is already empty. In the interests of keeping the discussion manageable, I'll deal with the rest of the points later. Cheers, Simon

2 1

Defaults for superclass methods
by Simon Marlow 11 Apr '06

11 Apr '06

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

2 1

RE: deeqSeq proposal
by Simon Marlow 11 Apr '06

11 Apr '06

On 07 April 2006 22:38, Andy Gill wrote: > On Apr 7, 2006, at 3:59 AM, Rene de Visser wrote: > >> Hello, >> >> As deepSeq has a non local effect, I think it requires a non-local >> source transformation to implement it. One option would be for the >> compiler to create a second deepSeq version of every function >> definition. >> >> e.g. >> >> If the user defines a function f >> >> f x = g h x >> >> then the compile creates an additional function !!f >> >> !!f x = temp `seq` temp >> where temp = !!g !!h x >> >> which uses the compiler generated functions !!g and !!h. >> >> It looks like library writers are increasingly doing this manually. >> Creating a strict and non strict version of a number of the >> functions provided. This would automate that. >> >> Rene. >> > > It depend on the semantics of deepSeq. If deepSeq just performs seq > on all constructors recursively, then > that can be implemented as a runtime primitive. If deepSeq is making > all embedded partial applications > strict, then yes this might be a non-local effect. > > What are the semantics of !!(\ x -> ...)? > > I am calling for the version of deepSeq/strict that evaluates all > thunks, but does not strictify the arguments > to partial application, because > - I believe this is straightforward to implement It's not *completely* straightforward to implement, at least in GHC, and at least if you want to implement it in a modular way (i.e. without touching lots of different parts of the system). The obvious way to "add a bit to a closure" is to use the LSB of the info pointer, which currently is always 0. However, that means masking out this bit every time you want to get the info pointer of a closure, which means lots of changes to the runtime. The price seems pretty high. An alternative is to have two info tables for every constructor, one normal one and one "deepSeq'd", and the normal one probably needs to point to the deepSeq'd version. This doesn't require masking out any bits, but it does increase code size (one extra info table + entry code for every constructor, except possibly those that don't contain any pointer fields), and one extra field in a constructor's info table. Plus associated cache pollution. Yet another alternative is to store fully evaluated data in a segregated part of the heap. The garbage collector could do this - indeed we already do something similar, in that data that has no pointer fields is kept separate. Checking the "deepSeq" bit on a closure is then more complicated - but this has the advantage that only the GC and storage manager are affected. None of these solutions is as simple and self-contained as I'd like :-( Cheers, Simon

5 5

RE: deeqSeq proposal
by Simon Marlow 11 Apr '06

11 Apr '06

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 I either put the bit in the constructor instance itself, or I need one info table for each variant, or I need to distinguish based on the address of the closure. Cheers, Simon

1 0