July 2018 - Haskell-Cafe

GHC, cabal and nightlies via Chocolatey
by Phyx 22 Jul '18

22 Jul '18

Hi All, For those that use a cabal based workflow on Windows or are interested in doing Windows testing for their packages using AppVeyor I've written up some instructions on how to do this using Chocolatey https://hub.zhox.com/posts/chocolatey-introduction/. The standard packages are pulled directly from Haskell.org As a trial I'm also making my own Windows Nightlies for GHC and Cabal available via my NuGet package stream. Details available on the post. Thanks, Tamar

1 0

Re: [Haskell-cafe] What is your favourite Haskell "aha" moment?
by Johannes Waldmann 22 Jul '18

22 Jul '18

> - Large-scale refactoring with types: > this is a huge selling point for Haskell in general I fully agree with the general idea, but the specific example > data Shape > = Circle Double > | Square Double > | Rectangle Double Double -- ^ added is not convincing (well, to programmers that know about static typing) Think of a Java program interface Shape { .. } class Circle implement Shape { ... } When you add class Rectangle { } , then Shape foo = new Rectangle () would be an error, until you put class Rectangle implements Shape { } then the compiler tells you what methods are missing. I think the extra value of types in Haskell (for everything, including refactoring) is that they tend to express more of the program's properties (w.r.t. statically typed imperative programs). Examples: the distinction between a and IO a, between IO a and STM a. In Data.Set, function "fromList" has an Ord constraint, but "toList" does not. Does "singleton" need the constraint? I used this as an exam question just last week. - J.W.

2 1

fyi 10 benchmarks game programs broken
by Isaac Gouy 20 Jul '18

20 Jul '18

https://benchmarksgame-team.pages.debian.net/benchmarksgame/measurements/gh… Several of those programs fail to compile: Variable not in scope: rdeepseq For example: https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/fannkuc… best wishes, Isaac

1 0

What is your favourite Haskell "aha" moment?
by Simon Peyton Jones 20 Jul '18

20 Jul '18

Friends In a few weeks I'm giving a talk to a bunch of genomics folk at the Sanger Institute<https://www.sanger.ac.uk/> about Haskell. They do lots of programming, but they aren't computer scientists. I can tell them plenty about Haskell, but I'm ill-equipped to answer the main question in their minds: why should I even care about Haskell? I'm too much of a biased witness. So I thought I'd ask you for help. War stories perhaps - how using Haskell worked (or didn't) for you. But rather than talk generalities, I'd love to illustrate with copious examples of beautiful code. * Can you identify a few lines of Haskell that best characterise what you think makes Haskell distinctively worth caring about? Something that gave you an "aha" moment, or that feeling of joy when you truly make sense of something for the first time. The challenge is, of course, that this audience will know no Haskell, so muttering about Cartesian Closed Categories isn't going to do it for them. I need examples that I can present in 5 minutes, without needing a long setup. To take a very basic example, consider Quicksort using list comprehensions, compared with its equivalent in C. It's so short, so obviously right, whereas doing the right thing with in-place update in C notoriously prone to fencepost errors etc. But it also makes much less good use of memory, and is likely to run slower. I think I can do that in 5 minutes. Another thing that I think comes over easily is the ability to abstract: generalising sum and product to fold by abstracting out a functional argument; generalising at the type level by polymorphism, including polymorphism over higher-kinded type constructors. Maybe 8 minutes. But you will have more and better ideas, and (crucially) ideas that are more credibly grounded in the day to day reality of writing programs that get work done. Pointers to your favourite blog posts would be another avenue. (I love the Haskell Weekly News.) Finally, I know that some of you use Haskell specifically for genomics work, and maybe some of your insights would be particularly relevant for the Sanger audience. Thank you! Perhaps your responses on this thread (if any) may be helpful to more than just me. Simon

44 103

Monads because of I/O?
by Olaf Klinke 19 Jul '18

19 Jul '18

Paul, monads were not invented because I/O could not be presented in another way in Haskell. Monads are way older than Haskell. It is a concept of category theory which was developed in the 1950s. Actually some concepts of algebra that are even older turn out to be monads. Take Galois theory for example. Once you know the pattern, you find a monad under every stone you turn around. It's one of the luckiest things that people like Moggi and Wadler realized that monads can be applied to structure programs. And don't blame them that monads are not composable - it is simply a mathematical fact. Some monads do compose with any other monad, and those are the monad transformers. If you like Prolog's relational programming model so much, then you should play with those programs that have "no business value". Because Haskell's type inference algorithm, together with multi-parameter type classes and maybe type level natural numbers together give rise to Prolog-like capabilities. All the work is done by the compiler this way. What you say about FSM is certainly true to some extent - they are well understood, can be generated automatically, and there is decent theory to reason about them. That is why this model is used in safety-sensitive environments such as aviation. I once applied for a position in verification in the automotive industry, and the interview partner told me that they struggle mightily with the vast state spaces of the FSMs they are checking. All this speaks in favour of Haskell. The semantics is simple and beautiful, because it is a single-paradigm language. And because of that, clever people can leverage theorem provers to mathematically prove correctness of Haskell code. I don't know of many languages where that is possible. (But then, I'm not an expert on verification.) Olaf

4 3

Defining operators via sections
by Tom Ellis 19 Jul '18

19 Jul '18

I can define operators directly or through their parenthesised name: > let x .+ y = x + y > let (.+) x y = (+) x y > let (.+) x = (+) x > let (.+) = (.+) but I can't define them via sections: > let (x .+) = (x +) <interactive>:11:6: Parse error in pattern: x .+ > let (.+ y) = (+ y) <interactive>:12:6: Parse error in pattern: .+ y It seems natural to write, for example instance Monad Maybe where ... (>>= f) = \case Nothing -> Nothing Just a -> f a Is there any particular reason this is not possible? Thanks, Tom

1 0

cannot upgrade stack
by Roger Mason 19 Jul '18

19 Jul '18

Hello, I'm attempting to upgrade stack on a FreeBSD 11.1 system but it fails: stack upgrade Current Stack version: 1.5.1, available download version: 1.7.1 Newer version detected, downloading Querying for archive location for platform: freebsd-i386-static Querying for archive location for platform: freebsd-i386 Exception occured when trying to perform binary upgrade: Unable to find binary Stack archive for platforms: freebsd-i386-static freebsd-i386 Falling back to source upgrade Selected mirror https://s3.amazonaws.com/hackage.fpcomplete.com/ Downloading timestamp No updates to your package list were found Updating package index Hackage (mirrored at https://s3.amazonaws.com/hackage.fpcomplete.com/) ...Could not parse '/tmp/stack-upgrade2294/stack-1.7.1/stack.yaml': Aeson exception: Error in $['extra-deps'][0]: failed to parse field 'extra-deps': (Invalid package identifier: "rio-0.1.1.0@rev:0","rio-0.1.1.0@rev:0") See http://docs.haskellstack.org/en/stable/yaml_configuration/ If it matters, I'm using ghc-8.0.2_3. Thanks for any help, Roger

3 6

Backpack vs plain old classes and instances
by Clinton Mead 19 Jul '18

19 Jul '18

Hi All I read though Edward Z. Yang's blog post <http://blog.ezyang.com/2016/10/try-backpack-ghc-backpack/> about Backpack but I can't understand what it does above and beyond classes and instances. It seems to me we could just replace a "signature" with a "class" and a "unit" with an "instance" and achieve the same thing. Of course there are issues with orphans instances if we don't own either the class or the associated data, but it would seem to me that "orphan units" are no less problematic than "orphan instances". Edward Kmett's unpacked-containers <https://www.reddit.com/r/haskell/comments/8a5w1n/new_package_unpackedcontai…> gets some speed improvements using Backpack, but is Backpack just optimisation thing, or are there ways you can organise code with Backpack that you couldn't do without just classes and instances? For example, does Backpack solve the issue of packages requiring huge dependency lists to implement instances that most of their users will not use? Thanks, Clinton

3 4

SqlPersistT action in MonadError issue
by Vlatko Basic 18 Jul '18

18 Jul '18

Hello, I'm trying to use SqlPersistT funcs with MonadError, but am failing in writing the runDB correctly. I tried several things, but always getting: • Couldn't match type ‘IOException’ with ‘AppException’ arising from a functional dependency between: constraint ‘MonadError AppException IO’ arising from a use of ‘f1’ instance ‘MonadError IOException IO’ at <no location info> • In the second argument of ‘runPool’, namely ‘f1’ In the second argument of ‘($)’, namely ‘runPool pgConf f1 pgPool’ In a stmt of a 'do' block: liftIO $ runPool pgConf f1 pgPool I understand there already is "instance MonadError IOException IO" and fundep says it can be only one for IO. How to make it compile? Best regards, vlatko Here is the minimal reproducible code: module Test where import Prelude import Control.Exception.Base import Control.Monad.Except import Control.Monad.Trans.Reader import Database.Persist.Postgresql data AppException = ExcText String | ExcIO IOException deriving (Show) type AppM m = ExceptT AppException (ReaderT App m) data App = App { pgConf :: PostgresConf, pgPool :: ConnectionPool} runDB :: (MonadIO m, MonadError AppException m) => AppM m Bool runDB = do App{..} <- lift ask liftIO $ runPool pgConf *f1* pgPool -- error -- liftIO $ runPool pgConf *f2* pgPool -- OK f1 :: (MonadIO m, MonadError AppException m) => SqlPersistT m Bool f1 = throwError $ ExcText "exception" f2 :: MonadIO m => SqlPersistT m Bool f2 = return True

2 4

Re: [Haskell-cafe] Monads vs. monoids
by Olaf Klinke 18 Jul '18

18 Jul '18

>Am 16.07.2018 um 21:48 schrieb Olaf Klinke: >> Joachim Durchholz wrote: >>> Nope, monoid is a special case of monad (the case where all input and >>> output types are the same). >>> (BTW monoid is associativity + neutral element. Not 100% sure whether >>> monad's "return" qualifies as a neutral element, and my >>> monoid-equals-monotyped-monad claim above may fall down if it is not. >> >> For every monad M, the type M () is a monoid, > >That doesn't make M a monoid, just its type. >Besides, type-level monoids aren't relevant to data-level properties. I'm sorry, I misunderstood your question, then. Of course monads are not monoids. You could say that every monad harbors a monoid, and that every monoid arises this way. But of course the whole and the part are not the same. > >> Does every monoid arise this way? Yes: Since base-4.9 there is the >> monad instance >> Monoid a => Monad ((,) a) >> and of course a and (a,()) are isomorphic (disregarding bottoms). > >An isomorphism does not make it the same, just easily mappable. > >This is pretty near to hair-splitting, I know. >However, from a software design perspective, it's important to keep >things separate even if they are easily mappable: temperatures are just >floats, it's an incredibly easy mapping - but the code becomes clearer >and more maintainable if you keep the Temperature type separate from the >Float type. You may even want to forbid multiplying Temperatures (but >you want the ability to multiply with a number, and temperature >quotients can be useful, too). I totally agree. As a domain theorist I am aware that a and (a,()) are not isomorphic because neither is () the terminal object of Hask nor is (,) the categorical product. But in terms of total elements, there is a monoid isomorphism between the two. >Not 100% sure how much of this is really applicable. > >> Also, there is the famous tongue-in-cheek saying "monads are just >> monoids in the category of endofunctors" > >Tongue-in-check does not make it real. >And being a monoid in a category does not make it a monoid directly. That depends on the definition of "monoid". If a monoid is a set with certain structure, then a monad is not a monoid. If a monoid is a monoid object in some monoidal category, then a monad is a monoid. Maybe we can agree on this distinction? monoid = monoid object in Set monoid object = any monoid object in monoidal closed category. > >There's also a final argument: If monad and monoid are really the same, >why do mathematicians still keep the separate terminology? Because they are different, as we hopefully agree. Olaf

3 2