August 2004 - Haskell-Cafe

RE: [Haskell-cafe] Hiding functions
by Simon Peyton-Jones 14 Aug '04

14 Aug '04

It's an explicit Haskell 98 design choice http://haskell.org/onlinereport/modules.html "5.6.2 Shadowing Prelude Names The rules about the Prelude have been cast so that it is possible to use Prelude names for nonstandard purposes; however, every module that does so must have an import declaration that makes this nonstandard usage explicit." It's a decision one could debate, but it was an explicit choice. Simon | -----Original Message----- | From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Lyle | Kopnicky | Sent: 12 August 2004 20:23 | To: Haskell Cafe | Subject: [Haskell-cafe] Hiding functions | | Hi all, | | I'm working on a program that uses my own brand of exceptions, and I | created two functions called 'throw' and 'catch'. In order for this to | work, I hide the Prelude 'catch' in my module, called 'Cont.hs'. Thus: | | module Cont where | import Prelude hiding (catch) | ... | throw = ... | catch = ... | | This works hunky-dory until I create another file that imports Cont. I | get a conflict when I use 'catch', so I have to hide the Prelude one again: | | import Prelude hiding (catch) | import Cont | ... | ... throw ... | ... catch ... | | So I'm a bit annoyed by this 'propagation' of hiding clauses. Then I | created a new file, that redefined throw: | | module ResumableExceptions where | import Cont hiding (throw) | import qualified Cont (throw) | ... | throw = ... Cont.throw ... | | Finally, I created a file using ResumableExceptions: | | import Cont hiding (throw) | import ResumableExceptions | ... | ... throw ... | | If I wanted to also use 'catch' I'd have to hide that from the Prelude | as well. | | I can't use type classes to solve this problem, because the types of the | two 'throw' functions are different. | | Perhaps I should just make up new names for these things, eh? But there | might be code that uses 'throw' and doesn't really care which one is | used, and it would be nice to just modify the import line and be done | with it. | | Any opinions? | | Thanks, | Lyle | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe

3 3

RE: [Haskell-cafe] closed classes [was: Re: exceptions vs. Either]
by Simon Peyton-Jones 13 Aug '04

13 Aug '04

Closed classes are certainly interesting, but a better way to go in this case is to allow the programmer to declear new kinds, as well as new types. This is what Tim Sheard's language Omega lets you do, and I'm considering adding it to GHC. kind HNat = HZero | HSucc HNat class HNatC (a::HNat) instance HNatC HZero instance HNatC n => HNatC (HSucc n) Here the keyword 'kind' is like 'data', except that it introduces a new *kind* HNat with new *type* constructors HZero and HSucc, rather than a new *type* constructor with new *data* constructors. There is no way to construct a value of type HZero, or (HSucc HZero); these are simply phantom types. Today we are forced to say data HNat data HSucc a which loses the connection between the two. A merit of declaring a kind is that the kind is closed -- the only types of kind HNat are HZero, HSucc HZero, and so on. So the class doesn't need to be closed; no one can add new instances to HNatC because they don't have any more types of kind HNat. At the moment I'm only thinking of parameter-less kind declarations but one could easily imagine kind parameters, and soon we'll have kind polymorphism.... but one step at a time. Any thoughts? Simon | -----Original Message----- | From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of | Duncan Coutts | Sent: 06 August 2004 15:11 | To: MR K P SCHUPKE | Cc: Haskell Cafe | Subject: [Haskell-cafe] closed classes [was: Re: exceptions vs. Either] | | On Fri, 2004-08-06 at 14:05, MR K P SCHUPKE wrote: | > >You should include the definitions of the classes before saying | > | > HOrderedList l' just has to prove by induction that for any element | > in the list, the next element is greater, so the class is simply: | > | > class HOrderedList l | > instance HNil | > instance HCons a HNil | > instance (HOrderedList (HCons b l),HLe a b) => HCons a (HCons b l) | | Somewhat off-topic, | | It's when we write classes like these that closed classes would be | really useful. | | You really don't want people to add extra instances to this class, it'd | really mess up your proofs! | | I come across this occasionally, like when modelling external type | systems. For example the Win32 registry or GConf have a simple type | system, you can store a fixed number of different primitive types and in | the case of GConf, pairs and lists of these primitive types. This can be | modelled with a couple type classes and a bunch of instances. However | this type system is not extensible so it'd be nice if code outside the | defining module could not interfere with it. | | The class being closed might also allow fewer dictionaries and so better | run time performance. | | It would also have an effect on overlapping instances. In my GConf | example you can in particular store Strings and lists of any primitive | type. But now these two overlap because a String is a list. However | these don't really overlap because Char is not one of the primitive | types so we could never get instances of String in two different ways. | But because the class is open the compiler can't see that, someone could | always add an instance for Char in another module. If the class were | closed they couldn't and the compiler could look at all the instances in | deciding if any of them overlap. | | So here's my wishlist item: | | closed class GConfValue v where | ... | | Duncan | | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe

6 5

RE: [Haskell-cafe] Hiding functions
by Bayley, Alistair 13 Aug '04

13 Aug '04

What is wrong with creating your own catch and throw with different names? e.g. data MyException = MyException ... deriving (Typeable, Show) catchMyEx :: IO a -> (MyException -> IO a) -> IO a catchMyEx = catchDyn throwMyEx :: MyException -> a throwMyEx = throwDyn > But there might be code that uses 'throw' and doesn't really > care which one is used, and it would be nice to just modify > the import line and be done with it. Can you expand on this? (more example code?) If you want to throw your own exceptions, then you must use throwDyn/catchDyn, so you have to use something other than catch/throw anyway. Alistair. > -----Original Message----- > From: Lyle Kopnicky [mailto:lists@qseep.net] > Sent: 12 August 2004 20:23 > To: Haskell Cafe > Subject: [Haskell-cafe] Hiding functions > > Hi all, > > I'm working on a program that uses my own brand of > exceptions, and I created two functions called 'throw' and > 'catch'. In order for this to work, I hide the Prelude > 'catch' in my module, called 'Cont.hs'. Thus: > > module Cont where > import Prelude hiding (catch) > ... > throw = ... > catch = ... > > This works hunky-dory until I create another file that > imports Cont. I get a conflict when I use 'catch', so I have > to hide the Prelude one again: > > import Prelude hiding (catch) > import Cont > ... > ... throw ... > ... catch ... > > So I'm a bit annoyed by this 'propagation' of hiding clauses. > Then I created a new file, that redefined throw: > > module ResumableExceptions where > import Cont hiding (throw) > import qualified Cont (throw) > ... > throw = ... Cont.throw ... > > Finally, I created a file using ResumableExceptions: > > import Cont hiding (throw) > import ResumableExceptions > ... > ... throw ... > > If I wanted to also use 'catch' I'd have to hide that from > the Prelude as well. > > I can't use type classes to solve this problem, because the > types of the two 'throw' functions are different. > > Perhaps I should just make up new names for these things, eh? > But there might be code that uses 'throw' and doesn't really > care which one is used, and it would be nice to just modify > the import line and be done with it. > > Any opinions? > > Thanks, > Lyle ----------------------------------------- ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************

2 1

RE: [Haskell-cafe] Closed Classes
by MR K P SCHUPKE 13 Aug '04

13 Aug '04

>In my view without that simple defining >rule it is difficult to come up with a proposal that is simple, I think I have decided that it was not really closed world I was thinking of, but more along the lines of what Simon PJ posted... After all at some point the compiler _has_ to commit to an instance. If we leave everything as it is - unless the compiler cannot choose an instance due to unresolved overloading. In which case my suggestion is that the compiler trys unifying all instances with the environment, and if one and only one instance unifies then use that one... Keean.

1 0

RE: [Haskell-cafe] Closed Classes
by MR K P SCHUPKE 13 Aug '04

13 Aug '04

>add the extra rule that if there is only one possible instance the >compiler should use it. Yes, I think that is what I am saying. The closed class assumption alters the types of exported functions by applying improvements to them - that is not what I meant at all. I think what is confusing me is the 'possible' part. I was thinking about applying type improvement to effectively determine which instance to choose. (I think this is an error on my part - I get the impression type improvement cannot be used for this) ... would a possibel instance be something like: assuming you are resolving instances lazily at the last possible moment, you try to unify all instances and if one and only one unifies - use that instance. Keean.

2 1

Re: [Haskell-cafe] puzzle: prove this floorSqrt correct
by blaetterrascheln＠web.de 13 Aug '04

13 Aug '04

Christian Sievers <sievers(a)math2.nat.tu-bs.de> wrote on 12.08.04 19:00:00: > sqrtInt n = help n where help x = let y = ((x + (n `div` x)) `div` 2) in if y<x then help y else x > > following p. 38f of Henri Cohen, A Course in Computational Algebraic Number Theory That bailout test is better than mine, and the book is in my local library. Thank you very much. ________________________________________________________________ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt neu bei WEB.DE FreeMail: http://freemail.web.de/?mc=021193

1 0

Re: [Haskell-cafe] Closed Classes
by MR K P SCHUPKE 13 Aug '04

13 Aug '04

>that g::Int (or, rather, Int->Int) No, because instances are considered wherever they are defined (as long as they are in _this_ file or an imported one). The point of the example was to show that it is the instances visible in the transitive closure that are considered. Basically the type of g will be g :: A a => a -> a In the end functions have to be called, and it is the ultimate call site for the whole chain of functions where grounded types and concrete values are provided that instance resolution occurs. In the end we can call > g (3::Int) 4 In effect it is the extra parameter (A a) that contains the dictionary for 'A'. We can only choose a dictionary when we know the type of 'a', and we can choose between all instances visible at the call site, not where the function was originally defined. Keean.

1 0

Re: [Haskell-cafe] Closed Classes
by MR K P SCHUPKE 13 Aug '04

13 Aug '04

>Informally, what I see as the defining rule for "closed world" is: But that would break existing programs. You would need a language extension so the feature could be selectively enabled. There are plenty of proposals for how to do this (from closed class keywords to 'kind' statements)... I think however that you can get the benefits of better improvement rules without going all the way to a closed world. My question in the last post was: what if we assume an open world whilst type-checking and generating function type signatures, but assume closed world when resolving instances? Keean.

1 0

Closed Classes
by MR K P SCHUPKE 12 Aug '04

12 Aug '04

Okay (thanks to Simon PJ) - the problem appears to be that applying the improvement rules could result in a function being exported with an incorrect type signature (if a later module defines additional instances): module X (f,g) where class A a where f :: a -> a instance A Int where f = id g x = f x After appling improvement 'g's type would be "g::Int -> Int", however if we now do: module Y where import X instance A Float where f x = x + 1.0 h x = g x Then after the type sig exported for 'g' is wrong ... So my question is now: What if we don't improve the types of 'f' at all and leave it at its most general: "g :: A a => a -> a", and instead wait until we are tring to resolve overloading to apply improvement. IE at some point we must decide which dictionary to pass in, to the top level function (with a constraint "A a =>") what happens if we defer improvement till this point? Surely it must be safe to assume a closed class at the top level? Keean.

6 5

Hiding functions
by Lyle Kopnicky 12 Aug '04

12 Aug '04

Hi all, I'm working on a program that uses my own brand of exceptions, and I created two functions called 'throw' and 'catch'. In order for this to work, I hide the Prelude 'catch' in my module, called 'Cont.hs'. Thus: module Cont where import Prelude hiding (catch) ... throw = ... catch = ... This works hunky-dory until I create another file that imports Cont. I get a conflict when I use 'catch', so I have to hide the Prelude one again: import Prelude hiding (catch) import Cont ... ... throw ... ... catch ... So I'm a bit annoyed by this 'propagation' of hiding clauses. Then I created a new file, that redefined throw: module ResumableExceptions where import Cont hiding (throw) import qualified Cont (throw) ... throw = ... Cont.throw ... Finally, I created a file using ResumableExceptions: import Cont hiding (throw) import ResumableExceptions ... ... throw ... If I wanted to also use 'catch' I'd have to hide that from the Prelude as well. I can't use type classes to solve this problem, because the types of the two 'throw' functions are different. Perhaps I should just make up new names for these things, eh? But there might be code that uses 'throw' and doesn't really care which one is used, and it would be nice to just modify the import line and be done with it. Any opinions? Thanks, Lyle

1 0