- Haskell-Cafe - Haskell.org

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 20 Jul '18

20 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

Proper rounding of floating-point values
by Troels Henriksen 17 Jul '18

17 Jul '18

Much to my surprise, there does not seem to be a function in base (let alone the Prelude) that rounds floating point numbers correctly in the presence of NaNs and infinities. For example: > round (0/0 :: Double) :: Int 0 > round (0/0 :: Double) :: Integer -269653970229347386159395778618353710042696546841345985910145121736599013708251444699062715983611304031680170819807090036488184653221624933739271145959211186566651840137298227914453329401869141179179624428127508653257226023513694322210869665811240855745025766026879447359920868907719574457253034494436336205824 > round (1/0 :: Double) :: Int 0 > round (1/0 :: Double) :: Integer 179769313486231590772930519078902473361797697894230657273430081157732675805500963132708477322407536021120113879871393357658789768814416622492847430639474124377767893424865485276302219601246094119453082952085005768838150682342462881473913110540827237163350510684586298239947245938479716304835356329624224137216 This is because the 'round' function must return an instance of Integral, which Double is not. In the presence of NaNs and infinities, this does not fly. In my own code, I ended up just using the FFI to call out to C, which is simple enough: foreign import ccall "round" c_round :: Double -> Double foreign import ccall "roundf" c_roundf :: Float -> Float However, it does disturb me a bit that I cannot find a standard way to do this fairly common operation. (GHC's implementation does seem to avoid many other common pitfalls[0], probably because it does use C's round() under the covers.) [0]: https://www.cockroachlabs.com/blog/rounding-implementations-in-go/ -- \ Troels /\ Henriksen

1 0

Monads vs. monoids
by Olaf Klinke 17 Jul '18

17 Jul '18

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, with mempty = return () x <> y = x >> y 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). Also, there is the famous tongue-in-cheek saying "monads are just monoids in the category of endofunctors" which is explained in numerous blog posts and Youtube videos. The monoid M () above has funny properties. Specialize M = [] and obtain the monoid of natural numbers under multiplication. Since (>>) has the more general type Monad m => m a -> m b -> m b We have a monoid action of M () on any type M b. In case of lists, it multiplies elements: [(),()] >> xs doubles the number of every element of the list xs. Olaf

3 2

if-then without -else?
by Johannes Waldmann 17 Jul '18

17 Jul '18

Dear Cafe, a student in my class detected this inconsistency in the design of Haskell: > Why require that each "if-then" has an "else" > while still allowing incomplete sets of patterns? > We could define "if p then a" > by translating to "case p of { True -> a }" I think that "but then we'd have the dangling-else problem" is not a good answer because this is really about semantics, not surface syntax. For reference, Scheme has short-if, see http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-14.html#node_sec_11.4.3 (value is "unspecified" if condition is false) and Common LISP does as well https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node84.html#SECTION001160000… (value is "nil") Was this considered at some point in Haskell's design process? There is Section 5.2 on pattern matching in http://haskell.cs.yale.edu/wp-content/uploads/2011/02/history.pdf (*) but it does not mention if-then(-else). - J.W. (*) can we please add this to https://www.haskell.org/documentation Upvote this: https://github.com/haskell-infra/hl/issues/86

6 5