February 2006 - Haskell-prime

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

RE: Module System
by Simon Marlow 23 Feb '06

23 Feb '06

On 22 February 2006 13:09, David Roundy wrote: > On Tue, Feb 21, 2006 at 03:50:29PM +0000, Henrik Nilsson wrote: >> I'm already somewhat unhappy about the way most present Haskell >> tools map module names to path names (I'd generally prefer to have >> the possibility to flatten my file hierarchies by, say, using dots >> in my file names), but at least these assumptions are not in the >> Haskell 98 language definition. > > I'd like to second this. I've been annoyed by the fact that ghc > requires extra subdirectories in order to use hierarchical modules, > and would be doubly annoyed if the language definition declared that > this couldn't be fixed. jhc's behavior sounds nicer, but I'd rather > there were the possibility of naming our haskell files whatever we > liked. Actually in GHC you can name your source files whatever you like, as long as you tell GHC the names of all the source files on the command line and use --make. eg. ghc --make My.Dotted.Module.hs Main.hs works fine. Similarly with GHCi. It's only when GHC has to actually *find* a source file for a module that the hierarchical naming convention comes into play. There are two reasons we don't allow the dotted convention: one is simplicity (the description of where GHC looks for files is already a bit complex), and the other is performance - GHC does a lot of looking for interface files, and looking in more places might slow things down (I haven't measureed it, though). Cheers, Simon

2 1

RE: Module System
by Simon Marlow 23 Feb '06

23 Feb '06

On 22 February 2006 14:55, Ben Rudiak-Gould wrote: > Simon Marlow wrote: >> there's a lack of modularity in the current >> design, such that renaming the root of a module hierarchy requires >> editing every single source file in the hierarchy. The only good >> reason for this is the separation between language and >> implementation. > > I don't see how this is related to implementation. Surely all the > language spec has to say is that the implementation has some > unspecified way of finding the code for a module given only its > canonical name, The point is that currently the language definition includes everything necessary to determine the meaning of a multi-module program. Losing this property is unfortunate, but probably ultimately necessary. To answer your question, yes - the spec would have to refer to an implementation-defined way to pair module definitions with import declarations. Cheers, Simon

1 0

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

23 Feb '06

On 22 February 2006 17:27, Malcolm Wallace 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). I'm not in favour of adding type signatures to export lists. It's a half way solution to specifying interfaces, and I'd rather design it properly from scratch. 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 data T a = C a Int f = ... -------------------------------------- Not a proposal by any means, and I don't think that Haskell' should tackle this, but this seems the right direction to me. Cheers, Simon

3 2

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

23 Feb '06

On 23 February 2006 10:28, Jean-Philippe Bernardy wrote: > I lost track of what is the issue being tackled here. What's broken > with the current way of specifying exported entities? Imho it's the > best system that I've seen (across all languages I know). > > A lot of language chose to separate interface from implementation in > source files. (eg. Ada) I find this annoying because to change a > single thing you have very often to edit two files. The > counter-argument is that the user of a module wants to see only the > interface. However, with modern tools like haddock, one doesn't look > at the source code any more to understand the interface of a module, > but some specifically processed version of the sources, so this > argument is void. So, again, please keep implemenation and interface > as close as possible. > > Public modifiers permit this adequately, but they don't fit with > haskell syntax style very well. > > The current export list being 1. very light 2. optional and 3. > allowing to re-order presentation in haddock (or such a similar tool) > makes it the very best solution for haskell, imho. I certainly sympathise with this point of view. It's a difficult call, there are good arguments on both sides. For interfaces: - separately declaring interfaces is generally considered good software engineering; stops you accidentally changing the interface - having an interface in the source code makes browsing the code that much easier - replaces the export list - makes mutually recursive modules easier to implement (maybe) Against interfaces: - good tool support lets you browse interfaces anyway, and could tell you when you break an existing interface - makes life harder for the implementer: interface and documentation are separated from the implementation, or are duplicated with the implementation. Code is less "agile". - more complication in the language definition and compiler Cheers, Simon

1 0

RE: Module System
by Simon Marlow 23 Feb '06

23 Feb '06

On 21 February 2006 18:22, Henrik Nilsson wrote: > Georg wrote: > > > Well, the hierarchical module system as it is implemented today and > > how it is proposed for being included into Haskell' uses the file > > system to locate modules. > > Yes, tools need to, somehow, locate modules. > > Yes, for portability reasons, it is convenient if tools support common > conventions. > > But that does not mean that the *language standard* should nail down > these details. While I've always liked the principle that the language spec is completely independent of implementation details such as the filesystem, I'm not sure we can hang on to it forever. This is not the first time that someone has made the same suggestion as Georg, and for good reasons: there's a lack of modularity in the current design, such that renaming the root of a module hierarchy requires editing every single source file in the hierarchy. The only good reason for this is the separation between language and implementation. There are more elaborate proposals, such as "grafting", where a module sub-hierarchy can be placed at an arbitrary position in the namespace at compile time, which boils down to renaming modules at compile time again, and violating the language/implementation separation. I don't have anything concrete to say (sorry!) except that I'm not convinced that the language spec should require a module to declare its full name in the source code any more. I certainly don't believe that the language spec should say anything at all about file systems, but it should be open to the possibility that "unspecified implementation-dependent behaviour" might affect how module definitions are paired with import declarations. Cheers, Simon

5 4

RE: minimal Prelude (was Re: Export lists in modules)
by Simon Marlow 23 Feb '06

23 Feb '06

On 22 February 2006 22:04, Malcolm Wallace wrote: > Wolfgang Jeltsch <wolfgang(a)jeltsch.net> writes: > >>> module Prelude.Standard >>> ( module Prelude >>> , module Prelude.Num >>> , module Prelude.Comparison >>> , module Prelude.Monad >>> , module Prelude.List >>> , module Prelude.Maybe >>> , module Prelude.Either >>> , module Prelude.Tuple >>> , module Prelude.IO >>> , module Prelude.Text >>> ) >> >> Why Prelude.List, not Data.List, etc.? > > No particular reason. Either choice would be good. (But I didn't > want to imply that everything currently in Data.List would be > re-exported, since it defines more than just Prelude entities.) Having all these extra modules seems like too much structure for not much gain. Also "Prelude.Standard" is ambiguous: which standard? Instead, I suggest Prelude.Haskell98 for the Haskell98-compatible prelude (in the haskel98 package, of course). I'm agnostic about whether we strip the Prelude down to the absolute minimum, or just remove some of the more less-used things. Cheers, Simon

1 0

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

23 Feb '06

On 23 February 2006 01:48, John Meacham wrote: > On Wed, Feb 22, 2006 at 05:11:26PM -0000, Simon Marlow wrote: >> 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. > > my best argument against this is to try to compile the following under > ghc in strict haskell 98 mode > >> class Foo a >> instance Foo IOError > > oops! Actually I wanted to distinguish type and data, and type and newtype, but not data and newtype (my lanugage was ambiguous, sorry about that). > Even if the restriction on synonyms in instance heads is lifted, being > able to use type synonyms to give true aliases for types is important > part of writing interfaces that can evolve and encapsulating > implementation details. > > But more importantly, The haskell module system has a nice philosophy > of just being about controlling the namespace of what is in scope in a > module. Conflating representation details with it would just confuse > things. I'd say use 'type' for everything in the type namespace, class > for everything in the class namespace, value (or nothing) for things > in the value namespace and so forth. We want the module system to > describe precicely what names are in scope and what entities names in > a module map too, nothing more. It is also a much simpler set of > rules to remember and much more straightforward to specify. That's a fair point. I agree it's a nice property that the module system just talks about *names* and nothing else, and on that basis you're right that distinguishing type synonyms from other type constructors in export specifiers would be inconsistent. Cheers, Simon

1 0

RE: Export lists in modules
by Simon Peyton-Jones 23 Feb '06

23 Feb '06

| 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. Simon

6 5