- Haskell-prime - Haskell.org

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

Re: FDs and confluence
by tom.schrijvers＠cs.kuleuven.be 10 Apr '06

10 Apr '06

On Mon, 10 Apr 2006, Claus Reinke wrote: >> (see the FunctionalDependencies page for background omitted here) > > which seems to ignore much of the discussion of confluence we had here some > weeks ago? I thought this list was for communication with the committee, and > since the ticket exists, I had been hoping that the > type class subcommittee would ensure that the wiki would be updated. > but it seems I have been talking to myself.. Yes, I wondered what had happened to your previous argument for the memo constraint. >> One of the problems with the relaxed coverage condition implemented >> by GHC and Hugs is a loss of confluence. Here is a slightly cut-down >> version of Ex. 18 from the FD-CHR paper: >> >> class B a b | a -> b >> class C a b c | a -> b >> >> instance B a b => C [a] b Bool >> >> Starting from a constraint set C [a] b Bool, C [a] c d, we have two >> possible reductions: >> >> 1) C [a] b Bool, C [a] c d >> => c = b, C [a] b Bool, C [a] b d (use FD on C) >> => c = b, B a b, C [a] b d (reduce instance) >> >> 2) C [a] b Bool, C [a] c d >> => C a b, C [a] c d (reduce instance) > > CHR-alt: > > B a b <=> infer_B a b, memo_B a b. > memo_B a b1, memo_B a b2 ==>b1=b2. > > C a b c <=> infer_C a b c, memo_C a b c. > memo_C a b1 c1, memo_C a b2 c2 ==> b1=b2. > infer_C [a] b Bool <=> B a b. > memo_C [a] b' c' ==> b'=b. What's this last rule for? It mentions a b that does not appear in the head of the rule. If you mean the rule memo_C [a] b c, memo_C [a] b' c' ==> b = b'. then it is already subsumed by the more general memo_C a b1 c1, memo_C a b2 c2 ==> b1=b2. Tom -- Tom Schrijvers Department of Computer Science K.U. Leuven Celestijnenlaan 200A B-3001 Heverlee Belgium tel: +32 16 327544 e-mail: tom.schrijvers(a)cs.kuleuven.be

1 0

RE: FDs and confluence
by Simon Peyton-Jones 10 Apr '06

10 Apr '06

Interesting! It'd be great if you've found a simpler more uniform rule. (Which you seem to be getting rather good at.) Let's see if you can convince Martin, first, and then articulate the proposed rules. I'll look fwd to that. Simon | -----Original Message----- | From: haskell-prime-bounces(a)haskell.org [mailto:haskell-prime-bounces@haskell.org] On Behalf Of | Ross Paterson | Sent: 10 April 2006 09:53 | To: haskell-prime(a)haskell.org | Subject: FDs and confluence | | (see the FunctionalDependencies page for background omitted here) | | One of the problems with the relaxed coverage condition implemented | by GHC and Hugs is a loss of confluence. Here is a slightly cut-down | version of Ex. 18 from the FD-CHR paper: | | class B a b | a -> b | class C a b c | a -> b | | instance B a b => C [a] b Bool | | Starting from a constraint set C [a] b Bool, C [a] c d, we have two | possible reductions: | | 1) C [a] b Bool, C [a] c d | => c = b, C [a] b Bool, C [a] b d (use FD on C) | => c = b, B a b, C [a] b d (reduce instance) | | 2) C [a] b Bool, C [a] c d | => C a b, C [a] c d (reduce instance) | | The proposed solution was to tighten the restrictions on instances to | forbid those like the above one for C. However there may be another | way out. | | The consistency condition implies that there cannot be another | instance C [t1] t2 t3: a substitution unifying a and t1 need not | unify b and t2. Thus we could either | | 1) consider the two constraint sets equivalent, since they describe | the same set of ground instances, or | | 2) enhance the instance improvement rule: in the above example, we | must have d = Bool in both cases, so both reduce to | | c = b, d = Bool, B a b | | More precisely, given a dependency X -> Y and an instance C t, if | tY is not covered by tX, then for any constraint C s with sX = S tX | for some substitution S, we can unify s with S t. | | We would need a restriction on instances to guarantee termination: | each argument of the instance must either be covered by tX or be | a single variable. That is less restrictive (and simpler) than | the previous proposal, however. | | Underlying this is an imbalance between the two restrictions on instances. | In the original version, neither took any account of the context of the | instance declaration. The implementations change this for the coverage | condition but not the consistency condition. Indeed the original form of | the consistency condition is necessary for the instance improvement rule. | | _______________________________________________ | Haskell-prime mailing list | Haskell-prime(a)haskell.org | http://haskell.org/mailman/listinfo/haskell-prime

1 0