October 2006 - Haskell-prime

(Pattern) Guards in lambdas
by Claus Reinke 20 Oct '06

20 Oct '06

since Pattern Guards appear to be popular with the committee, I suggest to revisit the decision to drop guards from lambdas: (a) http://www.cse.unsw.edu.au/~dons/haskell-1990-2000/msg00353.html (b) http://www.cse.unsw.edu.au/~dons/haskell-1990-2000/msg00382.html 1. I disagree that this was a simplification of Haskell the language became smaller (fewer valid programs), but that reduction in size was bought by breaking a symmetry (pattern matches are the same whereever they are used) and adding a restriction (no guards for patterns in lambdas), so the smaller language is actually more complicated. 2. adding guards to lambdas can only cause more program runs to fail (no chance of handling pattern-match/guard failure and fall through), so it is kind of understandable that this feature was considered dubious. however, - adding a guard there is comparable to adding an assertion, a feature often considered valuable - with pattern guards, the guard is no longer restricted to filtering, and that added functionality is not currently accessible for lambda patterns suggestion: undo removal of guards from lambdas, especially (but not only) if pattern guards make it into the language. claus ps. are there any notes regarding the discussion and stylistic grounds mentioned in (a)?

6 6

Standard syntax for preconditions, postconditions, and invariants
by Alan Falloon 20 Oct '06

20 Oct '06

I propose that haskell' include a standard syntax for invariants that the programmer wants to express. Here is a rough idea (just to get the point across): \begin{code} head :: [a] -> a head xs @ require { not (null xs) } head (x:xs) = x reverse :: [a] -> [a] reverse @ ensure { reverse (reverse xs) == xs } reverse [] = [] reverse (x:xs) = reverse xs ++ x data RedBlackTree a = RBLeaf a | RBNode Bool (RedBlackTree a) a (RedBlackTree a) invariant RedBlackTree a where RBNode False _ l _ r ==> redDepth l == redDepth r \end{code} The intent is not to have standardized checks on the invariants, its just to supply a common way to specify invariants to that the various strategies for checking them can all work from the same data. For example, one tool might use the invariants to generate QuickCheck properties, a compiler might provide a mode that does run-time checking of the invariants, and another tool might try to prove the invariants statically like in ESC [1]. Eventually, we might end up with sophisticated hybrid approaches that combine static proof with generating test cases for the unprovable bits. At the very least Haddock could include the invariants as part of the documentation. [1] http://www.cl.cam.ac.uk/~nx200/research/escH-hw.ps

4 4

Here-docs in Haskell source
by Alistair Bayley 19 Oct '06

19 Oct '06

Apologies if this has been covered already... I've searched the haskell-prime list archive and not found anything on this. I'd like to submit a request for a fairly trivial feature: multi-line text literals in source, AKA here-docs. You know, like the ruby/perl/bash <<EOD...EOD, or python's triple-quotes, or C#'s @"...". My motivation: primarly for embedding SQL statements in program text. I'm sure there are plenty of other uses... I'm aware of the trailing-\-leading-\ option, but IMHO that's almost on a par with ++ ".." for usability: if you have a chunk of text you need to paste into your program as a text literal, you must modify every line. I know this can be automated, but it's still an extra step, and if you need to extract it for editing, you have to strip off the surrounding crud. Here's an old related thread, but I can't tell if some conclusion was reached: http://www.mail-archive.com/haskell-cafe@haskell.org/msg01343.html Alistair

9 16

Concurrency
by William DUCK 15 Oct '06

15 Oct '06

Hello, Just to point out, this marvellous work : http://www.seas.upenn.edu/~lipeng/homepage/unify.html Best Regards, Will

2 1

Y0: (y-naught)
by William DUCK 15 Oct '06

15 Oct '06

Hello, I ask myself if we could take some ideas from this paper : http://www.eecs.harvard.edu/~aleks/papers/hoarelogic/httsep.pdf Y0: (y-naught) A next generation functional programming language. The focus of this project is a synthesis of good ideas from the ML, Haskell, Scheme, and LF communities. In particular, we are designing a language that like ML and Scheme, is primarily call-by-value, but like Haskell, provides good support for laziness. As in Haskell and FX, we are attempting to isolate effects and reflect them in the types. As in Haskell, O'Caml, and LF, we are trying to push the boundaries of type systems and type inference to the next level. Currently, I am working with Amal Ahmed, Mathew Fluet, and Aleks Nanevski on issues involving state and effects. I am also working with Norman Ramsey & Paul Govereau on integrating type-classes with ML-style modules. Concerning merging Haskell and ML, Manuel M T Chakravarty already did some great research : http://www.cse.unsw.edu.au/~chak/papers/mtc.ps.gz For dependent types, we have already : http://www.e-pig.org/ ( lacks dependent I/O ) Moreover, the parallel programming seems to be the future due to the massive multithreading abilities of next-gen processor... : http://en.wikipedia.org/wiki/Rock_processor http://en.wikipedia.org/wiki/CELL Best Regards, Will

1 0

Two things that i still can't understand in Haskell standard
by Bulat Ziganshin 14 Oct '06

14 Oct '06

Hello haskell-prime, first is the monomorphism restriction. why isn't it possible to check _kind_ of parameter-less equation and apply monomorphism restrictions only to values of kind '*'? so, this: sum = foldr1 (*) will become polymorphic because its kind is '*->*' while this exps = 1 : map (2*) exps will become monomorphic because its kind is * second is lack of support for prefix/postfix operations. why it is impossible to do in first pass only lexical analysis of Haskell program, then split it into sentences, extract all import/infix operations and only after processing of these operations, having all the information about operator types and precedence, do the syntax analysis? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

2 1

Re: Monomorphism restriction
by Iavor Diatchki 14 Oct '06

14 Oct '06

Hello, On 10/14/06, Bulat Ziganshin <bulat.ziganshin(a)gmail.com> wrote: > Hello haskell-prime, > > first is the monomorphism restriction. why isn't it possible to check > _kind_ of parameter-less equation and apply monomorphism restrictions > only to values of kind '*'? so, this: > > sum = foldr1 (*) > > will become polymorphic because its kind is '*->*' while this Kinds are use to classify _types_ and not _expressions_. In this case, the expression has the type "a -> a", with the constraint that "a" is a numeric type. This type is of kind *. In general, all the executable parts of a Haskell program have types that are of kind *. The things that have kinds like "* -> *" are type constructors. On the other hand, you might wonder why not use the _type_ of an expression in the monomorphism restriction (MR) and only monomorphize expressions of a non-functional type. The reason this would not work is that the MR is used to avoid repeated evaluation of overloaded expressions when they are instantiated to the same types, but the type of an expression does not tell us if the expression is already evaluated. Remember that in a functional language functions are values like any other, and so we might have to do computation to evaluate them. This is why the MR uses a syntactic heuristic. Having said that, many people find the MR weird because it is kind of implementation specific. Even without the MR, a compiler could perform an optimization that notices that a value is being instantiated with the same dictionary multiple times and avoid the repeated evaluation. The MR is especially weird if we consider the fact that the Haskell report does not even require implementations to have sharing (e.g., call by name semantics are OK), so implementation may duplicate evaluation at will... -Iavor

1 0

three syntax-sugar proposals
by Bulat Ziganshin 14 Oct '06

14 Oct '06

Hello haskell-prime, 1. allow to use '_' in number literals. its used in Ruby and i found that this makes long number literals much more readable. for example maxint = 2_147_483_648 2. allow to use string literals in patterns as head of matched list: optionValue ("kb"++n) = read n * 2^10 optionValue ("mb"++n) = read n * 2^20 this syntax already used in Erlang 3. writing kinds is very rare task, but i still don't like to count number of stars in something like '* -> * -> * -> *'. i think that representing this as '****' will be more readable -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 0

Pattern matching order for records
by Ian Lynagh 13 Oct '06

13 Oct '06

Hi all, Has clarifying the pattern matching order for records as described in http://hackage.haskell.org/trac/ghc/ticket/246 been discussed for haskell'? I couldn't see it on the proposals list. Personally I actually think hugs is doing the right thing according to the report and that there is no real ambiguity in the report's language, just a bit of unclarity. Furthermore, I think hugs' interpretation means that it is easier for the programmer to understand how his program will behave if he only has to look at the pattern to be matched, and not refer back to the definition of the record, even if this does make for slightly more desugaring work for the implementor. Thus I would propose just clarifying the language for Haskell'. Thanks Ian

2 2

Re[2]: Stand-alone deriving declarations added
by Bulat Ziganshin 10 Oct '06

10 Oct '06

Hello Simon, Friday, October 6, 2006, 11:41:21 AM, you wrote: > | declarations. The basic reason for maintaining a syntactic > | distinction between instance declarations and deriving declarations > | is to make the programmer aware of the restrictions of the deriving > | mechanism. unfortunately i don't see this whole message. but i disagree with this statement - imho, using several different mechanisms for deriving built-in classes, defining default instances, automatic generation of instances by TH, generic class definitions and automatic deriving for newtypes just confuse programmers and force to change code when one mechanism is replaced with another (say, when Typeable becomes built-in class instead of TH-generated one). so, i propose to leave only two forms of automatic instance definitions: - bundled with type definition: 'data ... deriving' clause - decoupled from type definition: 'instance Class Type' clause both forms should be allowed to be used with any class that may be automatically derived: 1) built-in classes Eq, Ord... 2) any class derived for newtype 3) class that has default definitions for all its methods: class (Enum a) => SuperEnum a where fromSuperEnum :: a -> Integer fromSuperEnum = toInteger . fromEnum 4) class that was defined using generics (currently GHC-only but i hope that future Haskell standards will support some form of Generic Haskell): class Generic a where f :: a -> a f (x :+: y) = ... f (x :*: y) = ... 5) i propose to extend GHC to allow TH generate default instance declarations. when one tries to derive XXX class, compiler should look up derivingXXX TH function and if it is defined, use this function to derive instance. so, the following: data A = B | C deriving(Binary) should be translated into data A = B | C $(derivingBinary 'A) Haskell is known as polymorphic language, but not generic one. It still lacks simple and powerful mechanism to generate class instances. Why i can't solve this problem completely, i hope that proposed extension may build some bridge to generic Haskell future, allowing at least GHC users to imagine that they work with compiler supporting user-controlled deriving mechanism imagine, for example, that you wrote serialization library with a Binary class. in first version, you have defined default Binary instance using generic classes: class Binary a where put (x :+: y) = ... put (x :*: y) = ... in the next version you have developed much more complex but efficient TH-based instance generation code: derivingBinary t = [| .... |] in third version, GHC comes with built-in Binary class support. and in the fourth version GHC includes Generic Haskell support so you can define default instance using GH. but independent of all these internal changes your clients continue to use the same deriving mechanism: data A = B | C deriving(Binary) is it not beautiful? :) | b) For deriving declarations, the compiler figures out the | constraints, whereas the programmer writes them for instance | declarations. it's real problem. in light of this i propose to extend 'deriving' mechanism so that it can derive in all the above-mentioned ways. plus, as Simon suggests, make the stand-alone 'deriving' clause the same syntax as 'instance' without constraints: data A = B | C deriving(Binary) data T a = T a deriving Binary (T a) where Binary deriving mechanism should by itself generate/check all necessary constraints -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 0