- Haskell-Cafe - Haskell.org

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 13 Aug '04

13 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

Combination-lock problem
by Florian Boehl 12 Aug '04

12 Aug '04

Hi, I'ld like to generate a list (of lists) that contains all combinations of natural numbers stored in another list. It should work like a combination-lock. E.g.: [2,2] -> [[0,0],[0,1],[0,2],[1,0],[1,1],[1,2],[2,0],[2,1],[2,2]] If I know the length 'l' of the 'locklist', I can solve the problem via generators. E.g.: l = 2: [[a,b] | a <- [0..locklist!!0], b <- [0..locklist!!1]] But if the length is unknown (because it's dynamic) this solutions (of course) fails. Is it possible to solve this problem in haskell in an elegant way? Thanks Flo

10 13

RE: [Haskell-cafe] closed classes [was: Re: exceptions vs. Either]
by MR K P SCHUPKE 12 Aug '04

12 Aug '04

>but if f is exported, that's probably not what you want. Why... Read my post carefully - I am suggesting that you close the class on IMPORT so module X import a import b import c So we close the class here - after reading all possible instances from imported files a,b, and c Keean.

1 0

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

12 Aug '04

but if f is exported, that's probably not what you want. And if you give a type sig to f, f:: forall a. C a => a -> Maybe a the type sig will say it's polymorphic, while the improvement rule will say that a must be Int. Simon | -----Original Message----- | From: André Pang [mailto:ozone@algorithm.com.au] | Sent: 12 August 2004 14:52 | To: Simon Peyton-Jones | Cc: MR K P SCHUPKE; haskell-cafe(a)haskell.org; qrczak(a)knm.org.pl | Subject: Re: [Haskell-cafe] closed classes [was: Re: exceptions vs. Either] | | On 12/08/2004, at 11:05 PM, Simon Peyton-Jones wrote: | | > module M where | > | > class C a where | > op :: a -> a | > | > instance C Int where | > op x = x+1 | > | > f x = Just (op x) | > | > Under your proposal, I'd infer f :: Int -> Maybe Int, on the grounds | > that C is closed and there is only one instance. | | If I'm reading Keean's posts right, that's exactly his point: if you | only have one instance of class C, then it's valid to improve f's type | to :: Int -> Maybe Int, right? | | If, on the other hand, you had another instance (e.g. instance C Bool), | then the signature of f would have to remain polymorphic. | | | -- | % Andre Pang : trust.in.love.to.save

1 0