- Haskell-Cafe - Haskell.org

Munich Haskell Meeting, 2018-10-30 @ 19:30
by Leah Neukirchen 28 Oct '18

28 Oct '18

Dear all, Next week, our monthly Munich Haskell Meeting will take place again on Tuesday, October 30 at Augustiner-Gaststätte Rumpler at 19h30. For details see here: http://muenchen.haskell.bayern/dates.html If you plan to join, please add yourself to this dudle so we can reserve enough seats! It is OK to add yourself to the dudle anonymously or pseudonymously. https://dudle.inf.tu-dresden.de/haskell-munich-oct-2018/ Everybody is welcome! cu, -- Leah Neukirchen <leah(a)vuxu.org> http://leah.zone

1 0

mfix for a nested monad
by Benjamin Redelings 25 Oct '18

25 Oct '18

Hi, I'm trying to implement mfix for a monad that is nested inside another monad. I came up with the following logic for how to implement this, but I suspect there are some things I'm missing. My conclusion is that I want interpret (MFix f) = mfix (interpret.f) Does this seem right? Has this situation been discussed somewhere? -BenRI P.S. Here's what I mean by the monad being nested in another monad. Let's say that the monad M2 has interpreter i2, with type i2 :: M2 a -> M1 a and then M1 is the other monad, and has interpreter i1: i1 :: M1a -> a I suppose that the nesting is really a nesting of interpreters. P.P.S. I came up with some equational reasoning for how to treat mfix in the i2 interpreter. (a) For some interpreters `i`, it makes sense to require i (mfix f) = let x = (i . f) x in x (b) I want the composition of interpreters (i1.i2) to act like (a) above: (i1 . i2) (mfix f) = let x = (i1 . i2 . f) x in x (c) Rearranging, and then substituting using (a): i1 (i2 (mfix f)) = let x = i1 . (i2 . f) x in x = i1 (mfix (i2 . f)) (d) Therefore, we could set i2 (mfix f) = mfix (i2 . f) I'm probably going to make a `data` declaration for M2 so I could actually write i2 (Mfix f) = mfix (i2 . f) -BenRI

2 1

Re: [Haskell-cafe] Impossible types [was [Haskell-prime]: A question about run-time errors when class members are undefined]
by Anthony Clayden 25 Oct '18

25 Oct '18

Transferring from https://mail.haskell.org/pipermail/haskell-prime/2018-October/004396.html On Sat, 13 Oct 2018 at 4:04 AM, <camarao(a)dcc.ufmg.br> wrote: > > Consider for example: > > class F a b where f:: a → b > class X a where x:: a > fx = f x > > The type of fx, (F a b, X a) ⇒ b, should not be ambiguous: in > distinct contexts, fx can have distinct types (if ambiguity, and > 'improvement', are as defined below). [See the -prime message for the "defined below".] I'm just not seeing why you think any Haskell should accept that. What value could inhabit `fx` except bottom? And indeed no Haskell does accept it, not even GHC with all sorts of nasty extensions switched on, including `AllowAmbiguousTypes`. GHC will accept class `F` with a Functional Dependency `b -> a`, but still I can't 'poke' any value into the `x` argument to `f` in the equation for `fx`. Note: agreeing with this view can lead to far-reaching consequences, e.g. > support of > overloaded record fields [1,Section 7], ... There are other ways to support overloaded/duplicate record fields, without doing this much violence to the type system. Look at the `HasField` class using Functional Dependencies, in Adam Gundry's work. polymonads [2] etc. > Note that's from a Trac ticket asking for 'dysfunctional' Functional Dependencies. There's a long discussion from the type-inference brains trust coming to no discernable conclusion as to whether it's broken type safety. (Catching incoherence in the Core lint typecheck is not a good look.) a) You've not shown any detailed working of how your proposal gives the type improvement required without also descending into incoherence. b) The combination of Functional Dependencies+Overlapping Instances+Undecidable Instances might be able to cover just enough, but not too much of the requirements (which were never made clear). See my worked examples on that ticket -- some of which are really quite scary. See some of Oleg's work on his ftp site with multi-directional FunDeps and overlaps to achieve injectivity. To try to tame the scariness while still supporting enough power, see the suggestion here https://ghc.haskell.org/trac/ghc/ticket/15632 > Further examples can be discussed I have yet to see a convincing use case (from the very lengthy discussions) which couldn't be handled already in GHC. I agree the combination of extensions in GHC (including its bogus consistency check/Trac #10675) can give alarming surprises; but they don't quite break type safety. but this example conveys the > main idea that ambiguity should be changed; unlike the example > of (show . read), no type annotation can avoid ambiguity of > polymorphic fx in current Haskell. Since `fx` is not accepted in current Haskell, whether you can put a type annotation seems beside the point. AntC [1] Optional Type Classes for Haskell, Rodrigo Ribeiro, Carlos Camarão, Lucília Figueiredo, Cristiano Vasconcellos, SBLP'2016 (20th Brazilian Symposium on Programming Languages), Marília, SP, September 19-23, 2016. [2] https://github.com/carlos1camarao/ghc-proposals/blob/d81c1f26298961ac635ce0…

2 2

property testing with context
by Ben Franksen 24 Oct '18

24 Oct '18

Hi everyone it seems to be the season for new variations on the "property testing" theme, so I would like to chime in... not to announce a new library, sadly, but with a rough idea how the existing ones could perhaps be improved, based on practical experience in Darcs. The problem I have is that there is a tension between (a) stating a property in a clear and simple way, so its code doubles as a formal specification and (b) writing the property in such a way that when it fails, the reported value(s) give enough information about the context to be useful for finding the cause of the problem. Let me give an example to demonstrate what I mean. There is a simple law that says if a sequential pair of patches A;B commutes to B';A' then B';A' commutes back to A;B. In code this looks (more or less) like this: prop_recommute :: Commute p => (p :> p) wA wB -> Bool prop_recommute (x:>y) | Just (y':>x') <- commute (x:>y) = case commute (y':>x')of Just (x'':>y'') -> x==x'' && y==y'' Nothing -> False | otherwise = True This is a bit more verbose than the informal spec but still quite readable. Now suppose this property fails. So quickcheck reports the counter example pair (X:>Y) for some X and Y. But that isn't too useful in itself. We'd like to know a bit more: * did the second commute fail? * or did it succeed but x/=x'' or y/=y''? * and in the latter case, which of the two? So in practice our property code looks more like this: prop_recommute :: (ShowPatch p, Commute p) => (p :> p) wA wB -> Bool prop_recommute (x :> y) | Just (y' :> x') <- commute (x :> y) = case commute (y' :> x') of Nothing -> failed (redText "failed, where x" $$ displayPatch x $$ redText ":> y" $$ displayPatch y $$ redText "y'" $$ displayPatch y' $$ redText ":> x'" $$ displayPatch x') Just (x'' :> y'') -> if y'' /= y then failed (redText "y'' =/\\= y failed, where x" $$ displayPatch x $$ redText ":> y" $$ displayPatch y $$ redText "y'" $$ displayPatch y' $$ redText ":> x'" $$ displayPatch x' $$ redText "x''" $$ displayPatch x'' $$ redText ":> y''" $$ displayPatch y'') else if x'' /= x then failed (redText "x'' /= x, where x" $$ displayPatch x $$ redText ":> y" $$ displayPatch y $$ redText "y'" $$ displayPatch y' $$ redText ":> x'" $$ displayPatch x' $$ redText "x''" $$ displayPatch x'' $$ redText ":> y''" $$ displayPatch y'') else True | otherwise = True Now this code tells us exactly what went wrong when the property fails but it is ugly and repetitive and the additional code obscures the simple logical content. So this is no longer quite as suitable for a (human readable) formal spec. I wonder if displaying (1) all relevant contextual variables and (2) "where in the code it fails" could be automated away, somehow. I guess this is not trivial and may require syntactic analysis, so perhaps expecting a /library/ to solve the problem is unrealistic, except perhaps by using Template Haskell. I'd also go with a separate tool that extracts properties from a module and enriches them with code that displays the additional information. Tackling this problem might be an interesting theme for a master thesis... ;-) Cheers Ben

4 7

Has twidge stopped working?
by Rider of Giraffes 24 Oct '18

24 Oct '18

Greetings, New on the list, apologies if I break any traditions. Sent here from https://github.com/jgoerzen/twidge/wiki with the question in the header. I sent a tweet via twidge on Oct 22, but since then nothing has got through. Has twidge stopped working? Has Twitter made yet another change to the API, this one incompatible? All assistance and advice welcome. Thank you. -- I don't suffer from stress - I'm a carrier.

2 1

Re: [Haskell-cafe] property testing with context
by Olaf Klinke 24 Oct '18

24 Oct '18

Ben, the solution might be simple: Don't express the property as an atomic function (a -> Bool). This reminds me a bit of the Cutty-Howard correspondence, only that proofs are replaced by counterexamples. A testing library should have an operator for each of the logical connectives, where - a counterexample to True is never found - a counterexample to False is () - a counterexample to (not x) is an example for x - a counterexample to (x && y) is either a counterexample to x or a counterexample to y, whichever is found first - a counterexample to (x || y) is a pair of counterexamples to both x and y - a counterexample to (x ==> y) is an example for x together with a counterexample for y Then, if you build your property out of smaller properties and the connectives above, the counterexample-finder would be able to inform you which part of the property failed. I'm pretty sure at least one of the testing libraries has a system like this. Cheers, Olaf

2 1

ANN: Yampa-0.12 and yampa-test (QuickCheck-based FRP testing)
by Ivan Perez 22 Oct '18

22 Oct '18

Dear all, I am please to announce version 0.12 of Yampa! Yampa is a mature and robust FRP implementation that has been used to create mobile, desktop, and web games and applications, including commercial mobile games available on iTunes and Google Play, and open source games that use devices like wiimotes and kinect [1-2]. This version comes with an accompanying library, yampa-test, which includes QuickCheck-based testing with LTL-based signal predicates. These features are described in the ICFP 2017 paper "Testing and Debugging Functional Reactive Programming" [3]. Thanks to Christina Zeller for reporting bugs. Both libraries can be found here: http://hackage.haskell.org/package/Yampa http://hackage.haskell.org/package/yampa-test This version has been tested against all major GHC versions from 7.6 to 8.6. Some legacy code has been deprecated, which has triggered a major version bump (0.12). I would expect all projects that use Yampa to work by, at most, adapting the version constraints in the cabal files. New versions of Yampa will present a simpler API, better documentation and benchmarks [4]. As always, contributions are welcome. There are a number of issues on the github page that are particularly suitable for beginners [5]. Happy Haskelling! Ivan [1] https://github.com/ivanperez-keera/Yampa#other-examples [2] https://haskell.games [3] https://dl.acm.org/citation.cfm?id=3110246 [4] https://github.com/ivanperez-keera/Yampa/milestones [5] https://github.com/ivanperez-keera/Yampa/labels/help%20wanted

1 0

(Sample) bioinformatics applications
by Vasili I. Galchin 22 Oct '18

22 Oct '18

Hello, Do any of these beasts exist for reference? Regards, Vasily

1 0

Well typed OS
by Yotam Ohad 22 Oct '18

22 Oct '18

Hi, In the last couple of days, I've been toying with the thought of an operating system in which programs (or more accurately, any process) has a distinct type which limits its use of the machine. For example, `echo` (String -> String) won't be able to print an output without a second program which would handle changing stdout. I think it could "break down" the IO monad into other structures that are better at specifying what is changing: A file is read / memory written / etc. I do, however, not sure how to incorporate drivers (which handles IO and external devices) into this. Giving them an `IO a` type feels like cheating. I would be much cooler if there was a way to treat them like the `echo` function from earlier. What are your thoughts/suggestions? I'll be happy to hear them. Yotam

13 26

Why is the Cabal User's Guide left outdated?
by Yuji Yamamoto 20 Oct '18

20 Oct '18

Getting interested in the features since Cabal 2.2 (esp. common stanzas), I looked up with the User's Guide <https://www.haskell.org/cabal/users-guide/>, which is (and should be) listed in the search result first, but can't find because the User's Guide is still about Cabal 2.0. Why is it left outdated? Actually User's Guide (HEAD) <https://cabal.readthedocs.io/en/latest/> is kept updated, but it's hard to find, and can include some information too new to release. Thanks in advance. -- 山本悠滋 twitter: @igrep GitHub: https://github.com/igrep GitLab: https://gitlab.com/igrep Facebook: http://www.facebook.com/igrep Google+: https://plus.google.com/u/0/+YujiYamamoto_igrep

2 2