Registry for Haskell extensions?
The Preface of the Haskell Report says: The comittee hopes that Haskell can serve as a basis for future research in language design. We hope that extensions or variants of the language may appear, incorporating experimental features. Various extensions have been proposed or even implemented. It would be nice to have a second companion document to the Haskell Report, dedicated to extensions. Placed at the official WWW-sites of the Report, but updated more frequently, it would provide a central registry for extension proposals and a central source of information for both the comittee and 'ordinary' Haskell users. The extension register should be divided into categories roughly describing the status of each proposal and could even include comments from the comittee, like: 'We rejected this proposal for the following reasons' or 'We judge this to be a very interesting extension, but haven't decided yet about the best way to include it in the standard'. There should be a list of open problems (e.g. conflicts with other language elements), expected advantages and known disadvantages for each proposal. Categories could be: PROPOSED description available (formal or informal) REJECTED rejected by the comittee or given up by the author PROTOTYPE implemented in at least one of the available systems SCHEDULED accepted (will be included in one of the next versions) What do You think about it? cr - Some examples: (the list is far from complete and only intended to show the need for a register, so please, don't flame me for mistakes and omissions ;-) STATE: Haskell 1.2 PROPOSED ? REJECTED views PROTOTYPE existential types (chalmers) fudgets (chalmers) mutable arrays(glasgow) ST monad (glasgow) ccall (glasgow) unboxed datatypes (glasgow) constructor classes (nottingham) monad comprehensions (nottingham) records (yale) foreign function interface(yale) X window interface(yale) concurrent execution, ... SCHEDULED monadic I/O (1.3) ... - Hmm.., there should be a section on proposals concerning the language environment as well: PROPOSED debugger (??) REJECTED PROTOTYPE interactive environment (chalmers,nottingham,yale) parser generator (glasgow) profiling, ... SCHEDULED -- Claus ReinkeUniversity of Kiel email: [EMAIL PROTECTED] Department of Computer Science http://www.informatik.uni-kiel.de/~cr/ Preusserstr. 1-9, 24105 Kiel
adding instances to (,)
Dear sir, I had written several pages of Haskell scripts, tried HUGS Haskell on them, debugged, and now I'm trying to complile the stuff with Glasgow Haskell. ghc-0.25 dislikes the following declarations: - module M where instance (Num a, Num b) => Num (a,b) where (x,y)+(x1,y1) = (x+x1, y+y1) ; - This module only tries to export the instance for (,): (Num a, Num b) => Num (a,b) HUGS Haskell (it ignores modularity) makes this (+) for pairs all right, so one can evalute (1,1)+(1,2) -> (2,3). But ghc-0.25 says that this instance for Num should be declared in the same module where the type constructor is defined. I guess, it is the (,) constructor from the Prelude module. Should one add an instance of Num for (,) to Prelude ? And how to do this ? Haskell-1.3 report contains an example: -- module A where import Prelude hiding (map) map f x = x f -- This module redefines `map' totally. Should I redefine totally (,) with its instances in this way ? Besides, import Prelude hiding ( (,) ) is qualified as illegal syntax. Does this all mean that to overload (+) for pairs one should define some new constructor, isomorphic to (,) but with the additional instances ? This does not look nice ... Thanks in advance. Sergei D.Meshveliani
Re: adding instances to (,)
Your error messages from ghc are correct: you have violated the infamous C-T rule (section 4.3.2, page 32) which restricts instance declarations to the module containing either the class or the datatype. Since (,) and Num are both in the prelude, you can't compile this in official Haskell 1.2. You could define your own datatype isomorphic to (,) but you won't get the nice notation. This should be legal in Haskell 1.3 (once it's done!) - the C-T rule can be quite annoying so it's being relaxed. Just remember: HUGS is not Haskell :-). John Peterson Yale Haskell Project
