- Haskell-prime - Haskell.org

RE: MPTCs and functional dependencies
by Simon Peyton-Jones 10 Apr '06

10 Apr '06

My current take, FWIW. * MPTCs are very useful. They came along very rapidly (well before H98). I think we must put them in H' * But MPTCs are hamstrung without FDs or ATs * FDs and ATs are of the same order of technical difficulty, as Martin says * ATs are (I believe) a bit weaker from the expressiveness point of view (zip example), but are (I believe) nicer to program with. * BUT we have way more experience with actually programming with FDs. ATs fail the "well-established" test by a mile. * Largely due to Martin's work, we now have a much better handle on just what restrictions on FDs make type inference tractable. So I believe there is a solid MPTC+FD story that we could embody in H'. * Medium term, I think ATs may *at the programming-language level* displace FDs, because they are nicer to program with. But that's just my opinion, and we don't have enough experience to know one way or the other. Tentative conclusion: H' should have MPTC + FDs, but not ATs. Simon | -----Original Message----- | From: haskell-prime-bounces(a)haskell.org [mailto:haskell-prime-bounces@haskell.org] On Behalf Of | Ross Paterson | Sent: 02 February 2006 11:25 | To: haskell-prime(a)haskell.org | Subject: MPTCs and functional dependencies | | On Thu, Feb 02, 2006 at 11:38:07AM +0100, John Hughes wrote: | > The problem with Haskell 98 is that it *lacks* features which | > have become absolutely essential to Haskell programmers today. Those | > features are what really *need* discussion and energy spent on them. | > | > [...] | > | > Multi-parameter classes with functional dependencies | > - used everywhere... for example in monad transformers... so | > *must* be included this time | > - omitted from Haskell 98 because "the right design" wasn't clear | > - it's still unclear! Functional dependencies *in some form* | > are essential, but associated types and datatypes look nicer | > in many ways! | > - is it too late, in practice, to replace fundeps by something | > else? How will we know? If we are to standardize on associated | > types instead, we need a major effort to *make sure* all | > important applications of fundeps can be represented. How will | > we organize that? | | I agree that MPTCs are much less useful (though not completely useless) | without something like FDs or associated types. But the specification | of FDs is far from clear: the system described in Mark's paper is quite | a bit weaker than what is implemented by GHC and (more shakily) by Hugs. | It seems that associated types aren't ready yet, but I don't think FDs | are either, accustomed as people are to them. | | I have another worry about MPTCs. They require require relaxations on | the form of instances (FlexibleInstances on the wiki), which in turn | require relaxations on contexts and thus deferred context reduction (see | FlexibleContexts). The result is that missing instances get reported | later than they do now. MPTCs are very useful and probably necessary, | but there is a cost. | | _______________________________________________ | Haskell-prime mailing list | Haskell-prime(a)haskell.org | http://haskell.org/mailman/listinfo/haskell-prime

6 6

RE: New syntax
by Simon Peyton-Jones 10 Apr '06

10 Apr '06

| > | It's very bad that with TH enabled you cannot write sections of the | > form ($ x) | > | anymore which are sometimes very handy. | > | > I'd prefer it if TH only sprang into action when you wrote | > $x | > or | > $(f x) | > | > That is, no space after the $. If you put spaces, you should get the | > H98 $. | | Isn't that the current behaviour? So it is! It's even documented as such. SImon

1 0

RE: Exceptions
by Simon Marlow 10 Apr '06

10 Apr '06

[oops, sent by accident...] On 08 April 2006 10:18, John Meacham wrote: > On Sat, Apr 08, 2006 at 12:11:51AM -0400, David Menendez wrote: >>> newtype ArithException a = ArithException a >>> >>> data DivideByZero >>> >>> throw (ArithException DivideByZero) >>> >>> your code: >>> >>> data MultiplyByZero >>> throw (ArithException MultiplyByZero) >> >> How would you use this to write a handler that captures any >> ArithException? > > You would use the Typeable1 class in Data.Typeable. not perfect, but > exception hierarchies shouldn't be too deep so it is not so bad. I mentioned this solution to John G. off-list; the problem is that you end up needing to parameterise all the classes of exceptions (we'd have IOException a, ArrayException a, AsyncException a, etc.), and that seems ugly. Given that we've already made the Exception type sideways extensible with a simple application of type classes and dynamic types, we can take the technique a bit further to create an extensible hierarchy of exceptions, which is what John's arguing for. To create a new subclass of exceptions: --------- class (Typeable x, Show x) => ArithException x newtype AnyArithException = AnyArithException Dynamic deriving Typeable instance Exception AnyArithException instance Show AnyArithException where show (AnyArithException x) = show x throwArith :: ArithException x => x -> a throwArith x = throw (AnyArithException (toDyn x)) matchArith :: ArithException x => AnyArithException -> Maybe x matchArith (AnyArithException x) = fromDynamic x --------- and populating the subclass is just as easy as populating the root: --------- data DivideByZero = DivideByZero deriving (Typeable, Show) data Overflow = Overflow deriving (Typeable, Show) instance ArithException DivideByZero instance ArithException Overflow --------- catching is easy too. To catch *any* ArithException: --------- x `catch` \(e :: AnyArithException) -> print e --------- To catch a particular ArithException: --------- x `catch` \e -> case () of _ | Just DivideByZero <- matchArith e -> print e | otherwise -> throw e --------- To catch a mixture of ArithException and other exceptions: --------- x `catchAny` \e -> case () of _ | Just (IOException x) <- matchException e -> print x | Just arith <- matchException e, Just DivideByZero <- matchArith arith -> print arith | otherwise -> throwAny e --------- I like this, it seems like a natural extension of what we've already proposed. The fact that you have to use 'throwArith' rather than plain 'throw' is slightly annoying, though. Cheers, Simon

1 0

RE: Exceptions
by Simon Marlow 10 Apr '06

10 Apr '06

On 08 April 2006 10:18, John Meacham wrote: > On Sat, Apr 08, 2006 at 12:11:51AM -0400, David Menendez wrote: >>> newtype ArithException a = ArithException a >>> >>> data DivideByZero >>> >>> throw (ArithException DivideByZero) >>> >>> your code: >>> >>> data MultiplyByZero >>> throw (ArithException MultiplyByZero) >> >> How would you use this to write a handler that captures any >> ArithException? > > You would use the Typeable1 class in Data.Typeable. not perfect, but > exception hierarchies shouldn't be too deep so it is not so bad. I mentioned this solution to John G. off-list; the problem is that you end up needing to parameterise all the classes of exceptions (we'd have IOException a, ArrayException a, AsyncException a, etc.). Given that we've already made the Exception type sideways extensible with a simple application of type classes and dynamic types, we can take the technique a bit further to create an extensible hierarchy of exceptions, which is what John wants. To create a new subclass of exceptions:

1 0

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

09 Apr '06

On 07 April 2006 13:58, John Meacham wrote: > all threads keep running while the exit handers are running, all > blockExit would do is grab and release an MVar. exit itself takes > that MVar on starting to get rid of races to exit as well as protect > itsesf from 'blockExit' (but won't ever put the MVar back). 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. Of course you could implement some global flag to say that an exit is in progress, but that implies explicit checking of the flag all over the place, which is what asynchronous exceptions are designed to avoid. When *do* we exit, in fact? When all the exit handlers have finished? >> Exceptions are the right way to handle releasing resources, and they >> are the right way to register cleanup actions. Therefore I believe >> exceptions are the right way to handle cleaning up on exit, too. > > Well, We really need 'onExit' for other reasons as well, I think it > should make it into the standard independently. Sure, I'm happy with onExit. > I think you have that backwards, releasing resources is the right > thing > to do when you get an exception, but there are lots of other reasons > you > want to release resources that have nothing to do with exceptions. you > don't use 'throwTo' to close all your files :) No, but you do use an exception handler, or something built using exception handlers like 'finally'. I don't want to have to use *both* exception handlers and exit handlers. >> Since async exceptions are no problem to implement in a coop system, >> shouldn't we use them for exit too? > > but then only one thread gets to clean up after itself, I think all threads should get the exit exception (I know GHC doesn't currently do this). > and you have > the issue that you can't interrupt a foreign function by throwing to > it. The situation is the same as in your proposal - the foreign call continues running. However, as soon as it returns, the Haskell thread will receive an exception. I propose this: When System.Exit.exitWith is called, all currently running threads are sent an exit exception as soon as possible. Exit handlers registered with onExit are started immediately. The system exits when (a) the main thread has stopped, and (b) all exit handlers have completed. Subsequent calls to exitWith simply throw an exit exception in the current thread. Cheers, Simon

3 2

limitations of newtype-deriving
by John Meacham 09 Apr '06

09 Apr '06

The newtype deriving extension is one of the most powerful tools for writing robust, typesafe code. However it suffers from a couple limitations. * 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 to be separate from data definitions. basically, we would allow deriving anywhere. > deriving (Show Foo) means the same thing as > data Foo = ... > deriving (Show) will derive an instance of Show for Foo. now we are no longer bound by either of the above constraints.. imagine we have a class > class MapLike k v | v -> k where > insert :: .. > delete :: ... > ... > instance MapLike Int (IM.IntMap a) where > insert = IM.insert > .... now, we want a newtype that describes Id's. > newtype Id = Id Int > deriving(Eq,Ord) now, we want to create a type of substitutions from Ids -> Terms > 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 deriving, we can do: > deriving(MapLike Id Subst) and be done with it. this would be worlds of useful. John -- John Meacham - ⑆repetae.net⑆john⑈

1 1

Re: Exceptions
by John Meacham 08 Apr '06

08 Apr '06

On Sat, Apr 08, 2006 at 12:11:51AM -0400, David Menendez wrote: > > newtype ArithException a = ArithException a > > > > data DivideByZero > > > > throw (ArithException DivideByZero) > > > > your code: > > > > data MultiplyByZero > > throw (ArithException MultiplyByZero) > > How would you use this to write a handler that captures any > ArithException? You would use the Typeable1 class in Data.Typeable. not perfect, but exception hierarchies shouldn't be too deep so it is not so bad. John -- John Meacham - ⑆repetae.net⑆john⑈

1 0

Re: Exceptions
by Dave Menendez 08 Apr '06

08 Apr '06

John Meacham writes: > On Fri, Apr 07, 2006 at 10:00:21AM -0500, John Goerzen wrote: > > But here's my concern. Let's say that I wanted to, for some > > reason, create a MultiplyByZero exception. It should be broadly > > considered an ArithException, and any code that catches an > > ArithException should be able to catch my MultiplyByZero exception. > > > > But the ArithException type is limited to storing errors that are > > defined by Control.Exception.ArithException. My MultiplyByZero is > > not defined there, so I am out of luck. The best I could do is > > define a new MultiplyByZero, and catch it in my own code. But any > > code that others have written to catch ArithExceptions would be > > blind to MultiplyByZero. > > newtype ArithException a = ArithException a > > data DivideByZero > > throw (ArithException DivideByZero) > > your code: > > data MultiplyByZero > throw (ArithException MultiplyByZero) How would you use this to write a handler that captures any ArithException? -- David Menendez <zednenem(a)psualum.com> | "In this house, we obey the laws <http://www.eyrie.org/~zednenem> | of thermodynamics!"

1 0

RE: Exceptions
by Simon Marlow 07 Apr '06

07 Apr '06

John, have you seen this? http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki/Extensible Exceptions Cheers, Simon On 07 April 2006 15:34, John Goerzen wrote: > Hello, > > One thing that bugs me about Haskell is that exceptions are not > extensible. > > I don't know how to craft a good solution, but perhaps if I explain > the problem well, someone would come up with one. > > In a language such as Python or Java, and exception is an object. > > Let's consider Python for a quick example. Python has an IOError > exception. So if I want to write a handler that deals with IOErrors, > that's easy enough. > > Now maybe I want to do something like report socket errors specially. > I could define a SocketError class that subclasses IOError. I could > take this further, and define a URLError that subclasses SocketError. > > Now the beauty of it is that I can: > > * Have a handler that catches URLErrors only and does nothing special > with SocketErrors or IOErrors. > > * Have a handler -- perhaps not even mine -- that catches and works > with IOErrors. Since SocketError and URLError are descendants of > IOError, that handler will *automatically* work if I raise a > SocketError or a URLError. > > I can see no such mechanism in Haskell. Haskell's I/O exceptions > have a certain defined set of errors that they can report, and I > can't subclass them and make them more specific for my purposes if I > want. Ditto for all the others. > > The Dynamic exception support is necessary and good to have, but it > also under-documented and can be complex. And of course, they still > suffer from the same lack of extensibility > > Are there any suggestions on how we might improve this situation in > Haskell? > > -- John

3 2

Re: deeqSeq proposal
by Rene de Visser 07 Apr '06

07 Apr '06

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.

2 1