- Haskell-prime - Haskell.org

Tackling the atrocious squad
by Achim Schneider 07 May '08

07 May '08

Well, it's an unformalised and not much thought about out-of-the-tub idea, but here it goes: Let there be a monad/typeclass representing the denotional semantics of Haskell Do some instances of it, called e.g. GHC or Hugs. so, instead of main :: IO () we have main :: (Haskell h) => h (IO ()) or, if you need some feature of the Haskell runtime system XYZ main :: XYZ (IO ()) or even main :: (FFI h) => h (IO ()) and main :: (SomeLib h) => h (IO ()) , and then go on and define every single language construct as part of this type hierarchy, and define some syntactic sugar to make stuff look exactly like haskell '98 if you're just hacking away. I especially like the metacircularity of this approach, and the fact that every Model (read: implementation) of Haskell would have to admit that it is only a Model (read: instance) of Haskell. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited.

2 2

DRAFT: Haskell' status update
by Simon Marlow 06 May '08

06 May '08

Those on the Haskell' mailing list may have seen recent signs of activity on the Haskell' front. I thought I should clarify the current status, and update the community on our plans for Haskell'. The main sticking point in the design of Haskell' has been the type system: namely whether Haskell' should have Functional Dependencies or Type Families. This issue is still undecided, although the experts are hard at work on developing a stronger understanding of Type Families in particular. Nevertheless, the committee feels that we cannot have a Haskell' without some way to resolve ambiguities when using multi-parameter type classes, be it Functional Dependencies (FDs) or Type Families (TFs). For one thing, a great deal of existing code uses FDs or depends on code that does, so unless we adopt one of these extensions all this code will still exist outside of Haskell', and that is far from ideal. So we decided to proceed in two stages: - "Haskell' alpha" will be a complete language specification, including all the modifications and additions we want to make to the language *except* for FDs or TFs. - Haskell' will follow afterward, adding either FDs or TFs. The motivation for this two-stage approach is that we can make progress on all the other parts of the language without being blocked on the type system, we can start work on implementing Haskell' alpha in our compilers, users can start using the new standard, and we can gain some experience with using it in practice. On the process side of things, we're now tracking the status of all language design proposals on this page: http://hackage.haskell.org/trac/haskell-prime/wiki/Status and as usual all the Haskell' resources are on the wiki: http://hackage.haskell.org/trac/haskell-prime/wiki The committee have been discussing various proposals amongst ourselves over the past few weeks, with the goal of making as many concrete decisions as possible. However, the general policy is still for technical discussions to take place in public, as far as possible. Changes to the status page are sent to the public mailing list, and we welcome comments on any of the issues, regardless of status. Thanks for your patience :-) And rest assured that progress is being made! Cheers, Simon (and the Haskell' committee)

10 39

RE: instance export decls
by Simon Peyton-Jones 02 May '08

02 May '08

Indeed! I think it'd be good to allow type signatures, including instance signatures, in export lists module Foo( data T (f :: * -> *), instance Functor f => Eq (T f), g :: T f -> T f ) The first step is to evolve a well-worked-out design. I think that'd be a very valuable thing for someone to do. Indeed, I'd really like to see it in Haskell', but it doesn't meet the "tried and tested" criterion. I'm a bit reluctant to invest effort in half-way-house solutions, though. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On | Behalf Of Serge D. Mechveliani | Sent: 22 April 2008 13:33 | To: glasgow-haskell-users(a)haskell.org | Subject: instance export decls | | Dear GHC developers, people, | | Do you agree that there exists such a problem for a programmer as | recalling exported instances? | Have Haskell and/or GHC some constructs and tools to help the programmer | to recall the exported instances for a module? | Could GHC support the instance export messages for each module? | | In Haskell-98, the exported instances cannot be named explicitly in the | export list. | Right? | But for easier understanding of a program, it is desirable to allow to | name (in a short form) instances in the export list. | For this reason, I add comments, and write the export like this: | | module Poly | (WithHead(..), WithTail(..), -- classes | Mon(..), Polynomial(..), | lc, polMons | -- , instances | -- for Mon: WithHead, List; | -- for Polynomial: WithHead, Cast Polynomial Mon | ) | The comment of kind "-- , instances ..." | helps to recall which instances are exported, without inspecting all | the (lengthy) module source. | | But when the programmer changes the source, one often forgets to | add/remove the needed comments about instances. | I often forget them (maybe, lazy to recall) when I move pieces of code | between modules. | | So, I suggest the following feature for GHC. | | 1. To allow the export declarations of kind instance {<type>} | (maybe to suggest this for Haskell ?) | 2. If the module under compilation has the word `instance' in its | export list, | then ghc finds the difference set diff for the exported instance | kinds eKinds and the instance kinds nKinds named in the export | list. If not $ null diff, it issues the message: | "Warning: the exported instance kinds and the instance kinds named | in the export differ in the following items: ...". | | Seeing such a message, the user corrects the export list in the source | according to diff. | | For the export list and for their messages, it is probably better to | use a short denotation: the instance kind rather than full instance | declaration. In the instance kind, the part of "(...) =>" is skipped. | | What people think of this suggestion? | | Thank you in advance for your notes and help, | | ----------------- | Serge Mechveliani | mechvel(a)botik.ru

2 1

The monomorphism restriction and monomorphic pattern bindings
by Simon Marlow 01 May '08

01 May '08

Folks, The current proposal on the table for what to do about the monomorphism restriction (henceforth MR) is * remove the MR entirely * adopt Monomorphic Pattern Bindings (MPB) Right now, the committee is almost uniformly in favour of dropping the MR, and most of us are coming round to the idea of MPB. Since this area has historically been difficult to achieve a concensus on, I'm excited that we appear to be close to making a decision, and a good one at that! The arguments for removing the MR are pretty well summarised on the wiki: http://hackage.haskell.org/trac/haskell-prime/wiki/MonomorphismRestriction You can read about MPB here: http://hackage.haskell.org/trac/haskell-prime/wiki/MonomorphicPatternBindin… GHC has implemented MPB by default (i.e. we deviate slightly from Haskell 98) since 6.8.1. The nice thing about the combination of removing MR and adopting MPB is that we retain a way to explicitly declare monomorphic bindings. These are monomorphic bindings: ~x = e x@_ = e or if you don't mind a strict binding: !x = e. The wiki points out that (x) = e would also be monomorphic, but arguably this is in poor taste since we expect (x) to mean the same as x everywhere. Cheers, Simon

7 14

Meta-point: backward compatibility
by Chris Smith 30 Apr '08

30 Apr '08

There appears to be some question as to the backward compatibility goals of Haskell'. Perhaps it's worth bringing out into the open. >From conversations I've had and things I've read, I've always gathered that the main goal of Haskell' is to address the slightly embarrassing fact that practically no one actually writes code in Haskell, if by Haskell we mean the most recent completed language specification. This obviously argues strongly for a high degree of backward compatibility. On the other hand, I am assuming everyone agrees that we don't want to replicate Java, which (in my view, anyway) is rapidly becoming obsolete because of an eagerness to make the language complex, inconsistent, and generally outright flawed in order to avoid even the most unlikely of broken code. -- Chris

15 20

patch applied (haskell-prime-status): BangPatterns: probably accept ==> undecided
by Simon Marlow 29 Apr '08

29 Apr '08

Tue Apr 15 11:12:08 PDT 2008 Simon Marlow <simonmarhaskell(a)gmail.com> * BangPatterns: probably accept ==> undecided M ./status.hs -2 +3 View patch online: http://darcs.haskell.org/haskell-prime-status/_darcs/patches/20080415181208…

13 22

RFC: qualified vs unqualified names in defining instance methods
by Claus Reinke 26 Apr '08

26 Apr '08

consider Haskell 98 report, section 4.3.2 "Instance Declarations": The declarations d may contain bindings only for the class methods of C. It is illegal to give a binding for a class method that is not in scope, but the name under which it is in scope is immaterial; in particular, it may be a qualified name. (This rule is identical to that used for subordinate names in export lists --- Section 5.2.) For example, this is legal, even though range is in scope only with the qualified name Ix.range. module A where import qualified Ix instance Ix.Ix T where range = ... i consider this confusing (see example at the end), but even worse is that the reference to 5.2 appears to rule out the use of qualified names when defining instance methods. while this abbreviation of qualified names as unqualified names when unambiguous may be harmless in the majority of cases, it seems wrong that the more appropriate explicit disambiguation via qualified names is ruled out entirely. i submit that 4.3.2 should be amended so that qualified names are permitted when defining instance methods. here's an example to show that the unambiguity holds only on the lhs of the method definition, and that the forced use of unqualified names can be confusing: module QI where import Prelude hiding (Functor(..)) import qualified Prelude (Functor(..)) data X a = X a deriving Show instance Prelude.Functor X where fmap f (X a) = X (f a) where q = (reverse fmap,Prelude.fmap not [True],reverse QI.fmap) fmap = "fmap" note that there are two unqualified uses of 'fmap' in the instance declaration, referring to different qualified names: - in the lhs, 'fmap' refers to 'Prelude.fmap', which isn't in scope unqualified, only qualified - in the rhs, 'fmap' refers to 'QI.fmap' claus

4 5

Suggestion regarding (.) and map
by Cale Gibbard 25 Apr '08

25 Apr '08

Hello, In keeping with my small but seemingly extremely controversial suggestions for changes to the Prelude, here's a suggestion which I think is elegant and worth considering for the Haskell' Prelude: Rename fmap to map (like it was in Haskell 1.4), and define (.) as a synonym for it. Additionally, add the instance: instance Functor ((->) e) where map f g x = f (g x) (and hopefully the corresponding Monad instance as well) This has the beautiful effect of unifying the notation for two of the most important things in functional programming: function composition and functorial application, and will hopefully reduce the number of extraneous functor application definitions in the Prelude and libraries. Note that the fusion law for functors: map (f . g) x = map f (map g x) When written in terms of (.) becomes: (f . g) . x = f . (g . x) which means that (.) will still be reliably associative, and that the functor in question is always easily determined by the type of the last thing in any chain of (.)'s. This has a fair level of backwards compatibility obviously, as it's strictly a generalisation on both fronts. I've been playing around with it for a while, and like it quite a lot myself, though it would be more convenient to really use if it was in the Prelude. - Cale

6 9

patch applied (haskell-prime-status): wiki link for the $ issue
by Simon Marlow 23 Apr '08

23 Apr '08

Wed Apr 23 09:47:02 PDT 2008 Simon Marlow <simonmarhaskell(a)gmail.com> * wiki link for the $ issue M ./status.hs -1 +1 View patch online: http://darcs.haskell.org/haskell-prime-status/_darcs/patches/20080423164702…

1 0

Re: Some clarity please!
by Aaron Denney 23 Apr '08

23 Apr '08

On 2008-03-13, Ketil Malde <ketil(a)malde.org> wrote: > Aaron Denney <wnoise(a)ofb.net> writes: > >> Well, the way the report specifies that max's default definition >> is. I'd actually favor making that not an instance function at >> all, and instead have max and min be external functions. > > If you permit a naïve question: > > Prelude> :i Ord > class (Eq a) => Ord a where > compare :: a -> a -> Ordering > (<) :: a -> a -> Bool > (>=) :: a -> a -> Bool > (>) :: a -> a -> Bool > (<=) :: a -> a -> Bool > max :: a -> a -> a > min :: a -> a -> a > > ..while all functions could be easily derived from 'compare'. Or from > the Eq instance's (==) and (<), say. > > What is the reason for this? Efficiency? (Which couldn't be handled > equally well by RULES?) Otherwise, it looks like an invitation for > writing inconsistent instances. My impression (which may not be entirely accurate) is not primarily for efficiency (though that is one reason), but for ease of implementation. It may be easier in some cases to think through the various cases of compare, or to just figure out what (<=) is. Either of these is sufficient (perhaps in combination with (==) from the superclass). You can write things so that any of (<), (<=), (>), or (>=) are sufficient, but for writing the default compare, it's easiest to know ahead of time which you are basing it on, so definitions don't get circular. max and min seem to have neither justification going for them, although I suppose it's technically possible to write compare in terms of them and (==). I don't think GHC's RULES were around when Haskell 98 was being formalized, nor is it clear that one compiler's method should let other efficiency concerns go by the wayside. Of course, it would be nice to be able to write (==) in terms of compare. While doable manually there's no way to default it to that "smartly". There are similar issues with Functor and Monad. ISTR some discussion about this on the list previously. -- Aaron Denney -><-

3 2