- Haskell-prime - Haskell.org

overlapping instances and constraints
by Claus Reinke 26 Feb '06

26 Feb '06

the point about overlapping instances is that they shouldn't, so we are looking for ways to resolve what looks like overlaps unambiguously, so that there are no overlapping instances left. we don't want overlapping instances in the language definition, but we do want more expressive means of defining non- overlapping instances. 1. resolving overlaps in favour of the most specific declaration does so, so why is that approach slated as "adopt: probably no"? http://hackage.haskell.org/trac/haskell-prime/ticket/54 2. FDs can help to make types in instance declarations more specific, thus avoiding some overlaps or at least helping the "best-match" to resolve overlaps. defaults resolve some of the simplest overlaps (which instance of Num did you mean?), but not others, because their overloading is not expressed in terms of classes (which empty list did you mean?). 3. in this context, could someone please remind me what exactly is the reason that class constraints in instance declarations are ignored when deciding whether two instances overlap? we have two worlds to consider, the unconstrained world of semi-decidable type class programming, and the restricted world which guarantees termination of type class inference. in the first world, it seems there is no reason not to look at the constraints, because there are no termination guarantees anyway. and in the second world, it seems there is no reason not to look at the constraints, because we know that doing so will terminate nicely, thank you. so why are some instance declarations still rejected as overlapping even if their constraints clearly say they don't? cheers, claus

1 0

RE: Array interface refactoring
by Simon Marlow 24 Feb '06

24 Feb '06

On 23 February 2006 01:24, John Meacham wrote: > On Wed, Feb 22, 2006 at 06:47:19PM +0000, Ben Rudiak-Gould wrote: >> While we're on the topic, I have a couple of problems with the >> current array system that cut deeper than the naming: >> >> * The function for getting the bounds of an MArray is pure, so >> the interface can't accommodate resizable arrays. > > Indeed. this has bothered me a whole lot too. I keep on trying to > implement an expanding circular buffer and then being sad when it > can't be done. > > We could fix it fairly easily, we just need to get rid of HasBounds > as a superclass of MArray and add a new method 'getBounds' that > returns the bounds in the monad and then modify the default methods > to use getBounds rather than bounds. since they are all already in > the monad this will work just fine. > > it would be almost perfectly backwards compatable, the only change > would be some code might need to list HasBounds in their type > signatures seperatly. If we can get this in before the next release > of ghc that would be really great. I've added a ticket, scheduled for 6.6. Cheers, Simon

4 4

Re: Haskell-prime Digest, Vol 2, Issue 58
by John Hughes 24 Feb '06

24 Feb '06

From: "Claus Reinke" <claus.reinke(a)talk21.com> let's go through 5.2 "Export Lists" to see what would be missing if we tried to replace the export list with a separation of a module into a public (exported) and a private (local) part: ... any other issues I missed here? I feel unkeen. One of the nice things about Haskell is that definitions can appear in any order. That makes it possible to gather a group of logically related definitions together, within a module. With your proposal, exported definitions and non-exported ones would have to be separated. What would that mean in practice? Suppose I have a few exported functions and a collection of auxiliary functions that are used to implement them. I have two choices: either I put the exported definitions in the public section, and the remaining ones elsewhere in the private section, or I put everything in the private section with appropriate redeclarations in the public part -- exportedName = localExportedName or whatever. The first alternative has the disadvantages that logically related code is separated, and that the public section of the module may itself become quite large (since it contains full function definitions), making it hard to see at a glance what the exported names are. The second alternative has the disadvantage of introducing an indirection---finding the actual definition of an exported function becomes more difficult, because one must both scan the module for it, and first look up the public section to see what the private version is called. Neither alternative feels really attractive to me. Today's export lists at least have the advantage that it is easy to see what is exported, even if changing the status of a definition from private to public is a little awkward (with edits in two places). With a tool like Haddock installed too, once gets a pretty good view of the interface---arguably better than one can get from a public module section. Perhaps, given that Haddock is available, a public modifier makes more sense than an explicit export list---although code browsing would then require running Haddock during development much more often than today, and potentially on syntactically incorrect or ill-typed modules. Incidentally, the Erlang equivalent of Haddock, edoc, is distributed with the compiler, so that all Erlang installations include the tool, no matter what platform they're running on. Surely that's a prerequisite for adapting the language design on the assumption that tools of various kinds are available? John

10 11

RE: Export lists in modules
by Simon Marlow 24 Feb '06

24 Feb '06

On 22 February 2006 14:54, Malcolm Wallace wrote: > "Simon Peyton-Jones" <simonpj(a)microsoft.com> wrote: > >>> I don't seriously propose for haskell-prime that signatures should >>> be required on exports. Just permitting them would be a large and >>> useful step up already. >> >> If this is to be a serious proposal, someone had better think what to >> do about classes, data types, instances and so on. > > As far as I can see, there is very little to change. Here is a > concrete proposal. A qvar in an export list may optionally have a > type > signature. A qtycon or qtycls in an export list may optionally have > an annotation saying whether it is a type, newtype, data, or class. > Instances cannot be mentioned in export lists, and this does not > change. > > export -> qvar > | qtycon [ (..) | ( cname_1, ... , cname_n ) ] (n>=0) > | qtycls [ (..) | ( var_1, ... , var_n ) ] (n>=0) > | module modid > > becomes > > export -> qvar [ :: type ] > | [type] qtycon > | [newtype] qtycon [ (..) | ( cname_1, ... , cname_n > ) (n>=0) | [data] qtycon [ (..) | ( cname_1, ... , > cname_n ) (n>=0) | [class] qtycls [ (..) | ( var_1, > ... , var_n ) (n>=0) | module modid > > As far as import entity lists are concerned, we permit an optional > annotation for type synonyms, newtypes, datatypes, and classes: > > import -> var > | tycon [ (..) | ( cname_1, ... , cname_n ) ] (n>=0) > | tycls [ (..) | ( var_1, ... , var_n ) ] (n>=0) > > becomes > > import -> var > | [type] tycon > | [newtype] tycon [ (..) | ( cname_1, ... , cname_n ) > ] (n>=0) | [data] tycon [ (..) | ( cname_1, ... , > cname_n ) ] (n>=0) | [class] tycls [ (..) | ( var_1, > ... , var_n ) ] (n>=0) > > Anyone see any difficulties? You're combining two extensions here - type signatures in export lists and tagging exported entities. Not a problem, but I don't think they're inextricably linked. Regarding tagging of exported entities, see this message from John Meacham in a previous discussion: http://www.haskell.org//pipermail/haskell-prime/2006-January/000226.html basically tagging exports lets us completely separate the namespaces of classes and tycons (currently they share the same namespace, for no really good reason). But you don't need to go so far as to indicate the difference between type/data/newtype - just differentiating classes from tycons is enough to separate the namespaces. Indeed, the distinction between data & newtype should be a completely private property, so we certainly shouldn't distinguish those in exports/imports. It's less clear to me whether type and data/newtype should be distinguished or not, which is why I asked the question. I'm not sure I agree with John's answer, I'd rather just say 'type' or 'data', using 'data' for both data and newtype, like Haddock does. BTW, I think Simon PJ was asking about how to *declare* types & classes in export lists, given that you're adding signatures to export lists which are a kind of declaration. If you want to put more of the interface into the export list, shouldn't you put it all in? Cheers, Simon

6 7

RE: Export lists in modules
by Simon Marlow 24 Feb '06

24 Feb '06

On 23 February 2006 11:14, Malcolm Wallace wrote: > "Simon Marlow" <simonmar(a)microsoft.com> wrote: > >>> However, I would be >>> equally happy to combine type/newtype/data into a single keyword for >>> exports. >> >> for the record, I am in favour of tagging export specifiers with >> 'class' or 'type' (using 'type' for all type constructors, in light >> of yours and John's points). > > For the sake of avoiding confusion, perhaps we should choose a keyword > (or better, a reserved identifier with no meaning outside of the > export/import list) that is none of "type", "data", or "newtype"? How > about "datatype", "tycon", or the like? Then it would be clearer that > there is no relationship between the way the type is defined, and how > its namespace is notated in the export list. Yes, I suppose you could have another keyword. In fact, a keyword is unnecessary, as long as classes are identified with the 'class' keyword, there's no need to tag type constructors too. This is the most minimal extension, and avoids both the confusion of referring to synonyms and datatypes in the same way, and taking a new keyword. Cheers, Simon

3 2

Re: Export lists in modules
by Benjamin Franksen 24 Feb '06

24 Feb '06

On Thursday 23 February 2006 09:53, Ketil Malde wrote: > Wolfgang Jeltsch <wolfgang(a)jeltsch.net> writes: > >> Personally, I would greatly prefer to have libraries that do not > >> clash with common Prelude functions. > > > > I would solve this problem by reducing the Prelude to just a core. > > List function could go, for example, (mostly) into Data.List. > > If this means that you must import Data.List almost everywhere, this > won't change anything - only add yet another import to every file. But you could import something different instead! For instance, I can then easily replace Prelude stuff with Edison or some other data structure library. That is what the whole discussion is about. I agree with the rest of what you wrote. Ben

2 1

Re: Export lists in modules
by Jared Updike 24 Feb '06

24 Feb '06

> I am not sure if this has been mentioned before, but something I > would really find useful is the ability to tell Haskell to export > everything in a function except for some named functions. No one has responded so I thought I would make a suggestion about what the syntax might look like to do this. Currently the syntax to set what gets exports is: > module Module ( list, of, things, to, export ) where .... and to hide things on import is > import Module hiding ( list, of, things, not, to, import ) How about combining the two (since 'hiding' is already a reserved word): > module Module hiding ( list, of, things, not, to, export ) where .... Everything gets exported except what you explicitly hide. Is this general enough? Are there reasons why this might not work? And does this solve your problem? Does anyone like this idea (aethestically and pragmatically)? Jared.

12 23

RE: Export lists in modules
by Simon Marlow 23 Feb '06

23 Feb '06

On 23 February 2006 11:14, Malcolm Wallace wrote: > "Simon Marlow" <simonmar(a)microsoft.com> wrote: >> If modules are to contain interfaces, I don't >> think extending the export list is the way to do it. I'd rather do >> something like: -------------------------------------- >> modules M exports >> >> class Eq a where >> (==) :: a -> a -> Bool >> >> data T :: * -> * >> f :: T -> Int >> mkT :: Int -> T >> >> where -- implementation below here >> -------------------------------------- > > But, apart from adding fuller signatures than I proposed, that is > exactly the same as an export list, modulo some very minor syntactic > differences! Of course it's the same as the export list, but with different syntax, and extended to allow specifying the full interface. That's the point ;-) The main difference is that I'm doing away with parentheses, commas, and export specifiers, and using layout and full declaration syntax instead. (I don't really want to discuss this very rough idea any more though, it's just a distraction, and I'm not sure I like it anyway). Cheers, Simon

5 6

Scoped type variables
by Ben Rudiak-Gould 23 Feb '06

23 Feb '06

Simon PJ thinks that Haskell' should include scoped type variables, and I tend to agree. But I'm unhappy with one aspect of the way they're implemented in GHC. What I don't like is that given a signature like x :: a -> a there's no way to tell, looking at it in isolation, whether a is free or bound in the type. Even looking at the context it can be hard to tell, because GHC's scoping rules for type variables are fairly complicated and subject to change. This situation never arises in the expression language or in Haskell 98's type language, and I don't think it should arise in Haskell at all. What I'd like to propose is that if Haskell' adopts scoped type variables, they work this way instead: 1. Implicit forall-quantification happens if and only if the type does not begin with an explicit forall. GHC almost follows this rule, except that "forall." (with no variables listed) doesn't suppress implicit quantification---but Simon informs me that this is a bug that will be fixed. 2. Implicit quantification quantifies over all free variables in the type, thus closing it. GHC's current behavior is to quantify over a type variable iff there isn't a type variable with that name in scope. Some care is needed in the case of class method signatures: (return :: a -> m a) is the same as (return :: forall a. a -> m a) but not the same as (return :: forall a m. a -> m a). On the other hand the practical type of return as a top-level function is (Monad m => a -> m a), which is the same as (forall m a. Monad m => a -> m a), so this isn't quite an exception depending on how you look at it. I suppose it is a counterexample to my claim that Haskell 98's type language doesn't confuse free and bound variables, though. If rule 2 were accepted into Haskell' and/or GHC, then code which uses implicit quantification and GHC scoped type variables in the same type would have to be changed to explicitly quantify those types; other programs (including all valid Haskell 98 programs) would continue to work unchanged. Note that the signature "x :: a", where a refers to a scoped type variable, would have to be changed to "x :: forall. a", which is potentially confusable with "x :: forall a. a"; maybe the syntax "forall _. a" should be introduced to make this clearer. The cleanest solution would be to abandon implicit quantification, but I don't suppose anyone would go for that. With these two rules in effect, there's a pretty good case for adopting rule 3: 3. Every type signature brings all its bound type variables into scope. Currently GHC has fairly complicated rules regarding what gets placed into scope: e.g. f :: [a] -> [a] f = ... brings nothing into scope, f :: forall a. [a] -> [a] f = ... brings a into scope, f :: forall a. [a] -> [a] (f,g) = ... brings nothing into scope (for reasons explained in [1]), and f :: forall a. (forall b. b -> b) -> a f = ... brings a but not b into scope. Of course, b doesn't correspond to any type that's accessible in its lexical scope, but that doesn't matter; it's probably better that attempting to use b fail with a "not available here" error message than that it fail with a "no such type variable" message, or succeed and pull in another b from an enclosing scope. There are some interesting corner cases. For example, rank-3 types: f :: ((forall a. a -> X) -> Y) -> Z f g = g (\x -> <exp>) should a denote x's type within <exp>? It's a bit strange if it does, since the internal System F type variable that a refers to isn't bound in the same place as a itself. It's also a bit strange if it doesn't, since the identification is unambiguous. What about shadowing within a type: f :: forall a. (forall a. a -> a) -> a I can't see any reason to allow such expressions in the first place. What about type synonyms with bound variables? Probably they should be alpha-renamed into something inaccessible. It seems too confusing to bring them into scope, especially since they may belong to another module and this would introduce a new notion of exporting type variables. I like rule 3 because of its simplicity, but a rule that, say, brought only rank-1 explicitly quantified type variables into scope would probably be good enough. Rules 1 and 2 seem more important. I feel like a new language standard should specify something cleaner and more orthogonal than GHC's current system. -- Ben [1]http://www.mail-archive.com/glasgow-haskell-users@haskell.org/msg09117.ht…

3 3

Re: Export lists in modules
by John Hughes 23 Feb '06

23 Feb '06

>Subject: Re: Export lists in modules > > Type signatures currently do more than state the type of a variable. They potentially (i) enable polymorphic recursion, and (ii) disable the monomorphism restriction, thus losing sharing. It would be very strange if a type signature *in an export list* were to have these effects--the export list surely should not change the way a module is compiled and type-checked. One good principle is that commenting out the export list should not change the way any definition is compiled, only what is exported. After all, commenting out the exports (so that all definitions can be tested) is a common step when debugging a module. I would conclude that polymorphic recursion should be enabled only if a type signature appears *in the body of the module*, similarly the M-R should be disabled only if an overloaded type signature appears in the body of the module. The same principle should apply to any other type signatures that change the way a definition is type-checked, if they are included in Haskell', such as rank-2 or rank-N type signatures. John

2 1