- Haskell-Cafe - Haskell.org

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

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

13 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

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

12 Aug '04

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. Simon | -----Original Message----- | From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of MR | K P SCHUPKE | Sent: 12 August 2004 14:03 | To: haskell-cafe(a)haskell.org; qrczak(a)knm.org.pl | Subject: Re: [Haskell-cafe] closed classes [was: Re: exceptions vs. Either] | | Okay anybody whish to argue against these points: | | 1) closed or open is the same if no instances overlap | | 2) overlapping instances (open or closed) can break | code in modules which import the defining module | if a new instance is declared in any imported | module. | | 3) code changes in non-imported modules cannot have | any affect on _this_ module. (And here I count | any module in the import tree as imported - at | least in terms of recompilation dependancies) | | The conclusion appears to be it is overlapping instances | that cause code to be 'breakable' by simply defining a new | instance and not closing the class. Closing the class | would appear to have no adverse affects on existing | programs (as it allows better improvement rules) all existing | programs that compile without the better improvement rules | should still compile - just a few more programs will be | valid with the closed assumption? | | Keean. | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe

2 1

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

12 Aug '04

Okay anybody whish to argue against these points: 1) closed or open is the same if no instances overlap 2) overlapping instances (open or closed) can break code in modules which import the defining module if a new instance is declared in any imported module. 3) code changes in non-imported modules cannot have any affect on _this_ module. (And here I count any module in the import tree as imported - at least in terms of recompilation dependancies) The conclusion appears to be it is overlapping instances that cause code to be 'breakable' by simply defining a new instance and not closing the class. Closing the class would appear to have no adverse affects on existing programs (as it allows better improvement rules) all existing programs that compile without the better improvement rules should still compile - just a few more programs will be valid with the closed assumption? Keean.

1 0

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

12 Aug '04

Just wondering, but what exacly is the problem with this open/closed stuff? As far as I understand it new instances can be added to classes in Haskell (because they are open)... But its not like instances can be added at link time, and all the instances that you wish to be considered _must_ be imported into the current module! That means if we (for example) used two pass compilation we could gather all the instances together first and know that we have all instances for a given class before considering any resolution of overlapping instances. Why is this not done? (personally I don't mind if compilation takes longer if it makes coding easier...) Keean.

3 2

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

12 Aug '04

>If the compiler treated instances as closed in this way, then adding a >new instance to the program could break existing parts of the program. But there are many ways to do this... and besides this doesn't really make sense... consider the following: module A defines class X module B imports class X defines some instances module C imports A & B Now, you can add any instance you like to module C and it is never seen by modules A and B... In other words even if you assume closed classes you cannot break an existing module without editing that module or one imported by it (in which case you can break _anything_ by deleting a function) If you don't allow overlapping instances none of this makes any difference anyway - closed or open ... (instance selection cannot change if no instances are allowed to overlap) Finally if you allow overlapping instances you can break existing code (without the closed assumption) just by putting in a more specific instance in a module included in some module using the more general instance. Thoughts? What is the problem with assuming all classes are closed within the available context (imported modules) Keean.

1 0