Re: [Haskell-cafe] closed classes [was: Re: exceptions vs. Either]

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.

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! [..]
Sure it's the case that instances are closed in any given build of a program. But they're not closed over the (maintenance / extension) lifetime of that program. 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. This would be a development nightmare. This is just an example of a general principle in language / compiler design - it's not sufficient that the behaviour be specified, it must behave predictably from the programmer's point of view; in particular, local changes shouldn't have global effect. This also comes up in optimisations - you could write a compiler that recognised occurrences of bubble sort and replaced them with quicksort, for example, but it wouldn't be a good idea, because a small change to the code might cause it to no longer recognise it as bubblesort - with a consequent asymptotic slowdown that bears no relation to the change just made. --KW 8-)

W liście z czw, 12-08-2004, godz. 10:30 +0100, Keith Wansbrough napisał:
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. This would be a development nightmare.
Well, this is already possible due to conflicting instances. It implies a guideline that a library should only add instances for classes it defines itself, or for types it defines itself. With multiparameter classes it suffices that at least one of the types from the instance head is new. All other cases should be carefully examined to see if the instance is appropriate, in particular if it's indeed the only "right" instance for this class/types combination. If that's right, the instances should be clearly announced in the documentation, and preferably defined in a separate module to be imported optionally. This increases the chance that anybody wishing to make a similar instance will know about that module, and if he still wants to make a separate instance, then both libraries can be linked together. This is only a guideline, not a hard requirement. -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/
participants (3)
-
Keith Wansbrough
-
Marcin 'Qrczak' Kowalczyk
-
MR K P SCHUPKE