March 2014 - 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

Typesafe multi-table PostgreSQL queries in Yesod with schema names?
by Manuel Gómez 12 Dec '14

12 Dec '14

Hi list, I’m looking for a rather specific point in the design space for database access libraries in Haskell and I’m having some trouble figuring out whether any existing library covers my use cases. Specifically, I need to 1. get a Yesod application to access a PostgreSQL database without having to reinvent the universe to get them decently integrated, 2. write queries in an EDSL with a good approach to composability and decent static verification against some declared form of the database objects, 3. be able to perform joins 4. be able to specify the schema name for each database object used in queries These are the closest solutions I’ve found: * HaskellDB: seems like the best approach to the EDSL issue and it’s certainly capable of performing joins, and I haven’t looked into schema names, but it seems possible — but it seems to be poorly maintained and somewhat abandoned, and comfortable Yesod integration doesn’t sound like a lot of fun. * Persistent: it’s perfectly integrated into Yesod, and together with Esqueleto, it provides a nice, typesafe and fully expressive EDSL — but, as far as I can tell, there is no support for specifying schema names, which is essential for my use case. * Groundhog: Yesod integration is reasonable since Persistent borrowed a good bit of its design, and after a few weeks of experimenting, I’ve got it pretty much worked out by now, but while it certainly takes an interesting and solid approach to the EDSL issue, it seems completely incapable of performing joins, and hence its usability is very heavily limited — I don’t fancy creating SQL views for each and every join I need. * postgresql-simple: minimal Yesod integration shouldn’t be too uncomfortable, since Persistent uses it internally anyway, and it can certainly do joins and use whatever fancy SQL magic I could ever want to write, certainly including schema names — but it doesn’t really do anything for statically checking queries against a schema specification or for composability and code reuse, and I might as well just use Persistent to do raw SQL. I’ve breifly looked at modifying Persistent to add support for schema names, but I got lost in the source code very quickly, and I worry about the fact that it requires serial primary keys — Groundhog is *very* nice in that it has a great approach to DBMS-specific syntax and other things I’ll probably need (non-numeric and composite keys), but it’s really a shame that it can’t do joins, and the workaround with views sort of defeats the purpose of SQL abstraction. I’m not sure what to do about this. Is there some grand unified relational database access library I just haven’t found, or is a pull request the only solution?

5 6

Haskell Cheat Sheet
by Rudy Matela 26 Oct '14

26 Oct '14

Hello, All, Some time ago, I was looking for a Haskell Cheat Sheet, to help me remember Haskell's syntax and common functions. I've found one, but it was quite long (14 pages), not what I was looking for. So, I've started building a Haskell Cheat Sheet with the most common language features condensed in two pages. It still needs a lot of improvement (and some content). I'm using LaTeX and I've built a "cls" (so it can be used to create Sheets for other languages as well), it is kind of a hack for now. If someone wants to use it as a reference, the first version can be found on [1] and the TeX source can be found on GitHub [2]. I would appreciate help on it: feel free to fork and make pull requests with new additions (or mail me asking for push permissions). Regards, Rudy [1]: https://matela.com.br/pub/cheat-sheets/haskell-ucs-0.1.pdf [2]: https://github.com/rudymatela/ultimate-cheat-sheets

4 5

Re: [Haskell-cafe] ANN: set-cover solves Sudoku, Soma cube, 8 Queens etc.
by Johannes Waldmann 22 Jun '14

22 Jun '14

Henning Thielemann <lemming <at> henning-thielemann.de> writes: > .. package set-cover for solving exact set cover problems. > http://hackage.haskell.org/package/set-cover It's hard to evaluate whether one could use the library because there's essentially no visible documentation. E.g., what does Math.SetCover.Exact.search do? Its type refers to "State" which seems implementation-dependent, and hides the connection to the specification of the set cover problem. Putting some text and examples into the haddocks might help. But of course putting the specification there would be even better. Also, care to explain what algorithm your solver uses, and give some performance data (e.g., N-queens for N=10,20,40,..)? - J.W.

2 1