- Haskell-Cafe - Haskell.org

Index for local documentation is incomplete
by Francesco Ariis 30 Mar '15

30 Mar '15

Dear Haskellers, I have a problem with local haddock documentation. Specifically, the documentation gets built but the index.html is not updated. As an example, here is the bottom part of the log of a package I installed a few days ago: > Haddock coverage: > 100% ( 6 / 6) in 'System.FilePath.Manip' > 100% ( 7 / 7) in 'System.FilePath.GlobPattern' > 100% ( 2 / 2) in 'System.FilePath.Glob' > 65% ( 41 / 63) in 'System.FilePath.Find' > Documentation created: dist/doc/html/filemanip/index.html > Creating package registration file: /tmp/pkgConf-filemanip-0.3.66815.3 > Installing library in > /home/user/.cabal/lib/i386-linux-ghc-7.8.3/filemanip-0.3.6.3 > Registering filemanip-0.3.6.3... The documentation files are present in ~/.cabal/share/doc/i386-linux-ghc-7.8.3/filemanip-0.3.6.3/html/index.html but when if I open `~/.cabal/share/doc/index.html`, there is no `System.FilePath.Find` module. cabal version is 1.22.0.0, GHC 7.8.3 Any idea on how to diagnose this?

1 1

Terra language: Lua+LLVM JIT+multi-stage metaprogramming
by oleg＠okmij.org 30 Mar '15

30 Mar '15

Bulat Ziganshin wrote: > It has predecessors like template haskell, metalua, julia, ocamlp4, > but all them lack either convenient multi-stage meta-programming, or > efficency of low-level code You have omitted MetaOCaml. One may argue about the convenience of MetaOCaml but one has to acknowledge that it is the typed and hygienic staged language. (The TExp subset of the new TH is typed and hygienic, but it does not permit any effects in the generator, which are often necessary). As to low level, it turns out relatively straightforward to interface MetaOCaml with LLVM, so that OCaml becomes a very powerful, typed and hygienic ``macro language'' for LLVM.

1 0

RFC: rewrite-with-location proposal
by Michael Snoyman 30 Mar '15

30 Mar '15

Quite a while back, Simon Hengel and I put together a proposal[1] for a new feature in GHC. The basic idea is pretty simple: provide a new pragma that could be used like so: error :: String -> a errorLoc :: IO Location -> String -> a {-# REWRITE_WITH_LOCATION error errorLoc #-} Then all usages of `error` would be converted into calls to `errorLoc` by the compiler, passing in the location information of where the call originated from. Our three intended use cases are: * Locations for failing test cases in a test framework * Locations for log messages * assert/error/undefined Note that the current behavior of the assert function[2] already includes this kind of approach, but it is a special case hard-coded into the compiler. This proposal essentially generalizes that behavior and makes it available for all functions, whether included with GHC or user-defined. The proposal spells out some details of this approach, and contrasts with other methods being used today for the same purpose, such as TH and CPP. Michael [1] https://github.com/sol/rewrite-with-location [2] http://hackage.haskell.org/packages/archive/base/4.6.0.1/doc/html/Control-E…

14 32

ANN: unification-fd 0.10.0
by wren romano 30 Mar '15

30 Mar '15

-------------------------------------------- -- unification-fd 0.10.0 -------------------------------------------- The unification-fd package offers generic functions for single-sorted first-order structural unification (think of programming in Prolog, or of the metavariables in type inference)[1][2]. The library *is* sufficient for implementing higher-rank type systems a la [Peyton Jones, Vytiniotis, Weirich, Shields], but bear in mind that unification variables are the metavariables of type inference--- not the type-variables. As of this version, the library is also sufficient for implementing (non-recursive) feature structure unification. An effort has been made to make the package as portable as possible. However, because it uses the ST monad and the mtl-2 package it can't be H98 nor H2010. However, it only uses the following common extensions which should be well supported[3]: Rank2Types MultiParamTypeClasses FunctionalDependencies -- Alas, necessary for type inference FlexibleContexts -- Necessary for practical use of MPTCs FlexibleInstances -- Necessary for practical use of MPTCs UndecidableInstances -- For Show instances due to two-level types -------------------------------------------- -- Changes since 0.8.0 (2012-07-11) -------------------------------------------- * (0.8.1) Added Functor, Foldable, and Traversable instances for COntrol.Unification.Types.UnificationFailure. Thanks Graham Rogers. * (0.9.0) Changed the fundeps on BindingMonad and RankedBindingMonad so that things compule under GHC 7.8.2 * (0.9.0) eta-expanded the rewrite rules in Data.Functor.Fixedpoint so that GHC 7.8 no longer gives warnings about not firing due to (.) possibly being inlined first * Cleaned things up to compile cleanly for GHC 7.10 * For EitherK and MaybeK, liberalized the instances to only require Applicative instead of Monad wherever possible. * Completely revamped the old UnificationFailure data type as the new UFailure data type and Fallible type class. This was necessary to clean up some deprecation warnings about using Control.Monad.Error, to remove the hack of needing an UnknownError constructor, and to make the data type for representing failures more extensible. -------------------------------------------- -- Description -------------------------------------------- The unification API is generic in the type of the structures being unified and in the implementation of unification variables, following the two-level types pearl of Sheard (2001). This style mixes well with Swierstra (2008), though an implementation of the latter is not included in this package. That is, all you have to do is define the functor whose fixed-point is the recursive type you're interested in: -- The non-recursive structure of terms data S a = ... -- The recursive term type type Term = Fix S And then provide an instance for Unifiable, where zipMatch performs one level of equality testing for terms and returns the one-level spine filled with pairs of subterms to be recursively checked, or Nothing if this level doesn't match. Each subterm can be separately marked as being resolved, Left xy, or as requiring further unification, Right(x,y). class (Traversable t) => Unifiable t where zipMatch :: t a -> t a -> Maybe (t (Either a (a, a))) The choice of which variable implementation to use is defined by similarly simple classes Variable and BindingMonad. We store the variable bindings in a monad, for obvious reasons. In case it's not obvious, see Dijkstra et al. (2008) for benchmarks demonstrating the cost of naively applying bindings eagerly. There are currently two implementations of variables provided: one based on STRefs, and another based on a state monad carrying an IntMap. The former has the benefit of O(1) access time, but the latter is plenty fast and has the benefit of supporting backtracking. Backtracking itself is provided by the logict package and is described in Kiselyov et al. (2005). In addition to this modularity, unification-fd implements a number of optimizations over the algorithm presented in Sheard (2001)--- which is also the algorithm presented in Cardelli (1987). * Their implementation uses path compression, which we retain. Though we modify the compression algorithm in order to make sharing observable. * In addition, we perform aggressive opportunistic observable sharing, a potentially novel method of introducing even more sharing than is provided by the monadic bindings. Basically, we make it so that we can use the observable sharing provided by the modified path compression as much as possible (without introducing any new variables). * And we remove the notoriously expensive occurs-check, replacing it with visited-sets (which detect cyclic terms more lazily and without the asymptotic overhead of the occurs-check). A variant of unification which retains the occurs-check is also provided, in case you really need to fail fast. * Finally, a highly experimental branch of the API performs *weighted* path compression, which is asymptotically optimal. Unfortunately, the current implementation is quite a bit uglier than the unweighted version, and I haven't had a chance to perform benchmarks to see how the constant factors compare. Hence moving it to an experimental branch. These optimizations pass a test suite for detecting obvious errors. If you find any bugs, do be sure to let me know. Also, if you happen to have a test suite or benchmark suite for unification on hand, I'd love to get a copy. -------------------------------------------- -- Notes and limitations -------------------------------------------- [1] At present the library does not appear amenable for implementing higher-rank unification itself; i.e., for higher-ranked metavariables, or higher-ranked logic programming. To be fully general we'd have to abstract over which structural positions are co/contravariant, whether the unification variables should be predicative or impredicative, as well as the isomorphisms of moving quantifiers around. It's on my todo list, but it's certainly non-trivial. If you have any suggestions, feel free to contact me. [2] At present it is only suitable for single-sorted (aka untyped) unification, a la Prolog. In the future I aim to support multi-sorted (aka typed) unification, however doing so is complicated by the fact that it can lead to the loss of MGUs; so it will likely be offered as an alternative to the single-sorted variant, similar to how the weighted path-compression is currently offered as an alternative. [3] With the exception of fundeps which are notoriously difficult to implement. However, they are supported by Hugs and GHC 6.6, so I don't feel bad about requiring them. Once the API stabilizes a bit more I plan to release a unification-tf package which uses type families instead, for those who feel type families are easier to implement or use. There have been a couple requests for unification-tf, so I've bumped it up on my todo list. -------------------------------------------- -- References -------------------------------------------- Luca Cardelli (1987) /Basic polymorphic typechecking/. Science of Computer Programming, 8(2):147--172. Atze Dijkstra, Arie Middelkoop, S. Doaitse Swierstra (2008) /Efficient Functional Unification and Substitution/, Technical Report UU-CS-2008-027, Utrecht University. <http://www.cs.uu.nl/research/techreps/repo/CS-2008/2008-027.pdf> Simon Peyton Jones, Dimitrios Vytiniotis, Stephanie Weirich, Mark Shields /Practical type inference for arbitrary-rank types/, to appear in the Journal of Functional Programming. (Draft of 31 July 2007.) Oleg Kiselyov, Chung-chieh Shan, Daniel P. Friedman, and Amr Sabry (2005) /Backtracking, Interleaving, and/ /Terminating Monad Transformers/, ICFP. <http://www.cs.rutgers.edu/~ccshan/logicprog/LogicT-icfp2005.pdf> Tim Sheard (2001) /Generic Unification via Two-Level Types/ /and Paramterized Modules/, Functional Pearl, ICFP. <http://web.cecs.pdx.edu/~sheard/papers/generic.ps> Tim Sheard & Emir Pasalic (2004) /Two-Level Types and/ /Parameterized Modules/. JFP 14(5): 547--587. This is an expanded version of Sheard (2001) with new examples. <http://web.cecs.pdx.edu/~sheard/papers/JfpPearl.ps> Wouter Swierstra (2008) /Data types a la carte/, Functional Pearl. JFP 18: 423--436. <http://www.cs.ru.nl/~wouters/Publications/DataTypesALaCarte.pdf> -------------------------------------------- -- Links -------------------------------------------- Homepage: http://code.haskell.org/~wren/ Hackage: http://hackage.haskell.org/package/unification-fd Darcs: http://community.haskell.org/~wren/unification-fd Haddock (Darcs version): http://community.haskell.org/~wren/unification-fd/dist/doc/html/unification… -- Live well, ~wren

1 0

ANN: stm-chans 3.0.0.3
by wren romano 30 Mar '15

30 Mar '15

-------------------------------------------- -- stm-chans 3.0.0.3 -------------------------------------------- The stm-chans package offers a collection of channel types, similar to Control.Concurrent.STM.{TChan,TQueue} but with additional features. -------------------------------------------- -- Changes since 3.0.0 (2013-05-29) -------------------------------------------- Cleaned up the header gunk to compile cleanly under GHC 7.10. No actual code has been altered. -------------------------------------------- -- Long description -------------------------------------------- In particular stm-chans offers the following data types: * Control.Concurrent.STM.TBChan: Bounded FIFO channels. When the channel is full, writers will block/retry. This ensures that the writers do not get too far ahead of the readers, which helps to make sure that memory and cpu resources are used responsibly. * Control.Concurrent.STM.TMChan: Closeable FIFO channels. * Control.Concurrent.STM.TMQueue: Closeable FIFO queues. Like TChan (Maybe a) but with a monotonicity guarantee that once Nothing is returned all future reads will be Nothing as well. * Control.Concurrent.STM.TBMChan: Bounded Closeable FIFO channels. * Control.Concurrent.STM.TBMQueue: Bounded Closeable FIFO queues. Combines the capabilities of TBChan and TMChan. -------------------------------------------- -- Links -------------------------------------------- Homepage: http://code.haskell.org/~wren/ Hackage: http://hackage.haskell.org/package/stm-chans Darcs: http://community.haskell.org/~wren/stm-chans Haddock (Darcs version): http://community.haskell.org/~wren/stm-chans/dist/doc/html/stm-chans -- Live well, ~wren

1 0

ANN: logfloat 0.13.3
by wren romano 30 Mar '15

30 Mar '15

-------------------------------------------- -- logfloat 0.13.3 -------------------------------------------- This package provides a type for storing numbers in the log-domain, primarily useful for preventing underflow when multiplying many probabilities as in HMMs and other probabilistic models. The package also provides modules for dealing with floating numbers correctly. This version drops support for Hugs and GHC < 7.8. Nothing major has changed, so they should still work; it's just that they're no longer officially supported. Thus, this version of the library provides a transitional point between backwards compatability and adding new features (see below). -------------------------------------------- -- Changes since 0.12.1 (2010-03-19) -------------------------------------------- * Monomorphized logFloat, logToLogFloat, fromLogFloat, and logFromLogFloat: that is, they all take/return Double now. The change was made to help reduce the need for explicit type signatures. It shouldn't really affect most users, since it seems noone was really making use of the polymorphism provided by previous versions. To get the previous behavior back, just explicitly add calls to realToFrac wherever necessary. * Fixed some instances to get them to compile under the new role-based type system of GHC 7.10 * Cleaned up various extraneous rewrite rules, specializations, etc * Added the functions sum, product, and pow. Both sum and product preserve more precision than the fold-based definitions in the Prelude. Moreover, sum is _much_ faster than the Prelude version, since it only requires crossing the log/exp boundary n+1 times, instead of 2*(n-1) times. The only downside is that sum requires two passes over the input and thus is not amenable to list fusion. -------------------------------------------- -- Upcoming changes (0.14+) -------------------------------------------- * Since the Data.Number.RealToFrac module is no longer required by any of the others, it will probably be forked off to a separate package in order to improve portability of the rest of the package by removing the need for MPTCs. * There's long been clamoring for adding a vector:Data.Vector.Unboxed.Unbox instance. I've been reluctant to add such an instance due to wanting to retain backwards compatibility and portability. Having dropped support for Hugs and older versions of GHC, I'm now willing to add them in. The logfloat library is conceptually quite simple, and thus to whatever extent possible I'd still like to retain portability to non-GHC compilers. So if you are interested in using logfloat with another compiler/interpreter but run into problems (e.g., due to the type families required by the vector library), please get in touch and I'll try to get things to work. -------------------------------------------- -- Compatibility / Portability -------------------------------------------- The package is compatible with GHC 7.8.3 and 7.10.1. It may still compile with older versions of GHC (or even Hugs!), however they are no longer officially supported. The package is not compatible with nhc98 and Yhc because Data.Number.RealToFrac uses MPTCs. However, that module is no longer required by any others, and all the other modules should be compatible with these compilers. Thus, it should be fairly easy to port. If you do so, please let me know and I'll try to incorporate support for them. -------------------------------------------- -- Links -------------------------------------------- Homepage: http://code.haskell.org/~wren/ Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/logfloat Darcs: http://code.haskell.org/~wren/logfloat/ Haddock (Darcs version): http://code.haskell.org/~wren/logfloat/dist/doc/html/logfloat/ -- Live well, ~wren

1 0

[announce] pipes-cliff - library for streaming to and from processes with Pipes
by Omari Norman 29 Mar '15

29 Mar '15

Sometimes you have to write Haskell code to interact with external processes. What a bother. The System.Process module makes it easy to send data in and out, but what if you want to stream your data in constant time and space? Then you need to cobble together your own solution using the provided Handles. Or you can use pipes-cliff, which lets you use the excellent Pipes library to stream your data in and out. Some simple examples in the package get you started. https://hackage.haskell.org/package/pipes-cliff Also, take a look at the README.md file, which lists some similar packages. Maybe one of those will work better for you. https://github.com/massysett/pipes-cliff/blob/master/README.md

1 0

OS X builds of GHC 7.8.4, 7.10.1-rc2, and 7.10.1-rc3
by Miëtek Bak 29 Mar '15

29 Mar '15

An OS X build of GHC 7.10.1-rc3 is now available, courtesy of Mark Lentczner. This is in addition to the GHC 7.8.4 and 7.10.1-rc2 builds Mark has made available on February 2. Thanks, Mark. GHC 7.8.4 for OS X can already be downloaded from haskell.org, even though it’s not mentioned on the GHC 7.8.4 webpage: https://downloads.haskell.org/~ghc/7.8.4/ghc-7.8.4-x86_64-apple-darwin.tar.… To avoid running up Mark’s bandwidth bill, I’m omitting the URL to his staging area. I’ve mirrored all three builds in Halcyon public storage: 7.8.4: https://halcyon.global.ssl.fastly.net/original/ghc-7.8.4-x86_64-apple-darwi… 7.10.1-rc2: https://halcyon.global.ssl.fastly.net/original/ghc-7.10.0.20150123-x86_64-a… 7.10.1-rc3: https://halcyon.global.ssl.fastly.net/original/ghc-7.10.0.20150316-x86_64-a… Binary builds of GHC, repackaged with documentation removed, are also available in Halcyon — on OS X 10.10, 10.9, 10.8, and a considerable number of Linux distributions. This includes GHC 7.10.1-rc3, 7.10.1-rc2, 7.8.4, 7.8.3, 7.8.2, 7.6.3, 7.6.1, 7.4.2, 7.2.2, and 7.0.4. Using Halcyon, installing GHC together with cabal-install is expected to take 20-30 seconds: https://halcyon.sh/tutorial/#install-ghc-and-cabal -- Miëtek https://mietek.io

1 1

Information about "definitive-base" prelude replacement
by Clinton Mead 29 Mar '15

29 Mar '15

I've played around a bit with "classy-prelude", but recently I stumbled into "definitive-base", on hackage here - https://hackage.haskell.org/package/definitive-base. The documentation is sparse, but there's some brief information here: https://marc.coiffier.net/projects/definitive-framework.html It looks interesting, but I was wondering if anyone has used it as a replacement prelude, and perhaps written/blogged on it? I'm just looking for a bit of a primer I guess.

2 1

LTS Haskell 2.0: Last call
by Michael Snoyman 29 Mar '15

29 Mar '15

This is the last announcement about the upcoming LTS 2 release, which is schedule for this Wednesday, April 1 (no joke). For those unfamiliar with the process: we will essentially be taking that day's Stackage Nightly and promoting it to LTS 2, and locking down the major versions of all packages in that package set until LTS 3. If you'd like to get any additional packages in, please send your pull requests now[1]. I'd also like to call attention to the current upper bounds issues[2]. If we can get any of these issues resolved before Wednesday, then newer versions of the relevant packages can make it into LTS 2. Otherwise, LTS 2 will continue with the old versions. (Alternatively, we can consider dropping the packages with restrictive upper bounds, if there's demand to do so.) Things worth pointing out: * primitive 0.6 is out, and introduces very minimal breaking changes. If you can get your packages to support the new version (likely with just a cabal file change), that would be great. * criterion 1.1 is out. I may simply disable benchmarks on the relevant users to allow the new version to slip in. * QuickCheck 2.8 would be a nice addition * lens 4.8 is blocked on a number of diagrams-* packages and a few others. I have no idea how complicated the changes are there. * blaze-builder 0.4 is blocked by snap, and unlikely to unblock in time, which likely means we'll have two ByteString Builder variants for this release * wizards depends on an old control-monad-free Thanks for everybody's participation! [1] https://github.com/fpco/stackage#get-your-package-included [2] https://github.com/fpco/stackage/issues?q=is%3Aopen+is%3Aissue+label%3Aboun…

1 0