February 2020 - Haskell-Cafe

(Feeling that) GHCi is trying to protect me from myself with overlapping instances and existential types
by Juan Casanova 16 Feb '20

16 Feb '20

Hello all, This stems from a Stack Overflow question that I posted a few days ago: https://stackoverflow.com/questions/60199424/overlapping-multi-parameter-in… I'd like to hear either agreement or a more convincing argument as to why GHCi behaves the way it does in this case, since the ones at Stack Overflow basically told me that it does to "protect me from being too dumb and not understanding my own code", the way I interpret it. I felt that was totally against the principles of Haskell, so I thought there must be more. I'm going to focus on my second example (on my own answer to the question) for the sake of clarity here. Consider the following code: {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE ExistentialQuantification #-} module ExistentialTest where class Class1 a b where foo :: a -> b instance {-# INCOHERENT #-} Monoid a => Class1 a (Either b a) where foo x = Right (x <> x) instance {-# INCOHERENT #-} Monoid a => Class1 a (Either a b) where foo x = Left x data Bar a = Dir a | forall b. Class1 b a => FromB b getA :: Bar a -> a getA (Dir a) = a getA (FromB b) = foo b createBar :: Bar (Either String t) createBar = FromB "abc" createBar2 :: Bar (Either t String) createBar2 = FromB "def" This code compiles, but only because of the INCOHERENT annotations. If you remove those, it will give overlapping instances errors on both createBar and createBar2. I argue that those errors are senseless, because, while if t were instantiated to String then those instances would be valid, the functions createBar and createBar2 are by definition polymorphic, and the only way to make those functions work for every t is to use specifically one of the instances on each case. Therefore, the compiler should realize this, use that instance, and not complain about it. When using the INCOHERENT annotations it works, and uses the right instance on each case (because of course it would, the other instance is absolutely unusable in each of the cases). The best argument that I was given on stack overflow is that allowing that would make it confusing because people might use those polymorphic functions with the specific t ~ String instantiation of the types and expect the behaviour to use the instance that is not usable in general. I find that a really poor argument. A user of the function need not know in general how a function internally works (that it uses the Class1 instance, which is not a constraint on the function signature), and it would be way too much for a user of the function to look at that code (that they should not need to look at), and then guess which instance it might be using, and guess wrong. Having GHCi protect me from that highly hypothetical situation while preventing me from compiling theoretically correct programs seems strange at best. I have tried to think of potential situations where a similar kind of ambiguity might affect the actual type checking and not just what the user might (wrongly) think of it, but I haven't found any. From what I understand, though, the INCOHERENT annotation is dangerous in that if there were other instances which in fact did match in general, then GHCi would choose an arbitrary one. Therefore, I'd like them out of my code. Are there any comments on this that give me a more theoretical reason as to why Haskell disallows this without the INCOHERENT annotations? Is it worth proposing a change to the compiler to allow this? It basically seems that the compiler is checking the overlapping instances "too soon" before realizing that t cannot be unified with String within createBar, because it is a forall quantified polymorphic function. A way to see this is to precisely comment one of the instances and realize that you still get one error on each function, and on the one you removed the right instance for, it will actually say that there is no instance at all. It feels wrong that Haskell can tell you there are two instances that would match, and when you remove one of them, it tells you that there are no instances that match. That in of itself screams bug to me until someone gives me a really convincing explanation of why that is okay. Thanks once again for any time you spent on this, haskell-cafe. Juan Casanova. -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

4 11

Re: [Haskell-cafe] (Feeling that) GHCi is trying to protect me from myself with overlapping instances and existential types
by Olaf Klinke 16 Feb '20

16 Feb '20

> the ones at Stack > Overflow basically told me that it does to "protect me from being too > dumb and not understanding my own code", the way I interpret it. I > felt that was totally against the principles of Haskell On the contrary! Protecing me against writing dumb code is one of the things where Haskell shines, and I am infinitely grateful for that. > Having GHCi protect me from that highly hypothetical situation while > preventing me from compiling theoretically correct programs seems > strange at best. But those theoretically correct programs may suddenly cease to be correct in very mysterious and little hypothetical ways, as explained below. I agree with Arien. Making the semantics of a function dependent on how many type class instances are in scope is totally against the principles of Haskell, IMHO. Even worse the function signature of createBar does not mention Class1 so at first glance there is no hint that type classes are at work here. Type class instances are hard to contain, in the sense that there is currently no mechanism of selectively importing or not importing them from some module. Change in semantics through orphan instances would be a nightmare to debug: Suppose you have written a package that defines Class1 and only the first incoherent instance. Alice comes along and uses your package to define a function useFoo :: Monoid a => a -> Either a a useFoo = foo and henceforth Alice relies on the semantics useFoo a = Right (a <> a), because that's what your package intends. Alice's code also depends on a package written by Bob, but she only uses some part of that package which is totally unrelated to useFoo and Class1. In an update of his package, Bob defines your second Class1 instance as orphan instance. Alice never explicitly imported any Class1 stuff from Bob's module, but the new instance will leak anyways. Suddenly the semantics of Alice's function changes, she gets useFoo a = Left a without any changes in her own code! If Bob did not adhere to the versioning policy then Alice has little chance of knowing that Bob's package is the cause. The only hint for Alice is the INCOHERENT pragma that signals danger, and you propose to take that away. Olaf

2 1

[ANN] zsh-haskell
by Marcin Szamotulski 16 Feb '20

16 Feb '20

Dear fellow Haskellers, I am pleased to announce a `zsh` completion for `cabal`, `ghc` and `ghc-pkg`. https://github.com/coot/zsh-haskell Cheers, Marcin Szamotulski

1 0

Taking over maintainership of cautious-file (or does anyone know of an alternative?)
by Brent Yorgey 14 Feb '20

14 Feb '20

The cautious-file package http://hackage.haskell.org/package/cautious-file has not been updated by the maintainer, Robin Green, since 2013 (though there have been a few Hackage trustee updates since then). The linked source repository was hosted on patch-tag.com and no longer exists. I tried contacting the maintainer on January 25 but have not heard back. I hereby announce my intention to take over as maintainer of the package. (As a side note, as far as I know my diagrams-haddock package is the only thing on Hackage that depends on it.) Alternatively, if anyone knows of a different, actively maintained package that provides similar functionality, I'd love to hear about it! -Brent

3 4

ghc runtime linker problem on i386
by Olaf Klinke 14 Feb '20

14 Feb '20

Dear Cafe, I'm experiencing strange behaviour on an old i386 machine when interpreting Haskell code on the fly: The same code runs from GHCi and fails as compiled executable. It might be a GHC runtime linker problem but I'm not sure. I successfully built haskintex and IHaskell with stack 2.1.3 on that machine. Both programs are supposed to interpret Haskell code at runtime: IHaskell uses the GHC API while haskintex uses hint, which itself is a wrapper for the GHC API. Therefore I suspect the problem lies in the usage of the GHC API itself. Both programs fail at runtime with the same error: $LIBDIR/ghc-prim-0.5.3/HSghc-prim-0.5.3.o: unknown symbol `_GLOBAL_OFFSET_TABLE_` When adding -dynamic to the ghc-options field in the package cabal file, the error goes away. Minimal code to reproduce is below. The i386 machine has no system ghc, no cabal, no ghcup and I wiped the $HOME/.stack directory before running "stack build". On x86-64 the error does not occur regardless of the -dynamic flag. Should I file a bug report or is this expected behaviour? If this is a bug, who should I file the bug against? Olaf {-- put this as app/Main.hs in a new stack project --} module Main where import Language.Haskell.Interpreter -- hint main :: IO () main = putStrLn =<< hintstuff hintstuff :: IO String hintstuff = fmap (either show show).runInterpreter $ do setImports ["Prelude"] interpret "1+2" (as :: Int)

1 0

Interpreting synchronized streams (pre-IO monad Haskell)
by Jiri Jakes 13 Feb '20

13 Feb '20

Heλλo! Before introduction of IO monad, first versions of Haskell used synchronised streams [1]: main :: [Response] -> [Request] where Response and Request were ADTs containing all possible actions and responses: data Request = ReadFile Name | ... | AppendChan Name String | ... data Response = Success | Str String | Bn Bin | Failure ... I wanted to write an interpreter of this representation using a simplified version: import System.Environment (getArgs) data Response = Success | StrList [String] data Request = GetArgs | PutStr String eval :: Request -> IO Response eval GetArgs = StrList <$> getArgs eval (PutStr s) = putStrLn s >> return Success main' :: [Response] -> [Request] main' ~(StrList args : _) = [ GetArgs, PutStr (show args) ] main :: IO () main = ??? I can imagine how interpreting main' could work, thanks to laziness. However, when actually trying to implement it, I get lost. I cannot figure out how could I read requests (result of calling main') before having something to pass to main'. Having a look at ancient version of GHC [2] didn't help either. Is it actually possible without some low-level tricks? Perhaps using mutually recursive functions? Or by converting to continuations somehow? Thank you! Jiri [1] http://haskell.org/definition/haskell-report-1.0.ps.gz [2] https://downloads.haskell.org/~ghc/0.29/ghc-0.29-src.tar.gz

2 1

Re: [Haskell-cafe] [ANN] Documentation for base-4.13.0.0 & GHC 8.8.1
by 石井大海 13 Feb '20

13 Feb '20

Oops, sorry I've sent the question only to Fumi mistakingly. Here I re-send to Cafe. Sorry! > 2020/02/13 13:28、石井大海 <konn.jinro(a)gmail.com>のメール: > > Hi, > > What's the difference with documentations already distributed with GHC Users' Guide? > > * https://downloads.haskell.org/~ghc/8.8.2/docs/html/ <https://downloads.haskell.org/~ghc/8.8.2/docs/html/> > * https://downloads.haskell.org/~ghc/8.8.2/docs/html/libraries/ghc-8.8.2/inde… <https://downloads.haskell.org/~ghc/8.8.2/docs/html/libraries/ghc-8.8.2/inde…> > * https://downloads.haskell.org/~ghc/8.8.2/docs/html/libraries/index.html <https://downloads.haskell.org/~ghc/8.8.2/docs/html/libraries/index.html> > > Are they hooglable? > >> 2020/02/13 13:20、Fumiaki Kinoshita <fumiexcel(a)gmail.com <mailto:fumiexcel@gmail.com>>のメール: >> >> It seems unlikely that they will be uploaded to Hackage anytime soon, so I decided to host them on my server. >> >> http://docs.hask.moe/base-4.13.0.0/index.html <http://docs.hask.moe/base-4.13.0.0/index.html> >> >> GHC 8.8.1: http://docs.hask.moe/ghc-8.8.1/index.html <http://docs.hask.moe/ghc-8.8.1/index.html> >> >> Hope this helps >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe> >> Only members subscribed via the mailman list are allowed to post. >

2 1

Re: [Haskell-cafe] [Job] Cloudseal seeks Haskell Software Engineers
by tomas gallegos 13 Feb '20

13 Feb '20

Hello there, My name is Tomas Gallegos and I specialize in functional programming using Haskell. I am very interested in this Haskell job position. It would be great if we could talk to discuss this position further and maybe schedule an interview. Thank you for your time and consideration, I look forward to hearing from you.(Attached to this email is my resume). Regards, Tomas Gallegos

6 7

[ANN] Documentation for base-4.13.0.0 & GHC 8.8.1
by Fumiaki Kinoshita 12 Feb '20

12 Feb '20

It seems unlikely that they will be uploaded to Hackage anytime soon, so I decided to host them on my server. http://docs.hask.moe/base-4.13.0.0/index.html GHC 8.8.1: http://docs.hask.moe/ghc-8.8.1/index.html Hope this helps

1 0

[ANN] BNFC-meta 0.6.1 release -- embedded Happy parsers
by Artem Pelenitsyn 12 Feb '20

12 Feb '20

Hello! BNFC-meta 0.6.1 has been released. The library [1,2] allows you to define simple parsers inside your source files using BNF-like formalism by the way of Template Haskell. A couple of small example applications are hosted here [3]. Details are described in the Haskell '11 paper [4] (preprint [5]). Compared with the previous release, support for recent GHCs is added. Also a minor problem with spaces after closing parenthesis in pretty-printer is fixed courtesy GitHub user @mbuszka. [1]: http://hackage.haskell.org/package/BNFC-meta [2]: https://github.com/ulysses4ever/BNFC-meta [3]: https://github.com/ulysses4ever/BNFC-meta-examples [4]: https://dl.acm.org/doi/10.1145/2096148.2034689 [5]: http://www.cse.chalmers.se/~patrikj/papers/MetaDSL_preprint_20110325.pdf -- Cheers, Artem

1 0