June 2009 - Haskell-prime

Proposal: ExplicitForall
by Niklas Broberg 24 Jul '09

24 Jul '09

Hi all, (I'm writing this to several lists since it involves GHC (implementation of extensions), cabal (registration of extensions) and some future Haskell standard (formalisation of extensions).) In my quest to implement all known syntactic extensions to Haskell in my haskell-src-exts package, I've become painfully aware of the sometimes ad-hoc nature that these extensions have been added to GHC. This should not be taken as criticism per se, GHC is awesome and I'm sure a lot of thought and research has gone into all of these extensions. I think the problem (from my point of view) is rather that most of the extensions are only really "interesting" on a type system level, whereas the syntactic level is rather trivial, and thus the latter has (rightly) gotten far less formal attention. I hope my putting the light on these issues will be a help and a kickoff towards improving the state of formalisation of the known and registered (with Cabal) extensions. One of the most blatant and (to me) problematic such issues is the matter of using 'forall'. GHC has a number of extensions relating to the use of forall-quantified types in various interesting ways. With none of these extensions on, forall is not considered a keyword, so the syntax with explicit forall quantification cannot be used at all ('forall' is considered a varid). However, with *any* extension on that relates to forall-quantified types, forall is a keyword, and can syntactically be used in types *anywhere*. This doesn't mean all such types will pass the type checker, most of them won't in fact, but syntactically there is really no (or at least very little) difference. Conceptually, all of these extensions (specifically PolymorphicComponents, Rank2Types, RankNTypes, LiberalTypeSynonyms and ScopedTypeVariables (and strangely also ExistentialQuantification)) thus have one thing in common. They all enable syntactically forall-quantified types. They allow different uses of these types as far as the type system is concerned, but syntactically there is no difference between type and type (in fact there cannot be, as I discussed in a recent blog post [1]). Funnily enough there are also some uses of forall-quantified types that are common to all of these extensions - using a forall just to make polymorphism explicit in a type doesn't change anything as far as the type system is concerned, so e.g. the types '(Eq a) => a -> Bool' and 'forall a . (Eq a) => a -> Bool' are equivalent. The latter type can be given to a function when any of the listed six extensions are given, even if most of them have nothing to do with this at all! So, what I'm getting at is an idea that Isaac Dupree gave as a comment to my blog post. He said: "I wish there was a plain old ExplicitForall extension that enabled the keyword in types (without extending the type checker -- only like (id :: forall a. a -> a) would be allowed)". I think this is a really great idea. I find it conceptually appealing, since I think it covers exactly that blind spot that is the seemingly unintended intersection between all these extensions. And it also makes the separation of concern between the syntactic level and the type system more clear. Any formalisation of any of the type system extensions would not need to bother with syntactic details, but can simply be said to imply ExplicitForall. I would thus like to propose the following formalisation of the ExplicitForall extension: ========================================= ExplicitForall enables the use of the keyword 'forall' to make a type explicitly polymorphic. Syntactically, it would mean the following change to Haskell 98: * 'forall' becomes a reserved word. * '.' (dot) becomes a special (not reserved) operator. * The following syntactic rule changes: type -> 'forall' tyvars '.' type | context '=>' type | ftype ftype -> btype '->' type | btype gendecl -> vars '::' type It does not allow the use of explicitly polymorphic types in any way not already allowed by Haskell 98 for implicitly polymorphic types. ========================================= One thing to note is that I haven't touched the matter of ExistentialQuantification in the above. Syntactically this is a different beast entirely, and could well be handled separately, though it's really an artifact of the way we (by default) write our data type declarations. Using GADT-style declarations, existential quantification goes nicely along with the others by following the same syntactic rules for types, even though from a type system it is of course still quite different from the rest. But with the ordinary Haskell 98 declaration style, we could define the syntactic part of the ExistentialQuantification extension as the following: ========================================= ExistentialQuantification allows data constructors to take existentially quantified arguments. Syntactically, it means the following changes to Haskell98: * 'forall' becomes a reserved word. * '.' (dot) becomes a special (not reserved) operator. * The following syntactic rule changes: constrs -> econstr_1 '|' ... '|' econstr_n econstr -> ['forall' tyvars '.' [context '=>']] constr ========================================= My hope is that you'll all agree with me on the need and rationale for the ExplicitForall extension, and that my proposal for formalisation is good enough for adoption. I feel much less strongly about ExistentialQuantification, and would love to hear some more input on that matter, but I do think it needs to be addressed one way or the other. Thoughts? Cheers, /Niklas [1] http://nibrofun.blogspot.com/2009/06/whats-in-forall.html

3 4

Proposal: Deprecate ExistentialQuantification
by Niklas Broberg 23 Jul '09

23 Jul '09

Hi all, Following the discussion on the use of 'forall' and extensions that use it [1], I would hereby like to propose that the ExistentialQuantification extension is deprecated. My rationale is as follows. With the introduction of GADTs, we now have two ways to write datatype declarations, the old simple way and the GADTs way. The GADTs way fits better syntactically with Haskell's other syntactic constructs, in all ways. The general style is (somewhat simplified) "keyword type 'where' decls", where keyword can in Haskell 98 be class or instance, but with GADTs also data. The old simple way of defining data types is the odd one out. It certainly has its uses though, in particular when defining some simple (but possibly large) enum-like datatype (like cabal's Extension type incidentally), then it obviously becomes tedious to have to restate the trivial type signature for each constructor. Using GADTs style syntax it is possible to allow constructors with existentially quantified arguments with *no additional syntax needed*. It follows nicely from the standard syntax for type signature declarations (assuming explicit foralls), e.g. the following "normal" datatype declaration data Foo = forall a . Show a => Foo a which uses ExistentialQuantification syntax, could be written as data Foo where Foo :: forall a . Show a => a -> Foo which is syntactically just a normal type signature. The upside of deprecating ExistentialQuantification is thus that we keep the syntax cleaner, and we keep the old style of datatype declarations simple (as it should be, IMO). Anything fancier can use the GADTs syntax, which anyone that uses something fancier should be acquainted with anyway. The downside is that we lose one level of granularity in the type system. GADTs enables a lot more semantic possibilities for constructors than ExistentialQuantification does, and baking the latter into the former means we have no way of specifying that we *only* want to use the capabilities of ExistentialQuantification. My own take on that is that what we have now is a wart that should be removed, and that if we think that the latter is a problem then the way to go would be to split the monolithic GADTs extension into several semantic levels. There is of course also the downside that we break existing code, but that's a standard problem with improvement through deprecation which I will pay no mind. Discussion period: 2 weeks Cheers, /Niklas [1] http://www.haskell.org/pipermail/glasgow-haskell-users/2009-June/017432.html

9 19

[Proposal] Move most of Control.Monad to Control.Applicative
by Thomas Davie 11 Jul '09

11 Jul '09

Hi, Most of Control.Monad doesn't actually rely on Monads, but instead Applicatives. Data.Traversable fixes this in a lot of cases, but it would be nice to have the 'standard' functions as general as possible. My quick reading of Control.Monad says these at least should fall victim to demotion to applicatives: mapA :: (Applicative f) => (a -> f b) -> [a] -> f [b] mapA_ :: (Applicative f) => (a -> f b) -> [a] -> f () sequence :: (Applicative f) => [f a] -> f [a] sequence_ :: (Applicative f) => [f a] -> f () filterA :: (Applicative f) => (a -> f Bool) -> [a] -> f [a] mapAndUnzipA :: (Applicative f) => (a -> f (b,c)) -> [a] -> f ([b], [c]) zipWithA :: (Applicative f) => (a -> b -> f c) -> [a] -> [b] -> f [c] zipWithA_ :: (Applicative f) => (a -> b -> f c) -> [a] -> [b] -> f () replicateA :: (Applicative f) => Int -> f a -> f [a] replicateA_ :: (Applicative f) => Int -> f a -> f () when :: (Applicative f) => Bool -> f () -> f () unless :: (Applicative f) => Bool -> f () -> f () I may have missed some. Bob

4 6

Outlaw tabs
by Achim Schneider 11 Jul '09

11 Jul '09

I guess everyone knows why. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited.

11 17

Re[2]: Proposal: ExplicitForall
by Bulat Ziganshin 24 Jun '09

24 Jun '09

Hello Brandon, Wednesday, June 24, 2009, 8:56:30 AM, you wrote: > but also e.g. if you are actually compiling Haskell98, hierarchical > modules should be illegal. afaik, HM and FFI are just considered to be included in H98 later, so these are part of (revised) standard -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 0