GHC 7.6 is now live: poly kinds, dynamic use of cores, numeric type literals...

http://www.haskell.org/ghc/docs/7.6.1/html/users_guide/release-7-6-1.html?7.6.1

by dons • 14 years ago

145 26 14 years ago

haskell.org

dons• 14 years ago

Much discussion here: http://www.reddit.com/r/haskell/comments/zgeen/ghc_761_offic...

Highlights:

* RTS now supports changing the number of capabilities at runtime

* Dataflow based code gen is on

* Unboxed tuples (register allocated structs) are now first class

* Multi-way if syntax

* Lambda case syntax

* Type level naturals and strings

sixbrx• 14 years ago

I've been away from Haskell for a while, it's great to see interesting things still being done. Wondering what the use of type-level naturals in Haskell is though? I dabbled with Agda a bit where they're used to satisfy the termination checker, is that sort of thing being done in Haskell now?

Also one thing that always gave me pause about Haskell was the record system, and the inability to have fields with the same name in the same module (especially when the fields are generated from a database). Has there been any progress on that front?

tmhedberg4• 14 years ago

There have been a zillion proposals, but as far as I know, not much actual consensus or implementation work.

Anecdotally, I've never run into a situation where this was anything more than a minor annoyance. I don't doubt that it can be a problem under the right set of circumstances, but I think the issue gets more attention than its magnitude truly merits. People theorize a lot about the difficulties it can hypothetically cause, but in practice, it seldom actually manifests itself.

ocharles2• 14 years ago

Type-level naturals let you express things like "map on a Vector of length n will produce a Vector of length n" and "given an element x and a vector xs of length n, cons x xs will produce a Vector of length (n + 1)". Other functions can inspect these nats and prevent you from taking the head of an empty list, as a very basic example.

JoshTriplett2• 14 years ago

Quite a few packages on Hackage use type-level naturals, hand-implemented using mechanisms like a type-level zero and a type-level successor function (and often a type-level "times 2" function to avoid the huge inefficiency of a unary representation). Building type-level naturals into GHC will allow all of those packages to become much cleaner and saner.

Type-level strings (AKA Symbols) also allow very impressive constructs, such as type-safe extensible records using type-level strings as keys.

igouy• 14 years ago

Problem with x64 fannkuch-redux -- but no problem with x86?

http://shootout.alioth.debian.org/u64q/program.php?test=fann...

http://shootout.alioth.debian.org/u32q/program.php?test=fann...

tmhedberg4• 14 years ago

Every new GHC release is like a little Christmas morning! The pace of new feature development impresses me.

I'm particularly interested in the new type-level literals (which seem like they will make it much less cumbersome to express certain static constraints) and the convenient new syntax for multi-way if expressions (I've long wanted Lisp's `cond` in Haskell) and case analysis on lambda arguments.

sadga• 14 years ago

`if` is not a function. http://www.haskell.org/haskellwiki/If-then-else#Replace_synt...

Functional `if` and `cond` are here: http://hackage.haskell.org/packages/archive/cond/0.4.0.1/doc...

tmhedberg4• 14 years ago

Did I suggest that it was a function? If so, I didn't intend to.

dbaupp• 14 years ago

Does anyone know how multiple arguments work with lambda-case[1]? Is the solution just using a tuple and manually currying like so (suggested here[2])?

   curry (\case (Nothing,_) -> ...)

(It seems like this would defeat the purpose of lambda-case for lambdas with more than 2 arguments, and it is awkward even for those with exactly 2 arguments.)

[1] http://www.haskell.org/ghc/docs/7.6.1/html/users_guide/synta... [2] http://hackage.haskell.org/trac/ghc/wiki/LambdasVsPatternMat...

aristidb• 14 years ago

You can still do \a b -> case (a,b) of ...

thesz• 14 years ago

And, perhaps, use uncurry $ \case ...

emillon• 14 years ago

The equivalent construct in OCaml is "function", and it suffers from the same limitation, and it's quite idiomatic to match on a tuple.

JoshTriplett2• 14 years ago

Yes, LambdaCase only supports one argument. That covers the most common cases, such as foo >>= \case ...

See the discussions at http://hackage.haskell.org/trac/ghc/ticket/4359 and https://unknownparallel.wordpress.com/2012/07/09/the-long-an... for the history of this.

Multi-argument lambda case proves quite difficult to handle sanely, because normal non-lambda case doesn't do multiple arguments, just tuples. Having multiple arguments requires separating the pattern for each argument somehow, a problem that doesn't come up for non-lambda cases.

GHC 7.6 is now live: poly kinds, dynamic use of cores, numeric type literals...

Related Stories