Re: [Haskell-cafe] GSoC proposal: Units for GHC
2012/4/4 Richard Eisenberg : > - A first crack at units in Haskell has already been done (by Bjorn > Buckwalter) and made public at http://code.google.com/p/dimensional/ > This implementation uses functional dependencies heavily and is restricted > to only a specific 7 units. I am a happy user of the type family variant of the dimensional package [1]. It can represent all possible dimensions in the type system by encoding them as powers of 7 base dimensions. It supports all SI units and a few non-SI units. One of the limitations of this approach is that you can not make a distinction between absolute and relative units (degree Celsius vs Kelvin). I found the wikipedia page on dimensional analysis [2] to present a good overview of the problem space. I share Gregory Collins' question on how your work would differ from the dimensional package, or what it would add. 1 - https://github.com/bjornbm/dimensional-tf 2 - http://en.wikipedia.org/wiki/Dimensional_analysis ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Kind error in GHC-7.4.1, works in GHC-7.2.2
Thank you for the explanation. I now understand the problem. I have rewritten the code using some parenthesis. Thanks, Roel 2012/2/10 Simon Peyton-Jones : > It should not have worked before. Consider > > I# $ 3# > > ($) is a polymorphic function and takes two *pointer* arguments. If we > actually called it with I# and 3# as arguments we might seg-fault when we > call the GC when allocating the box. > > Polymorphic type variables (in this case in the type of ($)) can only be > instantiated with boxed types. > > Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Kind error in GHC-7.4.1, works in GHC-7.2.2
Hello,
I have some code that compiled fine in GHC-7.2.2 but fails in
GHC-7.4.1 with a kind error.
{-# LANGUAGE MagicHash, NoImplicitPrelude, PackageImports #-}
import "base" Data.Function ( ($) )
import "base" GHC.Exts ( Int(I#) )
import "base" Prelude ( Integral, fromIntegral, toInteger )
import "integer-gmp" GHC.Integer.Logarithms ( integerLogBase# )
intLog :: (Integral a) => a -> a
intLog x = fromIntegral $ I# $ integerLogBase# 10 (toInteger x)
This results in the following error:
Couldn't match kind `#' against `*'
In the second argument of `($)', namely
`I# $ integerLogBase# 10 (toInteger x)'
In the expression:
fromIntegral $ I# $ integerLogBase# 10 (toInteger x)
In an equation for `intLog':
intLog x = fromIntegral $ I# $ integerLogBase# 10 (toInteger x)
Simply eliminating some $'s using parenthesis solves the problem:
intLog x = fromIntegral $ I# (integerLogBase# 10 (toInteger x))
Why do I get the above kind error? Could it be a bug in GHC?
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Unicode alternative for '..' (ticket #3894)
On Wed, Apr 21, 2010 at 12:51 AM, Yitzchak Gale wrote: > Yes, sorry. Either use TWO DOT LEADER, or remove > this Unicode alternative altogether > (i.e. leave it the way it is *without* the UnicodeSyntax extension). > > I'm happy with either of those. I just don't like moving the dots > up to the middle, or changing the number of dots. I would be happy with either changing the character to the baseline ellipsis or removing it altogether. It would be nice if we could grep (or emacs grep-find) all sources on Hackage to check which packages use the ⋯ character. I suspect it is very close to 0. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Unicode alternative for '..' (ticket #3894)
That is very interesting. I didn't know the history of those characters. > If we can't find a Unicode character that everyone agrees upon, > I also don't see any problem with leaving it as two FULL STOP > characters. I agree. I don't like the current Unicode variant for "..", therefore I suggested an alternative. But I didn't consider removing it altogether. It is an interesting idea. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Unicode alternative for '..' (ticket #3894)
I'm a big fan of the UnicodeSyntax [1] language extension. But I don't particularly like the alternative for the ellipsis '..'. I'm not sure if it was a conscious choice or a mistake to use the '⋯' character. I haven't really encountered that symbol before except for matrices and the like [2]. Therefore I propose to change the character from '⋯' to '…'. I submitted a bug report for this a few weeks ago [3]. Today I attached a patch which implements this change. Here are 4 code snippets for comparison: -- Simple ASCII import Data.Bool ( Bool(..) ) f :: [Int] f = [1, 3 .. 10] ++ [10..100] -- Current situation (MIDLINE HORIZONTAL ELLIPSIS, U+22EF) import Data.Bool ( Bool(⋯) ) f ∷ [Int] f = [1, 3 ⋯ 10] ++ [10⋯100] -- Proposed change (HORIZONTAL ELLIPSIS, U+2026) import Data.Bool ( Bool(…) ) f ∷ [Int] f = [1, 3 … 10] ++ [10…100] -- Another alternative (TWO DOT LEADER, U+2025) import Data.Bool ( Bool(‥) ) f ∷ [Int] f = [1, 3 ‥ 10] ++ [10‥100] The TWO DOT LEADER also looks nice, but I think we must consider more than looks alone (which is a matter of fonts) and take the semantics into account. I would really like some feedback on this since it is a change that breaks backwards compatibility (even though it is a really small change). Regards, Roel van Dijk 1 - http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#unicode-syntax 2 - http://en.wikipedia.org/wiki/Ellipsis#In_mathematical_notation 3 - http://hackage.haskell.org/trac/ghc/ticket/3894 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
