5 ms·

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

145 points by dons 14y ago

dons 14y ago
Much discussion here: http://www.reddit.com/r/haskell/comments/zgeen/ghc_761_officially_released/ 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 14y 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?
  - tmhedberg 14y ago
    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? 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.
    - fusiongyro 14y ago
      My experience has been the same. I think this is why the various proposals have mostly faltered; it's not a big enough pain point in practice.
    - evmar 14y ago
      In my experience it was a perpetual pain point. Do you namespace all your field names with a common prefix based on the outer type name? Or do you just get lucky and not have the names collide?
      - hesselink 14y ago
        In the past most people prefixed their field names with the type name. Nowadays, the most common thing is to put types in their own module, and use the module system to sort out any conflict. Qualified imports can add a prefix, but you can also import parts unqualified, or hide one problematic field.
        mifrai 14y ago
        While I prefer the module solution, it's not always possible when you have mutually recursive record definitions. Well, technically it is possible - but it's very unpleasant [1]. [1] http://www.haskell.org/ghc/docs/latest/html/users_guide/separate-compilation.html#mutual-recursion http://www.haskell.org/ghc/docs/latest/html/users_guide/sepa...
    - papsosouid 14y ago
      I've had quite the opposite experience. Every programmer I've convinced to try haskell has had problems with records. It is incredibly limiting when coming from any language that has objects or structs. Having to prepend every single name in every single record with the information that is already in that record's name is horribly ugly. I think there is no progress made because nobody can decide on a perfect solution, so all the good enough solutions sit and rot.
      - 14y ago
  - ocharles 14y 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.
  - JoshTriplett 14y 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.
    - TylerE 14y ago
      Ok, as someone with just a little bit of Haskell/FP exposure, that sounds cool...I think... but...English?
      - andolanra 14y ago
        Haskell already has the capability to write type-level representations of numbers, so we can have types like zipVec :: Vector a n -> Vector b n -> Vector (a, b) n where Vector a b is the type of a vector of elements of type a that is of length n. The above function will therefore only zip together two vectors if they have the same length; otherwise it's a compile-time error. Right now, people usually roll their own representations of numbers, but this new extension means not only do we have a standard one, we can now write something like myBuffer :: Buffer Int 256 where 256 is a type-level number. With type-level symbols, we could do something like data StringWrapper (a :: Symbol) = S String getUserData :: IO (StringWrapper "unsanitized") writeToDB :: StringWrapper "sanitized" -> IO () sanitize :: StringWrapper "unsanitized" -> StringWrapper "sanitized" stringLength :: StringWrapper a -> Int so that writing code like do x <- getUserData putStrLn ("Length is " ++ show (stringLength x)) writeToDb x -- forgetting to sanitize produces a compile-time error because the types don't match up.
        TylerE 14y ago
        Ahh! Makes sense now. Thanks.
        ocharles 14y ago
- igouy 14y ago
  Problem with x64 fannkuch-redux -- but no problem with x86? http://shootout.alioth.debian.org/u64q/program.php?test=fannkuchredux&lang=ghc&id=3#log http://shootout.alioth.debian.org/u64q/program.php?test=fann... http://shootout.alioth.debian.org/u32q/program.php?test=fannkuchredux&lang=ghc&id=3#log http://shootout.alioth.debian.org/u32q/program.php?test=fann...
tmhedberg 14y 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 14y ago
  `if` is not a function. http://www.haskell.org/haskellwiki/If-then-else#Replace_syntactic_sugar_by_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/html/Control-Conditional.html http://hackage.haskell.org/packages/archive/cond/0.4.0.1/doc...
  - tmhedberg 14y ago
    Did I suggest that it was a function? If so, I didn't intend to.
    - Evbn 14y ago
      'If' is not quite analogous to cond, and 'if' is a bit of a hack, and multiway is more hack on top, is all I wanted to highlight. And the cond you wanted has already been here for you.
dbaupp 14y 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/syntax-extns.html#lambda-case http://www.haskell.org/ghc/docs/7.6.1/html/users_guide/synta... [2] http://hackage.haskell.org/trac/ghc/wiki/LambdasVsPatternMatching http://hackage.haskell.org/trac/ghc/wiki/LambdasVsPatternMat...
- aristidb 14y ago
  You can still do \a b -> case (a,b) of ...
  - thesz 14y ago
    And, perhaps, use uncurry $ \case ...
- emillon 14y 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.
- JoshTriplett 14y 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 http://hackage.haskell.org/trac/ghc/ticket/4359 and https://unknownparallel.wordpress.com/2012/07/09/the-long-and-epic-journey-of-lambdacase-2/ 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.

145 points by dons 14y ago

dons 14y ago

Much discussion here: http://www.reddit.com/r/haskell/comments/zgeen/ghc_761_officially_released/ 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 14y 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?
- tmhedberg 14y ago
  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? 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.
  - fusiongyro 14y ago
    My experience has been the same. I think this is why the various proposals have mostly faltered; it's not a big enough pain point in practice.
  - evmar 14y ago
    In my experience it was a perpetual pain point. Do you namespace all your field names with a common prefix based on the outer type name? Or do you just get lucky and not have the names collide?
    - hesselink 14y ago
      In the past most people prefixed their field names with the type name. Nowadays, the most common thing is to put types in their own module, and use the module system to sort out any conflict. Qualified imports can add a prefix, but you can also import parts unqualified, or hide one problematic field.
      - mifrai 14y ago
        While I prefer the module solution, it's not always possible when you have mutually recursive record definitions. Well, technically it is possible - but it's very unpleasant [1]. [1] http://www.haskell.org/ghc/docs/latest/html/users_guide/separate-compilation.html#mutual-recursion http://www.haskell.org/ghc/docs/latest/html/users_guide/sepa...
  - papsosouid 14y ago
    I've had quite the opposite experience. Every programmer I've convinced to try haskell has had problems with records. It is incredibly limiting when coming from any language that has objects or structs. Having to prepend every single name in every single record with the information that is already in that record's name is horribly ugly. I think there is no progress made because nobody can decide on a perfect solution, so all the good enough solutions sit and rot.
    - 14y ago
- ocharles 14y 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.
- JoshTriplett 14y 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.
  - TylerE 14y ago
    Ok, as someone with just a little bit of Haskell/FP exposure, that sounds cool...I think... but...English?
    - andolanra 14y ago
      Haskell already has the capability to write type-level representations of numbers, so we can have types like zipVec :: Vector a n -> Vector b n -> Vector (a, b) n where Vector a b is the type of a vector of elements of type a that is of length n. The above function will therefore only zip together two vectors if they have the same length; otherwise it's a compile-time error. Right now, people usually roll their own representations of numbers, but this new extension means not only do we have a standard one, we can now write something like myBuffer :: Buffer Int 256 where 256 is a type-level number. With type-level symbols, we could do something like data StringWrapper (a :: Symbol) = S String getUserData :: IO (StringWrapper "unsanitized") writeToDB :: StringWrapper "sanitized" -> IO () sanitize :: StringWrapper "unsanitized" -> StringWrapper "sanitized" stringLength :: StringWrapper a -> Int so that writing code like do x <- getUserData putStrLn ("Length is " ++ show (stringLength x)) writeToDb x -- forgetting to sanitize produces a compile-time error because the types don't match up.
      - TylerE 14y ago
        Ahh! Makes sense now. Thanks.
      - ocharles 14y ago
igouy 14y ago
Problem with x64 fannkuch-redux -- but no problem with x86? http://shootout.alioth.debian.org/u64q/program.php?test=fannkuchredux&lang=ghc&id=3#log http://shootout.alioth.debian.org/u64q/program.php?test=fann... http://shootout.alioth.debian.org/u32q/program.php?test=fannkuchredux&lang=ghc&id=3#log http://shootout.alioth.debian.org/u32q/program.php?test=fann...

tmhedberg 14y 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 14y ago
`if` is not a function. http://www.haskell.org/haskellwiki/If-then-else#Replace_syntactic_sugar_by_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/html/Control-Conditional.html http://hackage.haskell.org/packages/archive/cond/0.4.0.1/doc...
- tmhedberg 14y ago
  Did I suggest that it was a function? If so, I didn't intend to.
  - Evbn 14y ago
    'If' is not quite analogous to cond, and 'if' is a bit of a hack, and multiway is more hack on top, is all I wanted to highlight. And the cond you wanted has already been here for you.

dbaupp 14y 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/syntax-extns.html#lambda-case http://www.haskell.org/ghc/docs/7.6.1/html/users_guide/synta... [2] http://hackage.haskell.org/trac/ghc/wiki/LambdasVsPatternMatching http://hackage.haskell.org/trac/ghc/wiki/LambdasVsPatternMat...

aristidb 14y ago
You can still do \a b -> case (a,b) of ...
- thesz 14y ago
  And, perhaps, use uncurry $ \case ...
emillon 14y 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.
JoshTriplett 14y 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 http://hackage.haskell.org/trac/ghc/ticket/4359 and https://unknownparallel.wordpress.com/2012/07/09/the-long-and-epic-journey-of-lambdacase-2/ 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.