February 2006 - Haskell-prime

RE: the MPTC Dilemma (please solve)
by Simon Peyton-Jones 28 Feb '06

28 Feb '06

I would not say that it's well-specified, no. What we do know is this: GHC may loop if you use -fallow-undecidable-instances -- but if it terminates, the program is well typed and should not "go wrong" at runtime. S | -----Original Message----- | From: haskell-prime-bounces(a)haskell.org [mailto:haskell-prime-bounces@haskell.org] On Behalf Of | Ashley Yakeley | Sent: 21 February 2006 20:13 | To: haskell-prime(a)haskell.org | Subject: Re: the MPTC Dilemma (please solve) | | Simon Peyton-Jones wrote: | | > Of course -fallow-undecidable-instances still lifts all restrictions, | > and then all bets are off. | | Is the behaviour of GHC with -fallow-undecidable-instances (and | -fcontext-stack) well-understood and specifiable? It is a very useful | option, as you can join (meet?) classes like this: | | class P a | class Q a | | class (P a,Q a) => PQ a | instance (P a,Q a) => PQ a | | -- | Ashley Yakeley | | _______________________________________________ | Haskell-prime mailing list | Haskell-prime(a)haskell.org | http://haskell.org/mailman/listinfo/haskell-prime

3 5

Re: public/private module sections (was: Haskell-prime Digest, Vol 2, Issue 58)
by Benjamin Franksen 28 Feb '06

28 Feb '06

On Friday 24 February 2006 16:38, Bulat Ziganshin wrote: > i personally prefer to have > public/private modifiers on each function and gather interface > documentation by tools like haddock Me too. Ben

7 6

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 25 Feb '06

25 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 24 Feb '06

24 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