- Haskell-prime - Haskell.org

patch applied (haskell-prime-report): Fix indentation in an example
by Ian Lynagh 24 Jul '09

24 Jul '09

Mon Jul 20 17:31:43 PDT 2009 Ian Lynagh <igloo(a)earth.li> * Fix indentation in an example Using tabs doesn't give the correct indentation in the HTML output M ./report/modules.verb -2 +2 View patch online: http://darcs.haskell.org/haskell-prime-report/_darcs/patches/20090721003143…

1 0

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: change to qualified operator syntax
by haskell＠henning-thielemann.de 14 Jul '09

14 Jul '09

Adding to an old thread: http://www.haskell.org/pipermail/haskell-prime/2008-April/002441.html I like to note that I'm against this proposal. The example given in http://hackage.haskell.org/trac/haskell-prime/wiki/QualifiedOperators namely [Red..] can be easily resolved by adding a space, thus [Red ..]. I use qualified operators occasionally, since I use NumericPrelude and thus have to import some things from Prelude in a qualified way. As there will appear more and more infix operators in libraries along with more name clashes (e.g. recently discussed List.++ and Monoid.++), qualified operator names will become not so uncommon. Of course, to keep the spirit of infix operators, you will better define custom operators locally, but this is only reasonable if you use an infix operator more than once. The current syntax is also in a way consistent, since e.g. (+) coincides with a two side operator section, which is no longer true with the new proposal. Also (...) and `...` are dual, which is a nice property.

9 13

[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

what about moving the record system to an addendum?
by Samuel Bronson 07 Jul '09

07 Jul '09

According to <http://hackage.haskell.org/trac/haskell-prime/wiki/Status>, ticket #99 was rejected, but the tickets own page, <http://hackage.haskell.org/trac/haskell-prime/ticket/99>, says "probably yes". Which is it? I was about to propose this myself, but decided to check the trac just in case it had already been proposed, Haskell being so popular with smart people and all, and was at first rather disappointed and ready to write an angry rant to the list, then rather confused when I noticed the ticket's page said almost the exact opposite of the Status page. In particular, I want records to be considered an extension to Haskell', to be implemented only by compilers that care, and even then only allowed with a LANGUAGE pragma like this: {-# LANGUAGE TraditionalRecordSyntax #-} For pre-Haskell' compilers, we would want something like: {-# LANGUAGE NoTraditionalRecordSyntax #-} which would mean extending the LANGUAGE pragma to support turning extensions off by adding/removing a No from the front of it. Hmm, is it really the case that nobody has proposed LANGUAGE pragmas for Haskell'? I don't see them listed on the Status page. I guess the work involved here is basically: (a) Go through Haskell 98, find all the parts that talk specifically about record syntax, and write up the list of such places. (b) Implement this in GHC: <http://hackage.haskell.org/trac/ghc/ticket/3356> (c) Add support for negating extension names by adding/removing No in front of extension names to Cabal: <http://hackage.haskell.org/trac/hackage/ticket/567> (d) Add {-# LANGUAGE #-} to Haskell' What do you folks think?

8 10

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

A HERE Document syntax
by Jason Dusek 24 Apr '09

24 Apr '09

The conventional HERE document operator -- `<<` -- is not a good fit for Haskell. It's a perfectly legal user-level operator. I'd like to propose the use of backticks for HERE documents. Examples -------------------------------------------------------------- Double backtick would introduce an "indented HERE document", one that would be bounded by the layout rules in the same way as `do` blocks. Just like a `do`, the doubled backticks must be followed by whitespace. For example: rawXML = `` <a> <b> text </b> </a> This is just the same as the Haskell string: "<a>\n <b> text </b>\n</a>" Note that the final newline -- and any final whitespace -- is stripped. Non-indented HERE documents are also of value; these require a terminator as well as an initializer. Any number of backticks greater than 2 introduces a non-indented HERE document; the same number of backticks terminates it. All leading whitespace up to and including the first newline is consumed; all final whitespace is likewise consumed. For example: usage = ```` USAGE: hello_world <name>? Says hello, optionally to <name>. ```` This yields the Haskell string: "USAGE: hello_world <name>?\n\nSays hello, optionally to <name>." There is a natural relationship between quasi-quoting and HERE documents. Thankfully, our rule about spaces gives us a way to integrate quasi-quoters. import Regexen(r) matchUTCDate = ``r` \d{4}-\d\d-\d\dT\d\d:\d\d:\d\dZ matchSource = ``r` [a-z]+\[\d+\] We use two backticks to introduce an indented HERE document and then specify the regular expression quasi-quote interpreter. This is brief and clear and not too full of demarcating cruft; it's not the usual `/[a-z]+\[\d+\]/` but it's still pretty nice. String Escapes & The Backslash Plague -------------------------------------------------------------- Naturally, one desires to use character escapes in HERE documents; however, the backslash plague is a bother and we'd not like that so much, either. Many Haskell escapes should be ignored. The string escapes for double quote and newline are unnecessary; likewise, we don't need to escape backslash. On the other hand, we can not do without character escapes for `\BEL`, Chinese characters and so forth. Let us adopt the rule that the 2 and 3 letter escapes are kept, as well as the hexadecimal escapes; the "control-with-character" escapes, octal escapes, decimal escapes and all single character escapes save `\&` are ignored. What if we want to document the escape rules of HERE documents in a HERE document? We have to have a way to "unescape" the escapes. The rule proposed is odd but simple: escaping = `` There comes a time when one desires to escape a magical character such as ASCII bell (\BEL). How shall we do it? We insert it with \BEL\&\\. \BEL\ We can insert a string of \BELs as long as they are terminated with with a \. We enter \BEL\BEL\BEL\&\\ to ding three times. \BEL\BEL\BEL\ As long as an escape pattern does not end with a backslash, it is interpreted literally. The empty string escape (\&) has an unusual power -- it is a "combo breaker" and prevents an otherwise legitimate sequence of escapes from being escaped. How do we output the literal we used for \BEL\&\\? It's \BEL \BS\\& \BS\\\. This example rings once when the first paragraph is printed and thrice when the second is printed. It becomes the Haskell string: unlines ["There comes a time when one desires to escape a magical" ,"character such as ASCII bell (\\BEL). How shall we do it?" ,"We insert it with \\BEL\\. \BEL" ,"" ,"We can insert a string of \\BELs as long as they are" ,"terminated with with a \\. We enter \\BEL\\BEL\\BEL\\ to" ,"ding three times. \BEL\BEL\BEL" ,"" ,"As long as an escape pattern does not end with a" ,"backslash, it is interpreted literally. The empty string" ,"escape (\\&) has an unusual power -- it is a \"combo" ,"breaker\" and prevents an otherwise legitimate sequence" ,"of escapes from being escaped. How do we output the" ,"literal we used for \\BEL\\? It's \\BEL \BS\\& \BS\\\\." ] This is the most sensible way that I can see to get rid of the need to escape backslashes but I grant it's a bit burdensome. I expect such advanced escaping to be rarely used. HERE documents are an aid to quasi-quotation and scripting. The syntax here proposed is simple, using only backticks in an unusual pattern, and allows for following the layout rule when that is desired. -- Jason Dusek

2 1

One more 'do' pattern
by Bulat Ziganshin 28 Mar '09

28 Mar '09

Hello haskell-prime, as we know, the following code action x y >>= \v -> do can be shortened to following v <- action x y but there is one more very popular 'do' pattern, with a 'do' block passed as a parameter: for list $ \element -> do ... or bracket createDialog destroyDialog $ \dialog -> do ... what about adding one more 'do' sugar that will allow to move variable name to the left, such as for element in list do or with dialog in bracket createDialog destroyDialog do or just element <-- for list do dialog <-- bracket createDialog destroyDialog do ? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

5 21