August 2013 - Haskell-Cafe

Join a transformer
by Michael Snoyman 11 Apr '18

11 Apr '18

I'm wondering if this pattern exists and has a name. We have the concept of joining a Monad: join :: Monad m => m (m a) -> ma How about joining a monad transformer? joinT :: (Monad m, MonadTrans t) => t (t m) a -> t m a I believe implementing this in terms of MonadTransControl[1] might be possible, but I was wondering if there's an already existing idiom for this. Michael [1] http://haddocks.fpcomplete.com/fp/7.4.2/20130301-40/monad-control/Control-M…

5 5

PatternSignatures (rant)
by Johannes Waldmann 06 Apr '18

06 Apr '18

Dear all, (this is a rant - please ignore) why has "PatternSignatures" been renamed to "ScopedTypeVariables" (in ghc-6.10)? show me the alleged "type variable" in this code: do x :: Int <- [ 1 .. 10 ] ; return $ x^2 and why on earth do I need to use a language extension at all to get to the most basic thing of declarative programming: to declare the type of an identifier? This seriously hurts (me, at least) when teaching Haskell. Thanks - J.W.

4 4

Commutative monads vs Applicative functors
by Ronald Guida 09 Jul '16

09 Jul '16

I have a few questions about commutative monads and applicative functors. >From what I have read about applicative functors, they are weaker than monads because with a monad, I can use the results of a computation to select between alternative future computations and their side effects, whereas with an applicative functor, I can only select between the results of computations, while the structure of those computations and their side effects are fixed in advance. But then there are commutative monads. I'm not exactly sure what a commutative monad is, but my understanding is that in a commutative monad the order of side effects does not matter. This leads me to wonder, are commutative monads still stronger than applicative functors, or are they equivalent? And by the way, what exactly is a commutative monad?

6 6

ANNOUNCE: ioctl 0.0.1
by Maciej Piechotka 13 Sep '15

13 Sep '15

A package for type-safe I/O control. Currently only ioctl is supported. Currently simply a extract from my tuntap fork TODO: - Return the integer as well as structure (will break the API) - Port for Windows Network.Socket.IOCtl (as soon as I manage to setup some sane environment on this platform) - Wrapping around DeviceIoControl Example (in hsc): data NotRead = NotRead instance NotRead Int where ioctlReq _ = #const FIONREAD notRead s = ioctlsocket' s NotRead Regards

2 1

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

Re: [Haskell-cafe] Yet Another Forkable Class
by oleg＠okmij.org 02 Jan '15

02 Jan '15

Perhaps effect libraries (there are several to choose from) could be a better answer to Fork effects than monad transformers. One lesson from the recent research in effects is that we should start thinking what effect we want to achieve rather than which monad transformer to use. Using ReaderT or StateT or something else is an implementation detail. Once we know what effect to achieve we can write a handler, or interpreter, to implement the desired operation on the World, obeying the desired equations. And we are done. For example, with ExtEff library with which I'm more familiar, the Fork effect would take as an argument a computation that cannot throw any requests. That means that the parent has to provide interpreters for all child effects. It becomes trivially to implement: > Another example would be a child that should not be able to throw errors as > opposed to the parent thread. It is possible to specify which errors will be allowed for the child thread (the ones that the parent will be willing to reflect and interpret). The rest of errors will be statically prohibited then. > instance (Protocol p) => Forkable (WebSockets p) (ReaderT (Sink p) IO) where > fork (ReaderT f) = liftIO . forkIO . f =<< getSink This is a good illustration of too much implementation detail. Why do we need to know of (Sink p) as a Reader layer? Would it be clearer to define an Effect of sending to the socket? Computation's type will make it patent the computation is sending to the socket. The parent thread, before forking, has to provide a handler for that effect (and the handler will probably need a socket). Defining a new class for each effect is possible but not needed at all. With monad transformers, a class per effect is meant to hide the ordering of transformer layers in a monad transformer stack. Effect libraries abstract over the implementation details out of the box. Crutches -- extra classes -- are unnecessary. We can start by writing handlers on a case-by-case basis. Generalization, if any, we'll be easier to see. From my experience, generalizing from concrete cases is easier than trying to write a (too) general code at the outset. Way too often, as I read and saw, code that is meant to be reusable ends up hardly usable.

9 12

ordNub
by Niklas Hambüchen 01 Jan '15

01 Jan '15

tldr: nub is abnormally slow, we shouldn't use it, but we do. As you might know, Data.List.nub is O(n²). (*) As you might not know, almost *all* practical Haskell projects use it, and that in places where an Ord instance is given, e.g. happy, Xmonad, ghc-mod, Agda, darcs, QuickCheck, yesod, shake, Cabal, haddock, and 600 more (see https://github.com/nh2/haskell-ordnub) I've taken the Ord-based O(n * log n) implementation from yi using a Set: ordNub :: (Ord a) => [a] -> [a] ordNub l = go empty l where go _ [] = [] go s (x:xs) = if x `member` s then go s xs else x : go (insert x s) xs and put benchmarks on http://htmlpreview.github.io/?https://github.com/nh2/haskell-ordnub/blob/1f… (compare `nub` vs `ordNub`). `ordNub` is not only in a different complexity class, but even seems to perform better than nub for very small numbers of actually different list elements (that's the numbers before the benchmark names). (The benchmark also shows some other potential problem: Using a state monad to keep the set instead of a function argument can be up to 20 times slower. Should that happen?) What do you think about ordNub? I've seen a proposal from 5 years ago about adding a *sort*Nub function started by Neil, but it just died. (*) The mentioned complexity is for the (very common) worst case, in which the number of different elements in the list grows with the list (alias you don't have an N element list with always only 5 different things inside).

23 49

Combining databases from packages installed with cabal install
by Marco Túlio Pimenta Gontijo 20 Jan '14

20 Jan '14

Hi. I'm configuring haddock via cabal install (see [0]) to build the hoogle database. The database is being installed in ~/.cabal/share/doc/$package-$version/html/$package.txt, but is not being combined with the default database. That is, if right after the installation I try to search with the hoogle command for some a function, it will not work. I wrote the following script, which I called cabal-install: #!/bin/sh set -e set -x cabal \ install \ --enable-documentation \ --enable-library-profiling \ --haddock-hyperlink-source \ --haddock-hoogle \ --haddock-html \ "$@" cd ~/.cabal/share/hoogle-4.2.13/databases/ for file in ~/.cabal/share/doc/*/html/*.txt do hoo=`echo $file | sed 's/.txt$/.hoo/;s#.*/##'` if [ ! -f $hoo ] then hoogle convert $file $hoo || true hoogle combine default.hoo $hoo -o /tmp/cabal-install-$$.hoo mv /tmp/cabal-install-$$.hoo default.hoo fi done Basically, it searches for .txt hoogle databases installed that were not combined yet with the default database, and combines them. I think it would be good if this was the default behaviour of cabal install when called with --haddock-hoogle. Is this a bug? Greetings. 0: http://hackage.haskell.org/trac/hackage/ticket/517 -- marcot http://marcot.eti.br/

2 1

The rmonad package is mysterious
by Simon Marechal 03 Dec '13

03 Dec '13

I tried to do something simple using the rmonad package (attached). I followed the example that's in haddocks (it is wrong, constraints has no arguments), grabbed the list of extensions from rmonad's source, but this program doesn't typecheck: Could not deduce (Hashable a) arising from a use of `HM.singleton' This seems to be an obvious use of this package ... am I missing something ?

2 1

Best practices for Arrows?
by Tom Ellis 13 Nov '13

13 Nov '13

I feel I may be doing a lot of programming with Arrows in the near future. Currently I'm delighted that Arrow notation[1] exists. It makes using Arrows much less painful. Are there any best-practices I should be aware of with Arrows? Or is it just a case of getting on with it? Tom 1. http://www.haskell.org/ghc/docs/latest/html/users_guide/arrow-notation.html

3 5