- Haskell-Cafe - Haskell.org

Please test: Cabal/cabal-install 1.20 RC2
by Johan Tibell 17 Apr '14

17 Apr '14

Hi all, The second, and hopefully last, release candidate for Cabal and cabal-install 1.20 is ready. If no issues are discovered, I plan to release this on Sunday, April 20th. You can help test by installing the release candidate and use it for your day-to-day work: cabal install http://johantibell.com/files/Cabal-1.20.0.0-rc2.tar.gz http://johantibell.com/files/cabal-install-1.20.0.0-rc2.tar.gz Please report any issues at https://github.com/haskell/cabal/issues -- Johan

1 0

Re: [Haskell-cafe] Minimal Haskell Platform
by Travis Cardwell 17 Apr '14

17 Apr '14

On 2014年04月15日 14:02, Simon Hengel wrote: >> It is interesting that cabal does not (try to) install happy as a >> prerequisite for haskell-src-exts, which lists happy as a >> Build-Tools dependency [2]. It is also interesting that `cabal >> install happy` requires itself, despite indication in the >> documentation [3] that it is a valid way to install the package... >> >> Does this indicate that Cabal expects Haskell Platform? > > No, installing build tools is just a missing feature of `cabal-install` > (AFAIK). I chatted with Duncan Coutts in #haskell, and he confirmed that it is indeed just a missing feature. I found the issue here: https://github.com/haskell/cabal/issues/220 I was unable to find an issue regarding the `cabal install happy` failure, so I created one: https://github.com/haskell/cabal/issues/1777 >> Should Cabal be changed to (support minimal installations and) >> manage Build-Tools dependencies? > > Yes. In #haskell, Duncan Coutts said: > as for the global vs. minimal, yes I see it's an issue. One sometimes > wants to start a sandbox with a very minimal set. > > the issue with making a minimal sandbox is simply knowing which > packages should be in it, and we currently just base them all off of > the global one. > > but that's not the only solution, it'd also be possible to copy a > subset, if we know what subset to copy > > and I have a somewhat cunning plan along these lines (related to some > other ghc-pkg/cabal improvement work) which might make that rather > easier > > what I want is for ghc itself to come with multiple profiles, with one > being the minimum (base + rts + deps), and that could be used as a basis > for new envs With such a feature, it sounds like we can get the best of both worlds: * a feature-rich Haskell Platform to support beginners * minimal sandboxes for advanced users > I think most Haskell developers use a reasonably recent version of GHC > (that would currently still be 7.6.3 for me) and the latest version of > cabal-install. Everything else can be installed with cabal-install. In my experience, the alex and happy binaries must also be installed (for a number of packages to be installable via cabal-install). > Where would something like the HP actually make sense? For stuff that > has external dependencies that are not easily installable with > cabal-install (like curses bindings, SSL support, etc.). We have none > of this in the HP. So I think currently we just have additional costs, > but no benefits (+ we harm innovation by arbitrarily "endorsing" random > packages). I understand this point of view, but allow me to offer an opposing one. By putting packages with external dependencies into Haskell Platform, we often increase the dependencies of Haskell Platform itself. For example, Haskell Platform currently includes Graphics packages; installing Haskell Platform on a server entails installing a number of OpenGL libraries that are never used. Cheers, Travis

4 3

Autocomplete command line options with GHC 7.8
by Jan Stolarek 16 Apr '14

16 Apr '14

Hi all, GHC 7.8 adds --show-options flag that prints all supported command line flags on standard output. This can be used to enable autocompletion of command line options for ghc in shells that support autocompletion. If you're using bash add this snippet to your ~/.bashrc file: <<<<<<<<<<<<< START # Autocomplete GHC commands _ghc() { local envs=`ghc --show-options` # get the word currently being completed local cur=${COMP_WORDS[$COMP_CWORD]} # the resulting completions should be put into this array COMPREPLY=( $( compgen -W "$envs" -- $cur ) ) } complete -F _ghc -o default ghc <<<<<<<<<<<< END Enjoy. Janek PS. I also added a wiki page: https://ghc.haskell.org/trac/ghc/wiki/AutocompleteGHCFlags Feel free to add instructions for other shells.

2 3

Re: [Haskell-cafe] Directed rounding in haskell ?
by Barak A. Pearlmutter 16 Apr '14

16 Apr '14

One issue that arises with rounding modes in a pure lazy language like Haskell is that it's pretty hard to nail down the semantics. The "round towards negative infinity" mode is a dynamic hardware feature, available by setting a rounding mode flag in the FPU. If you execute some hunk of code with that flag having different values, you will in general get different results. So if you try to do this in Haskell, you have to decide how to expose it without violating purity. This would break things: roundWith :: RoundMode -> ( () -> a) -> a consider let x = 0.1 + 0.2 in roundWith NegInfty (\_ -> x) vs roundWith NegInfty (\_ -> 0.1 + 0.2) So you need to make different numeric types. This is what Ed Kmett's "rounding" cabal package does, albeit in a much more general way where the new floating types are parameterized by both rounding mode and precision. The bottom line is that IEEE Floating Point numbers are actually a monad. There is NaN, which makes them a Maybe, or given that there are many NaNs perhaps an Either. And there is the rounding mode, which is sort of a Reader. As an aside, changing the rounding mode flags can be surprisingly slow on modern CPUs. One trick for doing interval arithmetic efficiently is to set the flags once, say to TowardInf. Then x*y computes the product of x and y rounding towards positive infinity while -((-x)*y) computes the same product rounding towards negative infinity without fiddling with the rounding mode. So for adding intervals, instead of Interval x0 x1 + Interval y0 y1 = Interval (x0+y0) (x1+y1) Interval x0 x1 * Interval y0 y1 | x0 >= 0 && y0 >= 0 = Interval (x0*y0) (x1*y1) -- etc but with some added hair to fiddle with the rounding modes, one leaves the rounding mode fixed and writes Interval x0 x1 + Interval y0 y1 = Interval (-(-x0-y0)) (x1+y1) Interval x0 x1 * Interval y0 y1 | x0 >= 0 && y0 >= 0 = Interval (-((-x0)*y0)) (x1*y1) -- etc As a final throwaway, allowing (Interval x0 x1) where x0>x1, i.e., improper intervals, gives a very pleasant system with a surprisingly nice and rich semantics. For example, Interval 1 2 - Interval 2 1 = Interval 0 0 which makes for a group rather than just a semigroup. The system is known variously as modal intervals, Kaucher intervals, directed interval arithmetic, or generalized interval arithmetic, and can be used to automatically prove interesting arithmetic properties full of ∀s and ∃s. -- Barak A. Pearlmutter Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland http://www.bcl.hamilton.ie/~barak/

1 0

Current status of Mavericks CPP
by Michael Snoyman 16 Apr '14

16 Apr '14

I still seem to be getting bug reports about the CPP implementation of Mavericks. Last I'd heard, it seemed that general consensus was that packages should *not* be patched to work around the different CPP implementation, and instead Mavericks users should be installing GCC's CPP. Is this accurate? And is there a wiki page somewhere describing the situation and how to work around it? I'd like to have some authoritative URL to point people to, especially given that I have no access to a Mac system and therefore can't test this myself.

14 29

Cabal/cabal-install 1.20 release candidates
by Johan Tibell 16 Apr '14

16 Apr '14

Hi all, I've prepared the Cabal/cabal-install 1.20 release candidates. I now need some help testing, especially on Windows as I don't have a Windows machine. There are over 300 commits since the last release and lots of interesting new features and changes. I will write them down when I make the actual release. To install the release candidates simply run: cabal install --constraint="HTTP >= 4000.2.5" http://johantibell.com/files/Cabal-1.20.0-rc.tar.gz http://johantibell.com/files/cabal-install-1.20.0-rc.tar.gz (The --constraint="HTTP >= 4000.2.5" flag is used to work around an issue I already found in the RC, it won't be needed for the real release.) Please report any issues on the bug tracker: https://github.com/haskell/cabal/issues If I haven't heard of anything release blocking bugs (or last minute important patches) in a couple of days, I will make these tarballs the official release. The commits used are tagged in the repo as Cabal-v1.20.0-rc and cabal-install-v1.20.0-rc. -- Johan

4 5

Minimal Haskell Platform
by Travis Cardwell 16 Apr '14

16 Apr '14

Hello, I have been using Haskell Platform since it was introduced because I have always heard that it is the recommended way to use GHC. Indeed, Haskell Platform has made the installation of a Haskell environment quite straightforward. My current usage strategy is a common one: * Only install Haskell Platform in --global. * Avoid installing into ~/.cabal (when possible). * Develop exclusively in Cabal sandboxes. In a recent /r/haskell post [1], user mightybyte commented: > This. The Haskell Platform installs a bunch of packages for you in > --global. My experience is that this inevitably leads to problems if > you're doing significant Haskell development. The best thing to do is > to minimize the number of packages installed as --global. The way to do > that is to install GHC directly and avoid using the Haskell Platform or > Haskell distributions provided by your OS. Asking about it in #haskell, it seems that a number of developers recommend such a minimal installation, particularly for large projects. I am very interested in minimizing the number of packages in --global, and I would like to start testing my software against the current Haskell Platform *as well as* such a minimal installation. I my initial tests (Debian stable amd64; minimal virtual machine), I tried installing GHC 7.8.2 and cabal-install (using bootstrap.sh) only. Installation went fine, `cabal update` worked fine, and `cabal sandbox init` worked fine. I then tried `cabal install hlint` (within the sandbox), and it successfully compiles a number of packages before failing when trying to build haskell-src-exts, complaining that happy could not be found. Running `cabal install happy` failed with the "setup: The program happy is required but it could not be found" error. Building happy via the source Setup.lhs worked fine, and installing the binary into my installation bin directory results in an environment in which I am able to `cabal install hlint` (and `cabal install happy`) into a sandbox without issue. It is interesting that cabal does not (try to) install happy as a prerequisite for haskell-src-exts, which lists happy as a Build-Tools dependency [2]. It is also interesting that `cabal install happy` requires itself, despite indication in the documentation [3] that it is a valid way to install the package... Does this indicate that Cabal expects Haskell Platform? Should Cabal be changed to (support minimal installations and) manage Build-Tools dependencies? Would it be worthwhile to create a "Minimal Haskell Platform" to create a truly common platform that everybody would be happy using? Cheers, Travis [1] http://www.reddit.com/r/haskell/comments/22up8l/ghc_782_released/ [2] https://github.com/haskell-suite/haskell-src-exts/blob/9bc4daf3b51d006741c6… [3] http://www.haskell.org/happy/

8 12

hsc2hs behaves differently under Windows?
by Dominick Samperi 16 Apr '14

16 Apr '14

It seems that hsc2hs behaves differently under Windows (when compared with Linux), causing build problems. An example foo.hsc is attached, along with the foo.hs that is generated using hsc2hs under Windows. Note the expressions my_$s in the result. It appears that under Windows the %n$s POSIX printf notation is not recognized. The correctly generated file that is produced under Linux is also attached, in foo-linux.hs. Note that proper substitution happens here. Is there a work-around for this Windows issue? Thanks, Dominick

1 1

Re: [Haskell-cafe] [Haskell] [ANN] quantities 0.3.0
by Auke Booij 15 Apr '14

15 Apr '14

On 15 April 2014 20:29, John David Reaver <jdreaver(a)adlerhorst.com> wrote: > Hello! I am happy to publicly announce the quantities package: I think haskell-cafe is more appropriate for these kinds of libraries. Anyway, welcome. > From the description on Hackage: > > A library for creating and manipulating physical quantities, > which are a numerical value associated with a unit of > measurement. Included is an expression parser and a huge list > of predefined quantities with which to parse strings into a > Quantity datatype. Once created, a quantity can be converted > to different units or queried for its dimensionality. A user > can also operate on quantities arithmetically, and doing so > uses automatic unit conversion and simplification. > not sure if "quantities" is an appropriate name for your package: an integer, a float, complex numbers - those are quantities. doesn't this package parse units? > Just to get a taste of how this package works, here are some > examples: why can i only "unsafely" create quantities using strings? what if i know upfront what kind of a unit i want to deal with? from the looks of it, this library is only good for dealing with human-readable input - surely that's not the only use case you had in mind? > >>> fromString "min => s" > Right 60.0 second can't we find some elegant way to express this in haskell, instead of having to invent a scripting language of sorts? On a similar note, your "magnitude :: Quantity -> Double" sounds a bit like unsafeCoerce: why would you want to forget that your quantity has a unit? >From your documentation: > >>> fromString "m => 3 ft" > Left (ScalingFactorError 3.0 foot) Why isn't the outcome of this 3.28084/3=1.09361 or something along those lines? (this is just a suggestion, I'm not saying this is a bad thing.) > >>> fromString "2 ft + 6 in => ft" > Right 2.5 foot Oh, so you are trying to support arbitrary arithmetical input! Then again, there is no way to add two "Quantity"s. I have the feeling the goal of your package is a bit unclear: do you want to implement a framework to type-safely compute with units? Or do you just want to write something that parses string input to typed data? In the former case, have you considered the discussion on the haskellwiki [1]? In the latter case, why don't you write it on top of an existing units package? Well, that was a big rant, I hope you can use some of it. Auke. [1]: http://www.haskell.org/haskellwiki/Physical_units

4 5

Re: [Haskell-cafe] quantities 0.3.0
by Henning Thielemann 15 Apr '14

15 Apr '14

Am 15.04.2014 21:29, schrieb John David Reaver: > Hello! I am happy to publicly announce the quantities package: > > Hackage: http://hackage.haskell.org/package/quantities > Github: https://github.com/jdreaver/quantities > > I feel this package is complete enough as of version > 0.3.0 (released today) to announce it to the public. I have programmed something similar years ago, first for Haskell 98 numeric classes and then for numeric-prelude. My implementation does not use an expression tree for the physical dimensions. Instead it uses a vector of base dimensions and constructs reasonable units only for string output. http://hackage.haskell.org/package/numeric-prelude-0.4.1/docs/Number-SI.html You can play around with it by unpacking the numeric-prelude package and run 'make ghci' thielema@sputnik:/tmp> cabal unpack numeric-prelude Unpacking to numeric-prelude-0.4.1/ thielema@sputnik:/tmp> cd numeric-prelude-0.4.1/ thielema@sputnik:/tmp/numeric-prelude-0.4.1> make ghci ... *Main> 25*meter/second :: SIDouble ... 25.0 m/s *Main> minute/second :: SIDouble 60.0 *Main> ampere*volt :: SIDouble 1.0 W There are many more libraries for handling of physical dimensions: http://www.haskell.org/haskellwiki/Physical_units You may add 'quantities' there.

1 0