- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] [ghc-proposals/cafe] Partially applied type families
by Anthony Clayden 08 Jun '17

08 Jun '17

> On Tue Jun 6 19:22:45 UTC 2017, Richard Eisenberg wrote: > I still don't see why TypeError is problematic once we > have instance guards. Ah, "once we have instance guards", TypeError is never needed. With instance guards, you might sometimes want to put a TypeError instance, to give a more helpful message. (HList nowadays exploits TypeError that way.) OTOH, sometimes currently you want to say: "I don't want to provide an instance for that pattern here, but by all means somebody else can elsewhere." Example code to illustrate the above: > module A > class C a b ... > instance C Int b ... > > module B > instance C a Bool ... Those instances overlap irresolvably. The only way you can catch (not really improve) is: > instance (TypeError <help message>) => C Int Bool ... But a) which module do you put that in? b) what if somebody wants a `instance C Int Bool`? with guards > module A > class {-# INSTANCEGUARDS #-} C a b ... > instance C Int b | b /~ Bool ... > > module B > instance C a Bool | a /~ Int ... > > module C -- if 'somebody else' wants > instance C Int Bool ... AntC

1 0

ANNOUNCE: streaming-conduit
by Ivan Lazar Miljenovic 08 Jun '17

08 Jun '17

I've recently found myself really enjoying using Michael Thompson's [streaming] library for, well, streaming data. However, a lot of packages that I want to use already use conduit for all their streaming needs. As such, I've just written the [streaming-conduit] library to convert between the two (rather than just switching this project to conduit entirely as I couldn't find a simple way to just stream data from a PostgreSQL database). I make no guarantees at this stage of performance, and it's quite possible that - especially for the asStream and asConduit functions - that they may not interoperate cleanly with monadic operations. [streaming]: https://hackage.haskell.org/package/streaming [streaming-conduit]: https://hackage.haskell.org/package/streaming-conduit -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com http://IvanMiljenovic.wordpress.com

1 0

Turtle library : grepping on Text vs FilePath
by Ruben Astudillo 07 Jun '17

07 Jun '17

Dear list On the Turtle library, the grep function got the following signature grep :: Pattern a -> Shell Line -> Shell Line For it to filter output of the `ls :: FilePath -> Shell FilePath` I got to fmap and transform via de Turtle.Format or Turtle.Line modules. Is this an indicator I shouldn't be doing this? Is the library telling me to use `find`? or is just accidental? -- -- Ruben

2 3

Encoding superclass relationships as a constraint?
by Alexis King 07 Jun '17

07 Jun '17

Using ExistentialQuantification, it’s possible to create a rather generic type that packages some arbitrary dictionary up at runtime: data Some ctx = forall a. ctx a => Some a This is nice, but it’s not very interesting. It would be nice if we could define a Show instance for our type, and a naïve implementation is trivial: instance Show (Some Show) where show (Some x) = show x However, this isn’t very useful in practice, since it means we can only show values of precisely the type (Some Show), which are better represented as values of type String. However, we might reasonably have some class with Show as a superclass: class Show a => Foo a instance Foo () ...and we might want to show values of type (Some Foo). However, this won’t work with the naïve implementation, since Foo is not the same as Show. Clearly, what we want is some instance like this: instance (ctx ≈> Show) => Show (Some ctx) ...where (a ≈> b) can be read “a implies b”. Unfortunately, as far as I can tell, this isn’t actually possible in any general way. The closest thing I was able to come up with was a less general solution using Edward Kmett’s constraints package. It’s possible to write (≈>) with some manual boilerplate: import Data.Constraint import Data.Constraint.Forall class Class (ctx a) (ctx' a) => Class1' ctx ctx' a instance Class (ctx a) (ctx' a) => Class1' ctx ctx' a type Class1 ctx ctx' = Forall (Class1' ctx ctx') type a ≈> b = Class1 b a ...and then it’s possible to write that Show instance: instance (ctx ≈> Show) => Show (Some ctx) where show (Some (x :: a)) = case inst @(Class1' Show ctx) @a of Sub Dict -> case (cls :: ctx a :- Show a) of Sub Dict -> show x However, this means users have to manually implement Class instances for their classes. Using the above example of Foo, a user would have to write the following instance: instance Class (Show a) (Foo a) where cls = Sub Dict With that instance, we can properly show values of type (Some Foo): ghci> Some () :: Some Foo () But this instance is both trivial and annoying, since it means the machinery leaks out of the implementation code and into the code that uses it. I’m wondering if there’s any way to do this more generally, and if not, if there’s any reason it could not or should not be supported by GHC itself. Alexis

2 1

Call for participation: Trends in Functional Programming in Education 2015 (in association with TFP 2017)
by Simon Thompson 07 Jun '17

07 Jun '17

Trends in Functional Programming in Education, 2017 Call for participation https://www.cs.kent.ac.uk/people/staff/sjt/TFPIE2017/ Programme timings https://www.cs.kent.ac.uk/people/staff/sjt/TFPIE2017/TFPIE_2017/Programme.h… The sixth workshop on Trends in Functional Programming in Education, 2017, which is to be held on the Canterbury campus of the University of Kent on Thursday, 22 June. Registration is included with that for TFP 2017, 19–21 June. Morning: functional programming and online learning A particular topic of this year's TFPIE will be MOOCs and other online learning and we've managed to gather people from most of the current MOOCs in functional programming to come to an informal symposium. Keynote: Heather Miller of EFPL and Northeastern University will begin the symposium by giving a keynote on this topic. Heather works on and around the Scala programming language and is Executive Director of the Scala Center. This will be followed by a presentation from Yann Régis-Gianas and Benjamin Canou about the MOOC on OCaml, and a round table discussion including Heather, the OCaml MOOC team, Jeremy Singer (Haskell), and Simon Thompson (Erlang). The morning will conclude with two regular presentations: - Stephen Adams. Teaching Erlang through the Internet: An Experience Report - Jeremy Singer and Blair Archibald. Functional Baby Talk: Analysis of Code Fragments from Novice Haskell Programmers Afternoon: TFPIE regular programme The afternoon will begin with a best lecture: Colin Runciman (York) on the topic of Purely Functional Queues The meeting will then have four regular presentations: - Marco T. Morazan. Vector Programming Using Structural Recursion - Curtis d'Alves, Tanya Bouman, Christopher Schankula, Jenell Hogg, Levin Noronha, Emily Horsman, Rumsha Siddiqui and Christopher K. Anand. Using Elm to Introduce Algebraic Thinking to K-8 Students - Hans-Wolfgang Loidl, Phil Barker and Sanusi Usman. Enhancing the Learning Experience on Programming-focused Courses via Electronic Assessment Tools (Extended Abstract) - Juan Carlos Saenz-Carrasco and Mike Stannett. Overcoming Non Distributivity: A Case Study in Functional Programming The meeting will conclude with a lightning talks session for attendees and others to give short talks about work in progress or projects that they would like to get started, followed by a plenary discussion on future directions for the community and the workshop. Programme committee Dr Laura Castro, University of A Coruña Prof Ralf Lämmel, University of Koblenz-Landau Dr Elena Machkasova, University of Minnesota, Morris Prof Michel Mauny, Inria, Paris Dr Jeremy Singer, University of Glasgow Prof Simon Thompson, University of Kent (chair) Simon Thompson | Professor of Logic and Computation School of Computing | University of Kent | Canterbury, CT2 7NF, UK s.j.thompson(a)kent.ac.uk | M +44 7986 085754 | W www.cs.kent.ac.uk/~sjt

1 0

Re: [Haskell-cafe] Bug in GHC or cabal-install?
by Ivan Lazar Miljenovic 06 Jun '17

06 Jun '17

On 6 June 2017 at 23:27, Henk-Jan van Tuyl <b.vantuyl1(a)upcmail.nl> wrote: > > versionBranch is still in base, but it is not compatible with Cabal 2. You mean it isn't re-exported by Cabal-2? Then maybe wxc's Setup.hs needs to explicitly import Data.Version from base rather than relying upon the re-export. > > Regards, > Henk-Jan van Tuyl > > > > > On Tue, 06 Jun 2017 14:32:45 +0200, Ivan Lazar Miljenovic > <ivan.miljenovic(a)gmail.com> wrote: > >> On 6 June 2017 at 21:13, Henk-Jan van Tuyl <hjgtuyl(a)chello.nl> wrote: >>> >>> >>> You are right, versionBranch is from originally from base, but you are >>> missing the point: >>> package wxc compiles perfectly the first time, but, without anything >>> being >>> changed, does not compile the second time. By the way, I am using a cabal >>> sandbox and as I said earlier, I am using a GHC release candidate. >> >> >> And in that release candidate, does the version of base have >> versionBranch in it? >> >> My guess is that a new version of Cabal is being used the second time, >> which is compiled against the base that comes with that RC which is >> missing versionBranch. >> >> (But since I don't have any GHC RC's I can't check it myself.) >> > > > >>> >>> Regards, >>> Henk-Jan van Tuyl >>> >>> >>> >>> On Tue, 06 Jun 2017 00:33:40 +0200, Ivan Lazar Miljenovic >>> <ivan.miljenovic(a)gmail.com> wrote: >>> >>>> On 6 June 2017 at 07:55, Henk-Jan van Tuyl <b.vantuyl1(a)upcmail.nl> >>>> wrote: >>>>> >>>>> >>>>> >>>>> wxc/setup.hs uses versionBranch from Cabal[0]; the function >>>>> versionBranch >>>>> is >>>>> not in Cabal 2, that is why I added "Cabal < 2" to wxc.cabal. When >>>>> installing wxc the first time, the right version of Cabal is picked, >>>>> when >>>>> "cabal install" is invoked a second time, GHC tries to compile >>>>> wxc/setup.hs >>>>> again, but with the wrong version of Cabal (note: the release candidate >>>>> of >>>>> GHC comes with Cabal 2) >>>>> >>>>> [0] >>>>> >>>>> >>>>> https://hackage.haskell.org/package/Cabal-1.24.2.0/docs/Distribution-Make.h… >>>> >>>> >>>> >>>> If you look at the source for this module, you'll see that it isn't >>>> defined in there; it's actually from Data.Version in base. >>>> >>>>> >>>>> >>>>> >>>>> On Mon, 05 Jun 2017 04:58:05 +0200, Ivan Lazar Miljenovic >>>>> <ivan.miljenovic(a)gmail.com> wrote: >>>>> >>>>>> I don't think it's a problem with Cabal, but the version of base going >>>>>> by the error: versionBranch is from base, and that error message is >>>>>> talking about compiling the setup.hs from wxc. >>>>>> >>>>>> On 5 June 2017 at 12:03, Henk-Jan van Tuyl <b.vantuyl1(a)upcmail.nl> >>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> The strange thing is, that the right version of Cabal is picked, the >>>>>>> first >>>>>>> time wxc is compiled. But when invoking cabal-install the second >>>>>>> time, >>>>>>> the >>>>>>> setup-depends section seems to be ignored (or at least the Cabal < 2 >>>>>>> part). >>>>>>> This does not happen with GHC 8.0.2 >>>>>>> >>>>>>> (By the way, cabal-install tries to compile setup.hs again, even >>>>>>> though >>>>>>> nothing has changed.) >>>>>>> >>>>>>> Regards, >>>>>>> Henk-Jan van Tuyl >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Sun, 04 Jun 2017 13:39:17 +0200, Ivan Lazar Miljenovic >>>>>>> <ivan.miljenovic(a)gmail.com> wrote: >>>>>>> >>>>>>>> This is from a limitation/bug with Cabal-the-library, in that there >>>>>>>> are typically no dependency checks for custom Setup.[l]hs >>>>>>>> configurations. >>>>>>>> >>>>>>>> wxc has such a custom one: >>>>>>>> http://hackage.haskell.org/package/wxc-0.92.3.0/src/Setup.hs >>>>>>>> >>>>>>>> versionBranch is from Data.Version in base, and it appears that the >>>>>>>> in >>>>>>>> this GHC pre-release there's been a change in base that removed this >>>>>>>> function. >>>>>>>> >>>>>>>> On 4 June 2017 at 19:45, Henk-Jan van Tuyl <hjgtuyl(a)chello.nl> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> L.S., >>>>>>>>> >>>>>>>>> I am trying the prerelease of GHC, version 8.2.0.20170507 >>>>>>>>> >>>>>>>>> I adapted wxHaskell to the new packages that come with the new GHC >>>>>>>>> and >>>>>>>>> it >>>>>>>>> compiles now, but only the first time. If I compile it a second >>>>>>>>> time, >>>>>>>>> even >>>>>>>>> if nothing has changed, the information from the custom-setup >>>>>>>>> section >>>>>>>>> of >>>>>>>>> the wxc.cabal file seems to be forgotten. This section looks like >>>>>>>>> this: >>>>>>>>> >>>>>>>>> custom-setup >>>>>>>>> setup-depends: >>>>>>>>> base, >>>>>>>>> Cabal < 2, >>>>>>>>> containers, >>>>>>>>> bytestring, >>>>>>>>> split, >>>>>>>>> process, >>>>>>>>> directory, >>>>>>>>> filepath >>>>>>>>> (I am using cabal-install 1.24.0.2) >>>>>>>>> >>>>>>>>> Output from the second time I try to install wxHaskell: >>>>>>>>> >>>>>>>>>> cabal install --force-reinstalls --reinstall wxdirect wxc wxcore >>>>>>>>>> wx >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> [1 of 1] Compiling Main ( >>>>>>>>> X:\Temp\wxHaskell\wxcore\dist\setup\setup.hs, >>>>>>>>> X:\Temp\wxHaskell\wxcore\dist\setup\Main.o ) >>>>>>>>> Linking X:\Temp\wxHaskell\wxcore\dist\setup\setup.exe ... >>>>>>>>> [1 of 1] Compiling Main ( >>>>>>>>> X:\Temp\wxHaskell\wxc\dist\setup\setup.hs, >>>>>>>>> X:\Temp\wxHaskell\wxc\dist\setup\Main.o ) >>>>>>>>> >>>>>>>>> X:\Temp\wxHaskell\wxc\dist\setup\setup.hs:505:61: error: >>>>>>>>> Variable not in scope: versionBranch :: >>>>>>>>> Version >>>>>>>>> -> >>>>>>>>> [a0] >>>>>>>>> | >>>>>>>>> 505 | full_ver = (concat . intersperse "." . map show . >>>>>>>>> versionBranch) ver >>>>>>>>> | >>>>>>>>> ^^^^^^^^^^^^^ >>>>>>>>> >>>>>>>>> This error message indicates that the wrong version of Cabal (2.0) >>>>>>>>> is >>>>>>>>> used >>>>>>>>> to compile the wxcore setup.hs >>>>>>>>> It looks like a cabal-install bug, but this does not happen when I >>>>>>>>> use GHC 8.0.2; should I write a GHC bug ticket? >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Henk-Jan van Tuyl > > > -- > Folding@home > What if you could share your unused computer power to help find a cure? In > just 5 minutes you can join the world's biggest networked computer and get > us closer sooner. Watch the video. > http://foldingathome.stanford.edu/ > > > http://Van.Tuyl.eu/ > http://members.chello.nl/hjgtuyl/tourdemonad.html > Haskell programming > -- -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com http://IvanMiljenovic.wordpress.com

1 0

Re: [Haskell-cafe] [ghc-proposals/cafe] Partially applied type families
by Anthony Clayden 06 Jun '17

06 Jun '17

> On Mon Jun 5 03:15:32 UTC 2017, Richard Eisenberg wrote: > > On Jun 4, 2017, at 4:06 AM, Anthony Clayden wrote: > ... I find these examples are clearest when they > include code that you want to write, but can't; Haskellers are a bright bunch. If there's code they want to write but can't, they'll find a work-round; bless it as an 'idiom'; publish a couple of papers; and make a virtue out of necessity. Looking at the HList library as is today. It's almost unrecognisable compared to the 2004 paper. It is in fact using the same techniques, but they're entirely obscured in work-rounds. There's no longer overlapping instances except in one class/in its own module. viz the type-level type equality test, returning Boolean. > ... I was expecting an example of how today's > TypeError doesn't work for you. The classic place in HList where TypeError (used to be) unavoidable is the `Lacks` predicate. Validate that an HList does _not_ contain element type `e`: > class HLacks e l > instance HLacks e HNil > instance (TypeError e) => HLacks e (HCons e l') > instance (HLacks e l') => HLacks e (HCons e' l') The sole purpose of that type-equal/TypeError instance, is to 'shadow' the type-different instance. That's nowadays avoidable: > -- class and HNil instance same > instance (TypeEq e e' b, HLacksCase b e l') > => HLacks e (HCons e' l') -- catch-all HCons > class HLacksCase b e l' > instance (HLacks e l') => HLacksCase False e l' > instance (TypeError e) => HLacksCase True e l' -- this now optional So every class in the HList library now has a catch-all HCons instance, with a call to the type equality test, and a case-despatching auxiliary class. It is semantically robust. I suppose you get used to the idiom. But in terms of helping type-level programming look like term-level programming, it's obtuse. (All that InstanceGuards are aimed at is blessing this idiom with some syntax sugar, so it looks like term-level guards.) And HList is working one element at a time, as it recursively descends into the list. The TypeError technique doesn't scale. What I really want to do is use 'flat' tuples as type-indexed anonymous/extensible records, putting newtypes to label the payloads: > me = (PersonId 41, PersonName "AntC") Again we must prevent repeated types: > notme = (PersonId 41, PersonName "AntC", PersonId 72) > class TIPle t -- Type Indexed Product tuples > instance TIPle (e1, e2) -- I just want e1 /~ e2, so: > instance (TypeError e1) => (e1, e1) -- exclude repeats This approach doesn't scale. Take the threeple: > instance (TypeError e1) => TIPle (e1, e1, e3) > instance (TypeError e1) => TIPle (e1, e2, e1) > instance (TypeError e2) => TIPle (e1, e2, e2) > instance TIPle (e1, e2, e3) -- OK, elements distinct by elimination Arguably I should also have > instance (TypeError e1) => (e1, e1, e1) The fourple case needs 6, arguably 9 exclusionary instances. I could use the nowadays HList idiom: > instance (TypeEq e1 e2 b1, TypeEq e1 e3 b2, TypeEq e2 e3 b3, > TIPleCase (b1, b2, b3) (e1, e2, e3) ) > => TIPle (e1, e2, e3) > instance TIPleCase (False, False, False) (e1, e2, e3) > -- TypeError instance(s) optional Perhaps I could use a type family with (~) constraint > instance (Equal e1 e2 ~ False, Equal e1 e3 ~ False, Equal e2 e3 ~ False) > => TIPle (e1, e2, e3) Note I've only talked so far about validating a TIPle, we want a whole bunch of methods for extending/projecting/ merging and comparing TIPles, and the classic record subtype relationship. With classes over two TIPLes there's a combinatorial explosion. So what you do is convert tuples to HLists, do all the operations on the HList, convert the result back to tuple. > > OK, concrete example: > > I'm afraid I don't see the concrete example. > But it looks like the example you give is one > motivating instance guards... It was trying to show: with CTFs (and presumably closed classes) there's an explicit or implicit TypeError catch-all instance at the end of the chain of `else`s. (It seems InstanceChain `fails` doesn't suffer this.) So the example showed I _didn't_ want that behaviour. AntC

2 1

Re: [Haskell-cafe] STG Program to invoke rule 17?
by Kei Davis 06 Jun '17

06 Jun '17

On 06/06/2017 06:00 AM, haskell-cafe-request(a)haskell.org wrote: > [Haskell-cafe] STG Program to invoke rule 17? This isn't a proper answer to your question, but I found the "fast curry" paper to be more useful for understanding STG http://community.haskell.org/~simonmar/papers/evalapplyjfp06.pdf -- Kei Davis Applied Computer Science Group CCS-7, Mail Stop B287 Los Alamos National Laboratory Los Alamos, NM 87545, U.S.A.

1 0

Re: [Haskell-cafe] Bug in GHC or cabal-install?
by Ivan Lazar Miljenovic 06 Jun '17

06 Jun '17

On 6 June 2017 at 07:55, Henk-Jan van Tuyl <b.vantuyl1(a)upcmail.nl> wrote: > > wxc/setup.hs uses versionBranch from Cabal[0]; the function versionBranch is > not in Cabal 2, that is why I added "Cabal < 2" to wxc.cabal. When > installing wxc the first time, the right version of Cabal is picked, when > "cabal install" is invoked a second time, GHC tries to compile wxc/setup.hs > again, but with the wrong version of Cabal (note: the release candidate of > GHC comes with Cabal 2) > > [0] > https://hackage.haskell.org/package/Cabal-1.24.2.0/docs/Distribution-Make.h… If you look at the source for this module, you'll see that it isn't defined in there; it's actually from Data.Version in base. > > > > On Mon, 05 Jun 2017 04:58:05 +0200, Ivan Lazar Miljenovic > <ivan.miljenovic(a)gmail.com> wrote: > >> I don't think it's a problem with Cabal, but the version of base going >> by the error: versionBranch is from base, and that error message is >> talking about compiling the setup.hs from wxc. >> >> On 5 June 2017 at 12:03, Henk-Jan van Tuyl <b.vantuyl1(a)upcmail.nl> wrote: >>> >>> >>> The strange thing is, that the right version of Cabal is picked, the >>> first >>> time wxc is compiled. But when invoking cabal-install the second time, >>> the >>> setup-depends section seems to be ignored (or at least the Cabal < 2 >>> part). >>> This does not happen with GHC 8.0.2 >>> >>> (By the way, cabal-install tries to compile setup.hs again, even though >>> nothing has changed.) >>> >>> Regards, >>> Henk-Jan van Tuyl >>> >>> >>> >>> On Sun, 04 Jun 2017 13:39:17 +0200, Ivan Lazar Miljenovic >>> <ivan.miljenovic(a)gmail.com> wrote: >>> >>>> This is from a limitation/bug with Cabal-the-library, in that there >>>> are typically no dependency checks for custom Setup.[l]hs >>>> configurations. >>>> >>>> wxc has such a custom one: >>>> http://hackage.haskell.org/package/wxc-0.92.3.0/src/Setup.hs >>>> >>>> versionBranch is from Data.Version in base, and it appears that the in >>>> this GHC pre-release there's been a change in base that removed this >>>> function. >>>> >>>> On 4 June 2017 at 19:45, Henk-Jan van Tuyl <hjgtuyl(a)chello.nl> wrote: >>>>> >>>>> >>>>> >>>>> L.S., >>>>> >>>>> I am trying the prerelease of GHC, version 8.2.0.20170507 >>>>> >>>>> I adapted wxHaskell to the new packages that come with the new GHC and >>>>> it >>>>> compiles now, but only the first time. If I compile it a second time, >>>>> even >>>>> if nothing has changed, the information from the custom-setup section >>>>> of >>>>> the wxc.cabal file seems to be forgotten. This section looks like this: >>>>> >>>>> custom-setup >>>>> setup-depends: >>>>> base, >>>>> Cabal < 2, >>>>> containers, >>>>> bytestring, >>>>> split, >>>>> process, >>>>> directory, >>>>> filepath >>>>> (I am using cabal-install 1.24.0.2) >>>>> >>>>> Output from the second time I try to install wxHaskell: >>>>> >>>>>> cabal install --force-reinstalls --reinstall wxdirect wxc wxcore wx >>>>> >>>>> >>>>> >>>>> [1 of 1] Compiling Main ( >>>>> X:\Temp\wxHaskell\wxcore\dist\setup\setup.hs, >>>>> X:\Temp\wxHaskell\wxcore\dist\setup\Main.o ) >>>>> Linking X:\Temp\wxHaskell\wxcore\dist\setup\setup.exe ... >>>>> [1 of 1] Compiling Main ( >>>>> X:\Temp\wxHaskell\wxc\dist\setup\setup.hs, >>>>> X:\Temp\wxHaskell\wxc\dist\setup\Main.o ) >>>>> >>>>> X:\Temp\wxHaskell\wxc\dist\setup\setup.hs:505:61: error: >>>>> Variable not in scope: versionBranch :: Version >>>>> -> >>>>> [a0] >>>>> | >>>>> 505 | full_ver = (concat . intersperse "." . map show . >>>>> versionBranch) ver >>>>> | >>>>> ^^^^^^^^^^^^^ >>>>> >>>>> This error message indicates that the wrong version of Cabal (2.0) is >>>>> used >>>>> to compile the wxcore setup.hs >>>>> It looks like a cabal-install bug, but this does not happen when I >>>>> use GHC 8.0.2; should I write a GHC bug ticket? >>>>> >>>>> Regards, >>>>> Henk-Jan van Tuyl > > > -- > Folding@home > What if you could share your unused computer power to help find a cure? In > just 5 minutes you can join the world's biggest networked computer and get > us closer sooner. Watch the video. > http://foldingathome.stanford.edu/ > > > http://Van.Tuyl.eu/ > http://members.chello.nl/hjgtuyl/tourdemonad.html > Haskell programming > -- -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com http://IvanMiljenovic.wordpress.com

2 3

Collecting examples where GHC generates unintuitive error messages
by Siddharth Bhat 06 Jun '17

06 Jun '17

Hello all, A discussion of GHC and error messages came up on ghc-devs. I'd like to give back to the community and try to improve this part of GHC. So, I created a repo to collect error messages ( https://github.com/bollu/hask-error-messages-catalog) That way, there's some concrete context for anyone who's working on the error messages subsystem of GHC. Elm does this as well (https://github.com/elm-lang/error-message-catalog) though they catalogue *all* errors. I'd be grateful for short examples where GHC generates unintuitive error messages, and perhaps a short explanation of what *would* be useful if possible. If you do have certain examples, please either open a pull request against the repository, or post a snippet on the mailing list. Thanks for the help, ~Siddharth -- Sending this from my phone, please excuse any typos!

2 2

[ANN] Schedule for Haskell Hackathon in Freiburg, Germany
by Alexander Thiemann 06 Jun '17

06 Jun '17

Dear Haskellers, the schedule for the Haskell Hackathon taking place in Freiburg, Germany this year is now online ( https://wiki.haskell.org/HacFreiburg2017 ) and we still have spots available. Register here: https://goo.gl/LDIQlw == Details: When: Friday 4 August 2017 - Sunday 6 August 2017 Where: Faculty of Engineering, University of Freiburg, Germany (https://goo.gl/maps/ZcHWLpMPhtj)Info page: https://wiki.haskell.org/HacFreiburg2017 Organizers: Peter Thiemann, Alexander Thiemann, Stefan Wehr == HacFreiburg is another Haskell Hackathon, where Haskell programmers from all around the world meet in Freiburg, Germany, to discuss, hack together and improve the Haskell infrastructure. We welcome all programmers interested in Haskell, beginners and experts! The Haskell Hackathon in Freiburg is part of the "Sommercampus 2017" (https://sommercampus.fachschaft.tf/en/) organized by the Faculty of Engineering at the University of Freiburg. Hope to see you there, Alex (with Peter and Stefan)

1 0

[ANN] mercury-api-0.1.0.0 (for RFID readers)
by Patrick Pelletier 05 Jun '17

05 Jun '17

https://hackage.haskell.org/package/mercury-api https://github.com/ppelleti/hs-mercury-api This package is a Haskell binding to the "Mercury API" C API for ThingMagic RFID readers. It is especially geared toward the SparkFun Simultaneous RFID Reader board, which uses ThingMagic's M6e Nano module, but it should work with other ThingMagic readers. (Though currently, only support for serial readers is compiled in.) Most of the function and type names are the same as their counterparts in the C API, with the TMR_ prefix dropped. For more in-depth, language-independent documentation of Mercury API, see Mercury API Programmers Guide, available from the "Manuals & Firmware" page, below. This package includes a copy of the Mercury API C library, so no external libraries are necessary. Several small bug fixes have been applied to the included version of the library. (I have submitted these patches upstream, but I don't know if or when they will be included in the official version.) The Haskell binding doesn't support background reads. I recommend that you just spawn a new Haskell thread and do foreground reads instead. Currently, only support for the serial reader is compiled in, but it probably wouldn't be too hard to enable LLRP support. (I don't have any way to test LLRP, however, as the M6e Nano doesn't support it.) On Mac OS X, be sure to use the serial device that starts with "/dev/cu.", not the serial device that starts with "/dev/tty.". Only some parameters and some tagops are currently supported in the Haskell binding. (There are a lot of them, and I only implemented the ones I needed.) If you need support for additional parameters or tagops, please file an issue in GitHub and I will add them. I have tested this package on Linux, Mac OS X, and Windows, using the SparkFun board. Additional resources: SparkFun Simultaneous RFID Reader: https://www.sparkfun.com/products/14066 ThingMagic Manuals & Firmware: http://www.thingmagic.com/index.php/manuals-firmware

1 0

STG Program to invoke rule 17?
by Siddharth Bhat 05 Jun '17

05 Jun '17

I'm reading the original STG paper <https://www.dcc.fc.up.pt/~pbv/aulas/linguagens/peytonjones92implementing.pdf> and implementing it along the way. (Raw link to paper: https://www.dcc.fc.up.pt/~pbv/aulas/linguagens/peytonjones92implementing.pdf ) I'm not able to figure out how to invoke rule 17 at all. This rule is to update a function call which calls another function. I've tried creating examples, but all of them wind up invoking the constructor update rule. ╰─$ cat stg-programs/updatable-fn-calls.stg define nu = {} \n {x, y, w, z} -> x {}; define main = {} \n {} -> let x = {} \n {} -> One {}; y = {} \n {} -> Two {}; // closure to update update = {x, y} \u {} -> nu {x, y, y, y}; // have something in argument stack kickstart = {update} \n {a, b} -> update {}; // make sure this is never evaluated bottom = {} \n {} -> bottom {} in case (kickstart {bottom, bottom}) of One {} -> Done {}; This was a program I tried, hoping that the "kickstart" function would ensure that there is something on the argument stack, so that when "nu" is entered, the rule would trigger. However, in my toy STG implementation here (simplexhc link) <https://github.com/bollu/simplexhc> (Raw: https://github.com/bollu/simplexhc) the rule is not triggered. You can run it with: $ stack build && stack exec simplexhc -- stg-programs/updatable-fn-calls.stg I believe I have either misunderstood the rule or mis-implemented it. So if someone could point me to a reference of how to trigger the rule, I'd be very thankful. I'd like to have some intuition on the rule and "why it works". Cheers, ~ Siddharth -- Sending this from my phone, please excuse any typos!

1 0

Re: [Haskell-cafe] Instance Chains selection by class membership [was: [ghc-proposals/cafe] Partially applied type families]
by Anthony Clayden 05 Jun '17

05 Jun '17

> > On Sun Jun 4 13:11:47 UTC 2017, J. Garrett Morris wrote: > > ... > > You keep talking about guarding instances or equations. > > Guards are equivalent to closed type families, > > I think not. They're somewhere between CTFs and Instance > Chains. > In that guarded instances are not closed. > Which also appears to be your claim wrt Instance Chains. > A further difference is wrt class instances and FunDeps. AFAICT, the closed class instances/Partiality paper is expecting no FunDeps, but using Assoc types within the class to achieve the same effect. I agree with that long-term aim, so the following applies to both guarded class instances and guarded type instances. The dreaded "Instances inconsistent with FunDeps" error can be boiled down to: > class TypeEq a b p | a b -> p > instance TypeEq a a HTrue > instance TypeEq a b HFalse The check for FunDep consistency unifies the class parameters on LHS of FunDep, yielding subsititution { a ~ b }. Then applies that substitution to rhs. yielding { HTrue ~ HFalse } doesn't hold, so inconsistency. GHC allows you to put this instead: > instance TypeEq a a HTrue -- same > instance (p ~ HFalse) => TypeEq a b p The consistency test compares { p ~ HTrue }, and apparently sees those as unifiable, despite the (~ HFalse) constraint. There are those [for example, Iavor], who think this should still count as inconsistent. So it works (and has consistently since 2004), but seems iffy. Furthermore the bare typevar `p` breaks the Coverage Conditions, (again despite the (~ HFalse) constraint grr! So you need UndecidableInstances, which apparently is not as benign as heretofore thought. With InstanceGuards it goes like this: class {-# INSTANCEGUARDS #-} TypeEq a b p | a b -> p instance TypeEq a a HTrue -- same instance TypeEq a b HFalse | a /~ b Now the consistency check: unifies the class parameters on lhs of FunDep, yielding { a ~ b } as before; then substitutes into the guard, yielding { a /~ a } -- a contradiction. So it doesn't need to check the consistency of the result. Because the 'arguments' to the FunDep are apart. Notice the side-benefit: by putting explicit HFalse, we haven't broken the Coverage Conditions, so don't need UndecidableInstances. The guarded type family goes likewise: > type family {-# INSTANCEGUARDS #-} Equals a b :: Bool > type instance Equals a a = True > type instance Equals a b | a /~ b = False AntC

1 0

Re: [Haskell-cafe] [ghc-proposals/cafe] Partially applied type families
by Anthony Clayden 05 Jun '17

05 Jun '17

> On Fri Jun 2 13:20:13 UTC 2017, Richard Eisenberg wrote: > > On Jun 2, 2017, at 3:22 AM, Anthony Clayden wrote: > >> I hereby pronounce > >>> instance TypeError ... => C Int Bool > >> > >> as "not an instance". ... > > > > Hmm. I'd be interested how you're going to stop > > the compiler matching some usage site to it. > > That's what TypeError does. When the compiler matches a > use site, it issues an error. I would imagine that's the > behavior you want. No. I want to leave the class open, so I can add other instances (possibly in a different module). If I protect instances in this module with guards, the compiler can satisfy itself that the other modules' instances do not overlap. > Can you write a concrete example of something you'd like > to do that the current machinery doesn't? > OK let's recap the Expression Problem first. There are two legs: * We want to freely add methods over a set of datatypes. (Problematic in OOP, because the methods are embedded in the objects.) In Haskell we can declare a new class with new method(s), and give instances over those datatypes. * We want to freely add constructors, and expand existing classes/methods to cover. That's not so easy in Haskell. The usual work-round is to make each constructor a new datatype. Then we can use the instance mechanism to extend classes/methods. ("Usual" for example with DSL's to expand the AST.) If you have closed type families/classes (esp in an imported/library module), you're blocked from extending it for new datatypes. Now apparently Instance Chains don't suffer this, the `fails` triggers a search for other instances in other chains. Garrett in an earlier message quoted section 3.1.1 of the paper "a class can be populated by multiple, non-overlapping instance chains, where each chain may contain multiple clauses". Unfortunately I can find no examples of using this feature, so I'm a bit unsure how it goes. We'd know the chains are non-overlapping because they'd chain over distinct datatypes, I imagine. And I thought that's what we were getting with CTFs, but the implementation fell short of my expectations. I wanted (when I suggested the `where`-style syntax): > module A > type family F a b -- full stop! > type instance F (T1 a) b where > ... -- overlapping equations within T1 > > module B > type instance F (T2 c) d where > ... -- overlapping equations within T2 Those closed instances in distinct modules are provably non-overlapping, because of the different type constructor. (By the same rules as currently, for apartness of instance heads. All equations within the where-group must unify with the instance head.) So then this (current) syntax would be a shorthand: > type family G e f where > ... -- total equations for G for the author of `G` who deliberately wanted to prevent anybody expanding the family. i.e shorthand for > type family G e f > type instance G e f where > ... Fair enough, that's a common requirement. But all we got in the implementation was that blitz-all style. (I'm grumpy.) And according to Garrett's survey, 15% of Hackage would be grumpy too. OK, concrete example: within the HList framework > data HNil = HNil > data HList e l = HList e l > -- deliberately not using DataKinds the Hlist paper discusses various approaches for indexing the payloads `e` within the list. Suppose (eliding a lot of detail) I choose Type-Indexed Products like > newtype PersonId = PersonId Int > newtype PersonName = PersonName String > ... > me = HCons (PersonId 41) $ HCons (PersonName "AntC") HNil And type indexed `Has` predicate needing overlaps: > class Has e l ... > -- no instance for HNil > instance Has e (HCons e l) ... > instance (Has e l') => Has e (HCons e' l') ... That's standard HList TIP, let's assume it's in a library/module. Another style of carrying the payload is type labels. To mix these styles, I need a way to cons a labelled element: > data AstroSign = AstroSign > ... > data HConsLab lab e l = HConsLab lab e l > > me2 = HConsLab AstroSign 12 me This deliberately allows the payload to be an ad-hoc type. Now I need a Has instance: > instance Has lab (HConsLab lab e l) ... > instance (Has lab l') => Has lab (HConsLab lab' e' l') ... Again relies on overlap. No danger of clashing with the vanilla HCons style, because labels are a distinct set of types. IOW this is fine: > you = HCons (PersonId 73) $ HCons (PersonName "rae") > $ HConsLab AstroSIgn 7 HNil > -- instances for the type of `you` > -- (Has you PersonId, Has you PersonName, Has you AstroSign) I can do all this now with stand-alone instances. But I have to be careful to keep my overlaps well-behaved. With closed Type Families/the proposed Classes, I can't add those HConsLab instances. I want to continue current support for freely adding instances, but provide a mechanism to enforce no-overlaps. And I think guards achieve that with relatively lightweight syntax, avoiding hard-to-follow sequences of `else` ... AntC

2 1

Re: [Haskell-cafe] Bug in GHC or cabal-install?
by Ivan Lazar Miljenovic 05 Jun '17

05 Jun '17

I don't think it's a problem with Cabal, but the version of base going by the error: versionBranch is from base, and that error message is talking about compiling the setup.hs from wxc. On 5 June 2017 at 12:03, Henk-Jan van Tuyl <b.vantuyl1(a)upcmail.nl> wrote: > > The strange thing is, that the right version of Cabal is picked, the first > time wxc is compiled. But when invoking cabal-install the second time, the > setup-depends section seems to be ignored (or at least the Cabal < 2 part). > This does not happen with GHC 8.0.2 > > (By the way, cabal-install tries to compile setup.hs again, even though > nothing has changed.) > > Regards, > Henk-Jan van Tuyl > > > > On Sun, 04 Jun 2017 13:39:17 +0200, Ivan Lazar Miljenovic > <ivan.miljenovic(a)gmail.com> wrote: > >> This is from a limitation/bug with Cabal-the-library, in that there >> are typically no dependency checks for custom Setup.[l]hs >> configurations. >> >> wxc has such a custom one: >> http://hackage.haskell.org/package/wxc-0.92.3.0/src/Setup.hs >> >> versionBranch is from Data.Version in base, and it appears that the in >> this GHC pre-release there's been a change in base that removed this >> function. >> >> On 4 June 2017 at 19:45, Henk-Jan van Tuyl <hjgtuyl(a)chello.nl> wrote: >>> >>> >>> L.S., >>> >>> I am trying the prerelease of GHC, version 8.2.0.20170507 >>> >>> I adapted wxHaskell to the new packages that come with the new GHC and it >>> compiles now, but only the first time. If I compile it a second time, >>> even >>> if nothing has changed, the information from the custom-setup section of >>> the wxc.cabal file seems to be forgotten. This section looks like this: >>> >>> custom-setup >>> setup-depends: >>> base, >>> Cabal < 2, >>> containers, >>> bytestring, >>> split, >>> process, >>> directory, >>> filepath >>> (I am using cabal-install 1.24.0.2) >>> >>> Output from the second time I try to install wxHaskell: >>> >>>> cabal install --force-reinstalls --reinstall wxdirect wxc wxcore wx >>> >>> >>> [1 of 1] Compiling Main ( >>> X:\Temp\wxHaskell\wxcore\dist\setup\setup.hs, >>> X:\Temp\wxHaskell\wxcore\dist\setup\Main.o ) >>> Linking X:\Temp\wxHaskell\wxcore\dist\setup\setup.exe ... >>> [1 of 1] Compiling Main ( >>> X:\Temp\wxHaskell\wxc\dist\setup\setup.hs, >>> X:\Temp\wxHaskell\wxc\dist\setup\Main.o ) >>> >>> X:\Temp\wxHaskell\wxc\dist\setup\setup.hs:505:61: error: >>> Variable not in scope: versionBranch :: Version -> >>> [a0] >>> | >>> 505 | full_ver = (concat . intersperse "." . map show . >>> versionBranch) ver >>> | >>> ^^^^^^^^^^^^^ >>> >>> This error message indicates that the wrong version of Cabal (2.0) is >>> used >>> to compile the wxcore setup.hs >>> It looks like a cabal-install bug, but this does not happen when I >>> use GHC 8.0.2; should I write a GHC bug ticket? >>> >>> Regards, >>> Henk-Jan van Tuyl > > > > -- > Folding@home > What if you could share your unused computer power to help find a cure? In > just 5 minutes you can join the world's biggest networked computer and get > us closer sooner. Watch the video. > http://foldingathome.stanford.edu/ > > > http://Van.Tuyl.eu/ > http://members.chello.nl/hjgtuyl/tourdemonad.html > Haskell programming > -- -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com http://IvanMiljenovic.wordpress.com

1 0

Re: [Haskell-cafe] Instance Chains selection by class membership [was: [ghc-proposals/cafe] Partially applied type families]
by Anthony Clayden 05 Jun '17

05 Jun '17

> On Sun Jun 4 13:11:47 UTC 2017, J. Garrett Morris wrote: >> On Sun, Jun 4, 2017 at 1:00 PM, Anthony Clayden wrote: >> ... > You have reiterated a point that is made at length ... Good, so we're agreed that the 2010 paper is inconsistent to reject `(f :+: f)` but accept `((f :+: f) :+: f)`. > I shouldn't, however, have suggested in 2015 that > the deduplicated version is necessarily preferable. I don't follow. The 2015 version is consistent. > If you omit the deduplication constraints, you simply end > up with Leijen-style scoped rows [Leijen, TFP05] ... Ouch! Its "A novel aspect of this work is that records can contain duplicate labels, " is about the most blood-chilling claim I've seen in the many papers on records systems. It is true, though, compared to what you seem to suggest "effectively introducing a form of scoping over the labels. " If `((f :+: g) :+: (h :+: f))` is to be supported, what's the basis for preferring `f` to the left or right? > ... Of course, if, as we did in 2010, you use classes instead > of branching to implement elimination on variants, you have no way to > tell the difference between the two models of variants, .. Is the only point I was wanting to make: using a single class fails to separate concerns, in this example. >> I'm working on showing how the Swierstra encoding >> could be catered for in Haskell 2010 + MPTCs+TypeEq. > You keep talking about guarding instances or equations. > Guards are equivalent to closed type families, I think not. They're somewhere between CTFs and Instance Chains. In that guarded instances are not closed. Which also appears to be your claim wrt Instance Chains. > ... so of course they're sufficient to implement > Swierstra's encoding (following any of ...), (I was specifically aiming to implement using Haskell as at 2010, but let it pass ...) Yes any of these approaches are "sufficient". That's not in debate. > and will require auxiliary definitions and indirections Yes, see code I posted subsequent to your message. > that would not be required using instance chains. Huh? Your 2015 paper uses auxiliaries class `In` Figure 3 in the Instance Chains version. True that the 2010 paper uses no auxiliaries, but it thereby ends up inconsistent. What is "wrong" with using auxiliaries? (Again, in terms of readability.) AntC

1 0

Different results when building wxHaskell on Cabal and Stack
by Yotam Ohad 04 Jun '17

04 Jun '17

Hello cafe, Lately, I wanted to try wxHaskell, so I downloaded and install wxWidgets and added the necessary paths to %PATH%. The problem was that when trying to build, cabal would have no problem at all, while stack sends me into battle with my path, complaining about missing header and executable files and so on. I don't understand why stack is having such a hard time when cabal has no trouble at all. I know that they are not the same, but I still think that it is weird that stack is acting like that. Thanks for your help, Yotam

2 1

Re: [Haskell-cafe] Instance Chains selection by class membership [was: [ghc-proposals/cafe] Partially applied type families]
by Anthony Clayden 04 Jun '17

04 Jun '17

> On Sun Jun 4 12:00:21 UTC 2017, Anthony Clayden wrote: > I think this shows that using class instances > to both define methods and drive selection logic > can fail to separate concerns. Richard's been (quite correctly) prodding me to explain why I want a no-instance in places, rather than an `instance ,,, fails` or `instance (TypeError ... ) => ...` I think Figure 7 in Garrett's 2015 paper provides a case in point. I find that `type family Ifi` and its call line 5/6 above to be more like an exercise in obfuscated type-programming. `type family Into` doesn't observe kind-hygiene in the way we'd expect a term-level function to observe type-hygiene. Type families `Into` or Ifi` might properly return: * Refl | L lp | R rp -- that could be a DataKind (where `lp` or `rp` is from a recursive call to `Into`) * or `Nope` -- which is a Boolean DataKind (yeuch) Yes `Into` does need to chase down the data structure in order to return the correct L/R accessor. But it doesn't need to also encode failure in that way. The frustrating thing (for me as reader) is `type family IsIn` is looking ahead inside the data structure to find `f`. Isn't that enough lookahead and error detection? I want there to be no equation for `Into` returning `Nope`. So I want no Line 7, nor line 10, 13 in `type family Ifi`. I think I'd tackle it this way. Instead of `type family IsIn` returning a Boolean, > type family CountF f g :: Nat where > CountF f f = (S Z) > CountF f (g :+: h) = Plus (CountF f g) (CountF f h) > CountF f g = Z Then for `Into` I'd use a count-preparing helper function, (instead of `Ifi`) and avoid those `Nope` returns: > type family Into f g where > Into f f = Refl > Into f (g :+: h) = IntoLR f (g :+: h) (CountF f g) (CountF f h) > -- no fail case needed > > type family IntoLR f g (cg :: Nat) (ch :: Nat) > type instance Into' f (g :+: h) (S Z) Z = L (Into f g) > type instance Into' f (g :+: h) Z (S Z) = R (Into f h) > -- no fail case needed, no overlap, so not closed So if the counts return {Z, Z} or {S Z, S Z} or {S (S (S Z)), S (S (S (S Z)))}, etc, there's simply no instance for `IntoLR`. (If you want a helpful error message, of course easy enough to add failure instances.) For completeness, I'll give the Instance Guard version for `CountF` and `Into`: > type family {-# INSTANCEGUARD #-} CountF f g :: Nat > type instance CountF f f = (S Z) > type instance CountF f (g :+: h) | f /~ (g :+: h) > = Plus (CountF f g) (CountF f h) > type instance CountF f g | f /~ g, g /~ (_ :+: _) = Z > type family {#- INSTANCEGUARD -#} Into f g > type instance Into f f = Refl > type instance Into f (g :+: h) | f /~ (g :+: h) > = IntoLR f (g :+: h) (CountF f g) (CountF f h) Those families/instances could be Associated types, grounded in the class instances (also guarded). Now I can see my way to translating this into Haskell 2010. AntC

1 0

Instance Chains selection by class membership [was: [ghc-proposals/cafe] Partially applied type families]
by Anthony Clayden 04 Jun '17

04 Jun '17

[starting a new thread for this topic] > On Fri Jun 2 17:35:35 UTC 2017, J. Garrett Morris wrote: >> On Fri, Jun 2, 2017 at 2:34 PM, Anthony Clayden wrote: >> else f :<: g fails if f :<: g >> Haskell very strictly doesn't support instance contexts >> driving selection of instances. > Haskell instance selection ... > if you apply the same restriction to instance chains ... What was confusing me is that there's a fault in the instance definitions for the Swierstra encoding as appears in the 2010 Instance Chains paper. I see in your 2015 paper that's been fixed. But before I go on to discuss, is there a typo in the 2015 paper? Figure 6 line 6 shows a type family equation > IsIn f g = Yep That's supposed to mirror the Instance Chains solution Figure 3 line 6: > else f `In` g fails So Figure 6/line 6's `Yep` should be a `Nope`?? Ok what was the fault in the 2010 paper? It correctly failed `instance f :<: (f :+: f)`, because that's ambiguous as to whether the wanted `f` should match left or right of `:+:`. But it didn't fail `instance f :<: ((f :+: f) :+: f)`, because from the failure above, the left operand of the outer `:+:`, viz `(f :+: f)`, is not an instance. So `f :<: ((fail) :+: f)` succeeds. I think this shows that using class instances to both define methods and drive selection logic can fail to separate concerns. You wrote [on the GCD thread]: >>>>> Of course, you'll have an easier time of it >>>>> if you limit yourself to only considering type-level definitions, >>>>> and not the corresponding method definitions. >>>>> But doing so rather misses the point of instance chains. It seems to me that in the 2010 paper, the fault arises from considering only the method definitions and failing to pay attention to the type-level. And yes, I want to make an easy time as possible for the programmer -- both writing and especially reading code. The second approach in the 2015 paper using a case-preparing Type Family seems to me to cleanly impose a phase distinction first type-level calculation then class instance selection/method overloading. So my end-game is to be able to remove FunDeps from the language, in favour of class and instance contexts giving Type Families with Equality constraints. (By all means, let's encourage those Type Families to be Associated within classes, per your Partiality paper with Richard.) To achieve that we need better support for overlaps. We need to do that in an understandable way for the programmer. That is, the 'umble programmer like me, not needing an advanced PhD in abstruse type theory. I think Instance Guards help readability by putting the instance selection criteria all in the one place at the instance head; not reliant on the reader scanning through a prior chain of instances/elses. > ... there is no reason to imagine that using > either instance chains or closed type families > would be any obstacle to implementing them. [viz extensible variants/co-products] No I'm not suggesting any lack of capability. If anything, Instance Chains are _too_ powerful. I'm working on showing how the Swierstra encoding could be catered for in Haskell 2010 + MPTCs+TypeEq. That is, was achievable in GHC 2004. (I could do with a few extra milli-Olegs of brain power.) It's a debate about whether/why/how we introduce syntactic sugar into current capability vs introducing a heretofore avoided feature into type inference viz: type class membership driving instance selection, as opposed to currently: types driving instance selection. AntC

2 1

Avoiding orphan instances and dependency blowups
by Clinton Mead 04 Jun '17

04 Jun '17

Hi All Consider this common situation. 1. Class C in package A. 2. A data type D in package B. 3. There is a clear instance C D but: 4. We do not want A to depend on B as most users of A do not use B. 5. We do not want B to depend on A as most users of B do not use A. Currently the proposed solutions are: 1. Create a third package, say AB, that depends on both A and B, wrap D in a newtype, and define an instance there. 2. Create a third package, say AB, that depends on both A and B as above, but instead create an orphan instance C D in this package. 3. Just give in and either make A depend on B or B depend on A. None of these solutions seem very satisfying. The first one, wrapping D in a newtype, destroys much of the interoperability that is attempting to be achieved by defining the instance in the first place. The second solution uses orphan instances and for a variety of reasons many seem to suggest these should be avoided. The third option introduces a snowball of dependencies that the vast majority of the time will be completely unused. I've heard some conversations of changes to GHC to deal with this, like "authoritative instances" but nothing seems to have come of it? I thought to myself, maybe this is a problem that could be solved by the package manager, not GHC. Here's the draft of how this could work: 1. Create a package, AB, that depends on A and B, but passes an "option" to B, in this case "A". So the dependencies of AB are A and B(A). 2. The package B defines the instance C D, but wrapped in some preprocessor #ifdef style macros. 3. The package manager passes the requested flags to B during it's compilation, and those flags trigger the sections of code required to be compiled and also additional dependencies. 4. If a new package is installed adds to the flags of B, B is recompiled. This way, packages could define instances for each other but if those dependencies are not used, they do not need to be compiled. But the user has a way to explicitly activate the instances. My questions: 1. Is this a roughly okay idea? 2. Is there already a better way of doing what I'm proposing (perhaps through backpack which I don't know much about yet)? 3. Is there a way to make this happen currently in Stack or Cabal, perhaps with custom setup scripts, or will this need some significant changes to Stack/Cabal themselves? Clinton

1 0

Re: [Haskell-cafe] [ghc-proposals/cafe] Partially applied type families
by Anthony Clayden 04 Jun '17

04 Jun '17

Errk, braino! This: > data HNil = HNil > data HList e l = HList e l Should be: > data HNil = HNil > data HCons e l = HCons e l AntC

1 0

Re: [Haskell-cafe] [ghc-proposals/cafe] Partially applied type families
by Anthony Clayden 03 Jun '17

03 Jun '17

> On Fri Jun 2 17:35:35 UTC 2017, J. Garrett Morris wrote: >> On Fri, Jun 2, 2017 at 2:34 PM, Anthony Clayden wrote: >> Although your papers/Dissertation cite some of S&S's work, >> you seem unaware of type disequality guards. > Of course we were aware of inequality guards. > They are a special case of the observation in §2.3 > of the instance chains paper about unifying > but non-overlapping instances; §7 of that paper and §7.1 of my > dissertation discuss extending the formal treatment > to accept such instances. Then I'm sorry Garrett, but if any of those refs are intended to be talking about inequality guards, it's so oblique as to have failed to communicate. In particular, you fail to mention them in your dissertation §7.1, first bullet. Example: "The first challenge is to develop a method to represent negative syntactic constraints on types. For example, in the following instance chain > instance C (Maybe t) > else C t "the second clause can only apply to types that are not of the form Maybeτ for some type τ. To pursue this approach, we would need to develop representations and proof rules for such limitations on the instantiation of type variables." I would write that non-Maybe instance as: > instance C t | t /~ (Maybe _) -- underscore = anonymous I guess instance chain: > else C t fails if t == (Maybe tau) > -- but that must not introduce typevar `tau` to the environment. The S&S CHR approach did "develop proof rules" to type inequalities (according to the 2002 paper). An explicit inequality guard makes it easy to test whether two instances are apart. > My Hackage survey ("Using Hackage > to inform language design", Haskell 2010) > discovered that 85% of overlapping instances were > contained within the same module, ... Well of course they are! Putting overlapping instances in separate modules is disastrous, everybody knows that. There's a thorough write-up from SPJ here https://mail.haskell.org/pipermail/haskell-cafe/2010-July/080043.html That does not prove people _want_ to restrict the instances to a single module. They have no choice in practice. So I'm surprised there's as much as 15% of overlapping instances in separate modules. I shudder at the incoherence. If you surveyed a joinery and found everything held together with nails, that would reflect only that there were no screwdrivers on the premisses. > motivating the formalization of that > usage pattern with instance chains. No. I would say (to both Instance Chains and Closed Type Families/Classes): motivating to support something less restrictive. Viz the ability to write stand-alone instances, that can be verified to not overlap (taking guards into account), same approach as the classes in the standard libraries. (Note how the monad transformers library was re-architected, to avoid the dangers of importing overlaps.) AntC

1 0

Re: [Haskell-cafe] [ghc-proposals/cafe] Partially applied type families
by Anthony Clayden 03 Jun '17

03 Jun '17

> On Fri Jun 2 13:48:43 UTC 2017, Richard Eisenberg wrote: > I'm going to respond just to the few points that concern > me directly. > Thanks Richard, blige! there's a lot to catch up with. > > On Jun 2, 2017, at 9:34 AM, Anthony Clayden wrote: > >>> There's a persistent problem for the compiler > >>> testing for type equality: > >>> the usage sites must have the types grounded. > >>> It's often more successful to prove disequality. > > > > That's straight out of the HList paper [2], > > Section 9 "By chance or by design?". > > "We should point out however groundness issues. > > If TypeEq is to return HTrue, the types must be > > ground; TypeEq can return HFalse even for unground > > types, provided they are instantiated enough to > > determine that they are not equal." > > While this may be true for HList's TypeEq, it is not true > for closed type families. If we have > > > type family Equals a b where > > Equals a a = True > > Equals a b = False > HList's TypeEq is comparable from 2004!, using typeclasses/FunDeps/Overlaps: > class TypeEq a b p | a b -> p where > instance TypeEq a a HTrue > instance (p ~ HFalse) => TypeEq a b p The False instance needs bare typevar `p` so that it overlaps; consequently needs UndecidableInstances. (I've used (~), but that was a typecast class in 2004.) > then (Equals [a] [a]) will reduce to True, even if `a` is > universally bound. Indeed, even (Equals a a) will reduce > to True. So there is no groundness issue any more. > Great stuff! And that TypeEq behaves likewise now. I was trying to cast the discussion back to ~2010, the Instance Chains work. IIRC groundedness was still a difficulty then. > > > >> and also: > > > >>> I suspect that for the compiler, > >>> Instance Chains will be as problematic > >>> for type inference as with Closed Type Families: > >>> CTFs have a lot of searching under the covers > >>> to 'look ahead' for equations that can safely match. > > > > That's from Richard, particularly this comment [3]. > > The whole blog post is relevant here, I think. > > I'm not sure where you're getting "look ahead" from. > Closed type families -- and that post, as far as I can > tell -- don't discuss looking ahead. Instead, closed type > families are all about looking *behind*, Well, I think we're saying the same thing. Your last comment on that blog post links to the NewAxioms write-up. That has this example: > type family And (a :: Bool) (b :: Bool) where > And False a = False > And True b = b > And c False = False > And d True = d > And e e = e "All of these equations are compatible, meaning that GHC does not have to do the apartness check against the target." Faced with simplifying `And c False`, does GHC get stuck at the first or second equation, because it can't resolve `c` to `False` or `True`? No, it "looks ahead" to the third equation. Because it sees that if `And c False` unifies with either of the first two, it'll yield the same result `False`. Your comment on the blog post is "coincident overlap within closed type families (the new nomenclature for branched instances) would indeed be useful." I think it would be useful, too, for Instance Chains or Closed Classes. But there's a problem: Class instances must select method implementations, as well type improvement. So we need to fix on a specific instance, even though we only have `And c False`. > > I think the situation has changed with the introduction > > of Type Families. They weren't applicable in 2010. > > So not relevant to the Instance Chains paper. > My mistake: I meant to say "... introduction of Closed Type Families". > Type families were introduced in 2005, I believe. > At least, that's when the papers were written. Hmm, careful. 2005 was Assoc types only. The usually cited paper for Type Families is Schrivers et al 2008. Garrett's papers cite that, not the 2005, and I agree that's the full write-up. But the 2008 paper was written in parallel with development. The feature appeared in GHC after the paper. And it wasn't complete: we waited a long time to get Type Families/(~) in superclass constraints. (There were a couple of release which supported the syntax superclass, but it did nothing.) > I don't know what version of GHC first included them, > but I think it was before 2010. > Vintage ~2010 there was limited support for overlap in TF instances -- the equations had to be "confluent". (This is the (||) example near the top of your blog post, where you conclude "and we can just write || using separate instances, anyway." Yes you could just write separate instances in ~2010.) I don't see that Instance Chains has a comparable notion of "confluent" or "compatible". But perhaps I missed it. > > > > "Look ahead" is exactly what Richard is describing > > in the bulk of that blog post. > > I disagree here: ... See above AntC

1 0

listing include files in a cabal file
by Patrick Pelletier 03 Jun '17

03 Jun '17

I have some C code in my Cabal package, consisting of both *.c and *.h files. Obviously, the *.c files get listed in "c-sources". But I'm trying to figure out where to list the *.h files. Right now, I'm not listing them anywhere, and my package compiles just fine. According to the Cabal users guide, there is an "includes" field and an "install-includes" field. The "includes" field seems to only be relevant when compiling via C. And even when compiling via C, wouldn't the include already be picked up when it is part of the foreign declaration, e. g.: foreign import ccall unsafe "tmr_tag_data.h TMR_bytesToHex" c_TMR_bytesToHex :: Ptr Word8 -> Word32 -> CString -> IO () As for the "install-includes" field, I don't think my header files would need to be installed, because they're internal to my package. The package's interface is entirely in Haskell. Should I just put my include files in "extra-source-files", so they get added to the package, but otherwise aren't treated specially? Or should I be using "includes" and/or "install-includes"? Thanks, --Patrick

2 2

do I need to uninstall haskell-mode before installing intero?
by Dennis Raddle 03 Jun '17

03 Jun '17

I want to try intero with emacs/stack. I have been using haskell-mode. Do I need to uninstall it first--is there any potential conflict? Thanks, D

1 1

can this be done with stack?
by Dennis Raddle 02 Jun '17

02 Jun '17

Using stack, but I have a need to build lots of executables. **lots** and new ones all the time .. my application is music playback. I used to have a single executable for playing music, and used it for all compositions. I later found that I needed to do a lot of configuration specific to each composition, and that the most natural language for specifying all the data and functions specific to a composition was Haskell. That means I have a source file for every composition, in the same directory where I store that composition (as a Sibelius file). But a couple things. (1) they aren't in the stack tree, (2) I don't want to add every one of these to a cabal file. What is the best way to approach this goal? D

2 5

Re: [Haskell-cafe] [ghc-proposals/cafe] Partially applied type families
by Anthony Clayden 02 Jun '17

02 Jun '17

> On Fri Jun 2 10:26:16 UTC 2017, J. Garrett Morris wrote: > This conversation has become deeply mysterious to me. Hi Garrett, thank you for the opportunity to debate the ideas in Instance Chains, and correct any misunderstandings I might have gained. The interaction of Overlapping Instances with other Haskell features has been vexing for a long time. There have been many approaches. I find this continuing situation particularly frustrating, because it seems to me there was an answer in 2002 [1], whose effectiveness was confirmed by the HList work 2004 [2]. I've been banging this drum for a long time [4]. > I understand that you're revisiting arguments on the structuring of conditionals ... No. Until your comment yesterday re Dijkstra (thank you for the tip), I was continuing ideas in the Sulzmann and Stuckey Constraint Handling Rules approach [1]. Although your papers/Dissertation cite some of S&S's work, you seem unaware of type disequality guards. I think that's a significant oversight. > ... that were tried and discarded in the 70s; I can see why Dijkstra's ideas might be discarded for term-level calculation: * the impossibility of determining whether guards are mutually exclusive (that's a specie of the halting problem) * the deliberate non-determinacy But that first objection is not applicable for instances/guards, because they have a very simple semantic structure: pattern-match on the instance head, then type (dis-)unifiability test. The second is a definite plus-feature for instance selection. (Reflecting how GHC works today.) So I'm fully up with the programme of the great programmer. > what I don't understand is why you need > to repeatedly mischaracterize my work to do so. If I'm mischaracterising, I apologise. I note, though, you haven't demurred at my observation that instance chains need backtracking. I find backtracking far more unacceptable than indeterminacy. > For one example, I have no idea why you make the following claim: >> Nevertheless, I can only write one Instance Chain >> per class. So I can't (say in another module) >> introduce a new datatype with instances. > The instance chains paper is quite explicit in ruling out this > interpretation; when introducing the notion of chains, we wrote: > In ilab, a class can be populated by multiple, non-overlapping > instance chains, where each chain may contain multiple clauses > (separated by the keyword else). Then I apologise. The two chief examples in that paper (gcd and the Swierstra encoding) both show a final `else ... fails` branch with a catch-all instance head. Section 3.2 comments "..., closing the Gcd class." For the Swierstra encoding in particular, the algorithm requires the class to be total (it must be closed), so that the recursive descent test/validation for go-left/go-right can be determinate. > For another, you give a fanciful description of the problems that > might arise in implementing instance chains, including: I reject "fanciful". So I'm going to give citations. >> There's a persistent problem for the compiler >> testing for type equality: >> the usage sites must have the types grounded. >> It's often more successful to prove disequality. That's straight out of the HList paper [2], Section 9 "By chance or by design?". "We should point out however groundness issues. If TypeEq is to return HTrue, the types must be ground; TypeEq can return HFalse even for unground types, provided they are instantiated enough to determine that they are not equal." > and also: >> I suspect that for the compiler, >> Instance Chains will be as problematic >> for type inference as with Closed Type Families: >> CTFs have a lot of searching under the covers >> to 'look ahead' for equations that can safely match. That's from Richard, particularly this comment [3]. The whole blog post is relevant here, I think. > Luckily, both instance chains and closed type families have > formalizations that can be checked to evaluate these claims. Yes, Overlapping Instances has suffered for too long from under-/non-formalised semantics. What I'll be doing for Instance Guards is giving a translation into Haskell2010 + MPTCs __without__ overlaps. (I will need to assume, though, a type-level type equality test/total function. You've already commented that's easliy produced.) A serious weakness of Instance Chains, it seems to me, is it can't be translated to existing Haskell. > In neither case do we find either equality limited to ground types > or anything that should be construed as 'look ahead'. I think the situation has changed with the introduction of Type Families. They weren't applicable in 2010. So not relevant to the Instance Chains paper. "Look ahead" is exactly what Richard is describing in the bulk of that blog post. That is, looking down the sequence of instance equations, to see if any would match and be confluent. This significantly helps progress in inference. If Instance Chains aren't going to be doing that, that's another weakness. > Perhaps you're trying to refer to the use of > infinitary unification in checking apartness (but not in > checking equality) for closed type families? No, infinitary unification is a whole 'nother bag of spanners. I am still goggling at your joint paper with Richard. > Here again, not only is there no use of or need > for infinitary unification with instance chains, ... Good! > but I discussed this difference and its consequences > in my 2015 paper. OK. I've not yet got through that paper. What I do see in the 2010 paper (perhaps this has changed subsequently) is using typeclass membership to determine whether a type is a member of the __same__ class. This seems to be essential to the Swierstra encoding such as: > else f :<: (g :+: h) if f :<: g > else f :<: (g :+: h) if f :<: h Gloss: "f is related to (g :+: h), if f is related to g". And likewise for f related to h. So: * this needs look inside the ( :+: ) to see if f is related to g or to h, or to both (fail) or to neither (fail). And now you tell me there might be other instance chains for `:<:`, so the compiler has to work through them. * it breaks down the 'phase distinctions' in instance selection. I feel very queazy about a recursion like that at the class level. We can express Russell's paradox: > else f :<: g fails if f :<: g Haskell very strictly doesn't support instance contexts driving selection of instances. That is confusing for newbies, but it's for very good decidability reasons. > Finally, you make various claims about what is and is not a solution > to the expression problem which have no apparent relationship to any of > the existing work on the expression problem or its encodings. > ... Again, this is all laid out, with examples, in my 2015 paper. I was being brief. (And this post has gone on plenty long enough, too.) I'll come back and debate that point when I've worked through your 2015 paper. What's strongly motivating me with Haskell is getting the type system to cater for extensible/anonymous records. (I'm a Relational Theorist by trade.) Closed instances (be they Chains or Type Families, or the proposed Closed Classes) are just not going to hack it. Adam G for the Overloaded Records Fields work has eschewed Type Families in favour of FunDeps. That's because it needs to create instances 'on the fly'. Now he hasn't needed overlaps yet (ORF is at an early stage), but anonymous/extensible records will. Just like HList. AntC [1] Sulzmann & Stuckey 2002 "A Theory of Overloading", esp section 8.2 "Overlapping Definitions" [2] Kiselyov et al 2004 "Strongly Typed Heterogeneous Collections" [3] https://typesandkinds.wordpress.com/2013/04/29/coincident-overlap-in-type-f… [4] https://ghc.haskell.org/trac/ghc/wiki/NewAxioms/DiscussionPage

3 2

Haskell Weekly
by Taylor Fausak 02 Jun '17

02 Jun '17

Hello haskell-cafe! I am the Haskell Weekly editor. In the past, some people have expressed interest in receiving my newsletter on this mailing list. Is that something I should set up? If you're curious about Haskell Weekly, please check out the latest issue, which was published today: <https://haskellweekly.news/issues/57.html> I've also included issue 57 as plain text here. If you like what you see, head over to <https://haskelweekly.news> and subscribe! --- # Haskell Weekly ## Issue 57 Welcome to another issue of Haskell Weekly! Haskell is a purely functional programming language that focuses on robustness, concision, and correctness. This is a weekly summary of what’s going on in its community. - Realizing Hackett, a metaprogrammable Haskell <https://lexi-lambda.github.io/blog/2017/05/27/realizing-hackett-a-metaprogr…> > Almost five months ago, I wrote a blog post about my new programming language, Hackett, a fanciful sketch of a programming language from a far-off land with Haskell's type system and Racket's macros. [...] Hackett is not only real, it's working, and you can try it out yourself! - Imperative Haskell <http://vaibhavsagar.com/blog/2017/05/29/imperative-haskell/> > Why don't we do this all the time, when Haskell is at least a serviceable imperative language? Because writing imperative programs is hard! They don't compose as well, have less useful type signatures, and are harder to reason about. Getting away from those things is why we have Haskell to begin with! - A Haskell cross compiler for Android <https://medium.com/@zw3rk/a-haskell-cross-compiler-for-android-8e297cb74e8a> > Finally launching and running the application on the device, we are greeted with "Hello from Haskell". While the utility of this application is certainly questionable it illustrates the essential steps required to build, link and run an Android application calling a native Haskell function. - Smart data with conduits <https://mmhaskell.com/blog/2017/5/29/smart-data-with-conduits> > If you're a programmer now, there's one reality you'd best be getting used to. People expect you to know how to deal with big data. The kind of data that will take a while to process. The kind that will crash your program if you try to bring it all into memory at the same time. - Wire is hiring a Software Backend Developer (Operations) in Berlin, Germany (ad) <https://wire.softgarden.io/job/1022464?l=en> > Wire is an open source, end-to-end encrypted messenger for personal and business use. For our development center in Berlin we are hiring two Backend Haskell Developers. As Software Developer Backend Operations you will maintain our infrastructure, ensuring that it runs 24/7. Check out our jobs at wire.com/jobs and our open source code on github.com/wireapp. - What we talk about when we talk about types <https://joyofhaskell.com/posts/2017-05-31-is-vs-has.html> > These dialogues somewhat pedantically dissect what we mean when we say a type is an instance of a type class or a type has an instance of a type class and why. Through the course of conversation, we touch on the nature of types, type constructors, and type classes, which led to us talking about math, set theory and category theory, and what they have to do with types and type classes. - The partial options monoid <https://medium.com/@jonathangfischoff/the-partial-options-monoid-pattern-31…> > Parsing options is not the hardest problem. However, if you do not create a pattern the rest of your team can follow, your program can become a tangled mess of random file reads, environment variable lookups and unpredictable defaulting. The Monoid class is a rock solid abstraction for combining options. - Playing with lens-aeson <https://www.snoyman.com/blog/2017/05/playing-with-lens-aeson> > That works, but it's far from inspiring. We're declaring a Color data type simply for the purpose of writing a type class instance. But it feels pretty heavyweight to have to declare a data type and make a type class instance for just one use site. ### Packages of the week Several interesting packages were announced this week. Instead of picking one to feature, all four are this week's packages of the week! - double-pendulum-simulation <https://github.com/lotz84/double-pendulum-simulation> Simulates and renders a double pendulum system. - legion <https://github.com/aviaviavi/legion> Implements a simple block chain server that synchronizes nodes over the network. - prettyprinter <https://github.com/quchen/prettyprinter> Aims to end the Wadler/Leijen zoo dilemma by being a modern, well-documented pretty printer. - sitepipe <https://github.com/ChrisPenner/SitePipe> Generates static sites with plain values and less magic.

5 6

Re: [Haskell-cafe] [ghc-proposals/cafe] Partially applied type families
by Anthony Clayden 02 Jun '17

02 Jun '17

> On Fri Jun 2 02:32:39 UTC 2017, Richard Eisenberg wrote: > > > On May 31, 2017, at 12:31 AM, Anthony Clayden wrote: > > >> You could always view > >> > >>> instance TypeError ... => C Int Bool > >> > >> as sugar for > >> > >>> instance C Int Bool fails > > > > Yes I understand that. > > But no I don't want any instance. > > (Sugar on rotten fruit doesn't hide the smell.) > > I hereby pronounce > > > instance TypeError ... => C Int Bool > > as "not an instance". ... Hmm. I'd be interested how you're going to stop the compiler matching some usage site to it. > In other words, I'm not sure what > you're getting at here other than concrete syntax. > How does not having an instance differ > than the TypeError solution? Good question. I've been struggling to explain it. Re-reading the Instance Chains paper has clarified the issue for me. And looking at Garrett's later 'Variations on Variants' paper. (Clarified, because that's a non-solution.) It's the Expression Problem: Once I have a catch-all instance (even if it has an impossible-to-fulfill constraint) the compiler is committed to selecting that instance. I can't introduce a new data type and new instance for it, because it'll overlap the catch-all instance. IIUC, Instance Chain's 'fail' is more powerful, it triggers back-tracking to look for another instance that doesn't fail. But we don't want to introduce backtracking into Haskell search for instances. Nevertheless, I can only write one Instance Chain per class. So I can't (say in another module) introduce a new datatype with instances. Sometimes closed/chained instances are the right solution. (That's the case for HList, for example. But even there I'm not convinced. I might want as well as HNil, HCons, a constructor with explicit type-labelling.) But sometimes closed instances are not right. I would say that where closed instances are needed, you can still achieve that with a 'catch-all' stand-alone instance, suitably guarded, of course. So I disagree with Garrett: not only do Instance Chains fail to solve the expression problem, they actually exacerbate it. (Same for Closed Type Families, or Closed Class Instances.) > > OK. Perhaps you're seeing something I can't. > > To adapt your example from a parallel message, suppose: > > <snip> > > What you're getting at here is that there may be > interesting interplay between instance guards and > OverlappingInstances. Indeed. This would have to be worked > out (or left as an open question) in the proposal. > > Regardless, I think that hashing out this level of detail > here is the wrong place. ... OK, fair enough. > Put it in the proposal! That way, the ensuing > debate involves more of the community and > persists better. > Oh! that I had "Deserts of vast eternity" to write the thing. As it is, it's easier to tackle as bite-size pieces on the forum. AntC

3 2

Call for participation: Trends in Functional Programming, 19-21 june 2017 AND Trends in Functional Programming in Education, 22 june 2017, University of Kent, Canterbury
by Peter Achten 02 Jun '17

02 Jun '17

----------------------------- C A L L F O R P A R T I C I P A T I O N ----------------------------- ======== TFP 2017 =========== 18th Symposium on Trends in Functional Programming 19-21 June, 2017 University of Kent, Canterbury https://www.cs.kent.ac.uk/events/tfp17/index.html ========= TFPIE 2017 ======== Co-located with TFP, and included in the registration fee, is Workshop on Trends in Functional Programming in Education 22 June 2017 University of Kent, Canterbury https://www.cs.kent.ac.uk/people/staff/sjt/TFPIE2017/ The symposium on Trends in Functional Programming (TFP) is an international forum for researchers with interests in all aspects of functional programming, taking a broad view of current and future trends in the area. It aspires to be a lively environment for presenting the latest research results, and other contributions (see below). Authors of draft papers will be invited to submit revised papers based on the feedback receive at the symposium. A post-symposium refereeing process will then select a subset of these articles for formal publication. TFP 2017 will be the main event of a pair of functional programming events. TFP 2017 will be accompanied by the International Workshop on Trends in Functional Programming in Education (TFPIE), which will take place on 22 June. The TFP symposium is the heir of the successful series of Scottish Functional Programming Workshops. Previous TFP symposia were held in * Edinburgh (Scotland) in 2003; * Munich (Germany) in 2004; * Tallinn (Estonia) in 2005; * Nottingham (UK) in 2006; * New York (USA) in 2007; * Nijmegen (The Netherlands) in 2008; * Komarno (Slovakia) in 2009; * Oklahoma (USA) in 2010; * Madrid (Spain) in 2011; * St. Andrews (UK) in 2012; * Provo (Utah, USA) in 2013; * Soesterberg (The Netherlands) in 2014; * Inria Sophia-Antipolis (France) in 2015; * and Maryland (USA) in 2016. For further general information about TFP please see the TFP homepage. (http://www.tifp.org/) == SCOPE == The symposium recognizes that new trends may arise through various routes. As part of the Symposium's focus on trends we therefore identify the following five article categories. High-quality articles are solicited in any of these categories: Research Articles: leading-edge, previously unpublished research work Position Articles: on what new trends should or should not be Project Articles: descriptions of recently started new projects Evaluation Articles: what lessons can be drawn from a finished project Overview Articles: summarizing work with respect to a trendy subject Articles must be original and not simultaneously submitted for publication to any other forum. They may consider any aspect of functional programming: theoretical, implementation-oriented, or experience-oriented. Applications of functional programming techniques to other languages are also within the scope of the symposium. Topics suitable for the symposium include, but are not limited to: Functional programming and multicore/manycore computing Functional programming in the cloud High performance functional computing Extra-functional (behavioural) properties of functional programs Dependently typed functional programming Validation and verification of functional programs Debugging and profiling for functional languages Functional programming in different application areas: security, mobility, telecommunications applications, embedded systems, global computing, grids, etc. Interoperability with imperative programming languages Novel memory management techniques Program analysis and transformation techniques Empirical performance studies Abstract/virtual machines and compilers for functional languages (Embedded) domain specific languages New implementation strategies Any new emerging trend in the functional programming area If you are in doubt on whether your article is within the scope of TFP, please contact the TFP 2017 program chairs, Scott Owens and Meng Wang. == BEST PAPER AWARDS == To reward excellent contributions, TFP awards a prize for the best paper accepted for the formal proceedings. TFP traditionally pays special attention to research students, acknowledging that students are almost by definition part of new subject trends. A student paper is one for which the authors state that the paper is mainly the work of students, the students are listed as first authors, and a student would present the paper. A prize for the best student paper is awarded each year. In both cases, it is the PC of TFP that awards the prize. In case the best paper happens to be a student paper, that paper will then receive both prizes. == PAPER SUBMISSIONS == Acceptance of articles for presentation at the symposium is based on a lightweight peer review process of extended abstracts (4 to 10 pages in length) or full papers (20 pages). The submission must clearly indicate which category it belongs to: research, position, project, evaluation, or overview paper. It should also indicate which authors are research students, and whether the main author(s) are students. A draft paper for which ALL authors are students will receive additional feedback by one of the PC members shortly after the symposium has taken place. We use EasyChair for the refereeing process. Papers must be submitted at: https://easychair.org/conferences/?conf=tfp17 Papers must be written in English, and written using the LNCS style. For more information about formatting please consult the Springer LNCS web site: http://www.springer.com/computer/lncs?SGWID=0-164-6-793341-0 == INVITED SPEAKERS == Conor McBride University of Strathclyde (UK) Cătălin Hriţcu INRIA Paris (FR) Heather Miller Northeastern University (USA) and EPFL (CH) == IMPORTANT DATES == Submission of draft papers: 5 May, 2017 Notification: 12 May, 2017 Registration: 11 June, 2017 TFP Symposium: 19-21 June, 2017 Student papers feedback: 29 June, 2017 Submission for formal review: 2 August, 2017 Notification of acceptance: 3 November, 2017 Camera ready paper: 2 December, 2017 == PROGRAM COMMITTEE == Co-Chairs Meng Wang University of Kent (UK) Scott Owens University of Kent (UK) PC Jeremy Yallop University of Cambridge (UK) Nicolas Wu University of Bristol (UK) Laura Castro University of A Coruña (ES) Gabriel Scherer Northeastern University (US) Edwin Brady University of St Andrews (UK) Janis Voigtländer Radboud University Nijmegen (NL) Peter Achten Radboud University Nijmegen (NL) Tom Schrijvers KU Leuven (BE) Matthew Fluet Rochester Institute of Technology (US) Mauro Jaskelioff CIFASIS/Universidad Nacional de Rosario (AG) Patricia Johann Appalachian State University (US) Bruno Oliveira The University of Hong Kong (HK) Rita Loogen Philipps-Universität Marburg (GE) David Van Horn University of Marylan (US) Soichiro Hidaka Hosei University (JP) Michał Pałka Chalmers University of Technology (SE) Sandrine Blazy University of Rennes 1 - IRISA (FR)

1 0

Re: [Haskell-cafe] [ghc-proposals/cafe] Partially applied type families
by Anthony Clayden 02 Jun '17

02 Jun '17

> On Tue May 30 19:43:30 UTC 2017, Richard Eisenberg wrote: > > On May 24, 2017, at 3:13 AM, Anthony Clayden wrote: > ... Some functions are defined by an ordered set of equations. > Some (that is, class methods) are defined by > an unordered set of equations, perhaps distributed across modules. > Both models are useful. Sure. Let a 100 schools of thought contend. >>> ... [equality constraints and equality guards are] >>> different, but I think the equality guard is useless >> I agree adds nothing over repeating the typevar. And I've already agreed the potential for confusion with (~) constraints. So noted. I'll include it in the proposal, where a wider audience can bikeshed. >> I see two main uses/benefits: >> 1. avoids the need for non-linear patterns in the head > > Agreed that it would do this. But why is that important? > I was in part thinking of your wondering-out-loud earlier in the Partially applied thread https://mail.haskell.org/pipermail/haskell-cafe/2017-May/127078.html If we want to part-apply a type Fun which has a non-linear lhs, how does that go with your case-equation style? Adapting that earlier example: > type family F a b where > F a a = () -- added an equation > F Int b = b > F a Bool = a would really mean > type F a b = case a of > _ -> case b of -- ?? _ match-all > a -> () -- ?? re-using typevar a > Int -> b > _ -> case b of > Bool -> a > _ -> F a b > > 2. visually points up the 'non-apartness' vs an, um. > > "apartness guard" > > > > (When I was figuring out Andy A-M's 2013 example, > > I rewrote the non-linear patterns with ~ guards, > > so I could figure out the apartness guards > > esp for the semi-apart instances. > > I posted the later workings to your blog > > Somehow, this is more convincing. But I'm still not > convinced on this point. Happily, you don't need to > convince me -- put in the proposal what you like and then > we can debate a concrete design. > > >> [except as a type-level "let", I suppose].) > > They would work as "let", I think: > > > instance Either a a | a ~ SomethingBigAndUgly where ... > > Note that the `a` is not introduced in the guard. Ah, OK. I get you. Equally that could be > instance Either a b | a ~ b, a ~ SomethingBigAndUgly where .. > > > Ok thanks, yes [TypeError] helps. > > Nevertheless it seems disergonomic > > to write an instance for a type-equal case, > > even with a helpful error message; > > when what you want is: no such instance. > > You could always view > > > instance TypeError ... => C Int Bool > > as sugar for > > > instance C Int Bool fails Yes I understand that. But no I don't want any instance. (Sugar on rotten fruit doesn't hide the smell.) There are (or at least used to be) all sorts of side-effects from there in effect being an instance that matched. > > What I can see will be awkward is backwards > > compatibility: can a class/type family with guards > > coexist with CTFs and with classes using overlap? > > Sure. There would be no problem with this. The new idea is > just that: new. I don't see it as getting rid of anything > we already have. Perhaps some day we could think about > removing OverlappingInstances, but we certainly don't have > to do that at the same time as introducing instance > guards. (I do like that name, too.) > OK. Perhaps you're seeing something I can't. To adapt your example from a parallel message, suppose: > module A > > class {-# INSTANCEGUARDS #-} C a where ... > instance C (Maybe a) | a /~ Int where ... > instance C (Maybe Int) where ... > > module B > -- knows nothing of InstanceGuards > import A > > instance {-# OVERLAPPABLE #-} C (Maybe Bool) where ... I want to reject that `(Maybe Bool)` instance. Even though it would legitimately be OVERLAPPABLE by (Maybe a) (that is, without the `a /~ Int` guard). Furthermore I might want a class to be InstanceGuarded, even though the instances I declare don't themselves need guards. (That is, I'm wanting to avoid 'future' overlaps in modules that import the class.) > > > > I'll have a crack at the proposal. > > Great. Thanks! (Likely I'll need some help with the protocols.) AntC

2 1

Vim syntax file typo
by Matthew Fernandez 02 Jun '17

02 Jun '17

Hello Haskell Cafe, The attached patch fixes what looks to be a typo in a comment in the Haskell Vim syntax file. Pretty trivial, but I'm mailing it to this list as it's listed as the maintainer of the file and I believe that's the Vim policy. Please let me know if there's somewhere more appropriate I should send this or if you'd prefer me to just submit it as a pull request on the Vim Github. Thanks, Matt

1 1

Re: [Haskell-cafe] Type-level GCD [Instance Chains]
by Anthony Clayden 01 Jun '17

01 Jun '17

> On Thu Jun 1 12:44:32 UTC 2017, Anthony Clayden wrote: >> For example, consider the simple chain: >> >> class C t u where f :: t -> u >> instance C Int Int where >> f = M >> else C t u where >> f = N Ah, silly me. There's a neater way to achieve that. > I think Instance Guards both have less lexical clutter, > and help the compiler see what's coherent: > instance C Int Int where f = M > instance C t u | (t, u) /~ (Int, Int) where f = N AntC

1 0

Re: [Haskell-cafe] Type-level GCD [Instance Chains]
by Anthony Clayden 01 Jun '17

01 Jun '17

> On Thu Jun 1 09:51:25 UTC 2017, J. Garrett Morris wrote: >> On Thu, Jun 1, 2017 at 3:23 AM, Anthony Clayden wrote: >> No, my concern is readability. > Well, presumably from the readability perspective, > the point is that instance chains allow you to express > Euclid's algorithm directly, following the > mathematical presentation, ... What I see in the mathematical presentation, is that each equation is stand-alone, with a guard. I guess we'll just agree to differ on the readability of the Haskell. (What if Euclid had taken up lazy functional programming ..?) >> I must admit I hadn't though of stand-alone instances >> as being like rows in truth tables. >> They're like separate lines of equations, >> each guarded by a condition. > I sense a Dijkstra-like argument that we should avoid writing > "else" or "otherwise", ... If I'm in the company of Dijkstra and Euclid, that's good enough for me. > ... we generally hope for programs to have meanings Yes we do. > and thus for instance resolution to be coherent. I agree the current (under-/non-)specified rules for overlap don't help us reason much about coherence. (But see my post on the cafe last month wrt "Well-behaved instances".) > For example, consider the simple chain: > > class C t u where f :: t -> u > instance C Int Int where > f = M > else C t u where > f = N This is an example where overlap is well-behaved. (Assuming those are the only instances.) > Now, it is simple to define type equality t == u There's a persistent problem for the compiler testing for type equality: the usage sites must have the types grounded. It's often more successful to prove disequality. > using functional dependencies, and so (...) > in the instance chains framework these could be written > as separate instances. This is a case of well-behaved overlap, so they'd work as separate instances anyway. > We might hope to get away with just one extra instance: > instance C Int Int where f = M > instance C t u if t == Int fails where f = N > instance C t u if u == Int fails where f = N > But note that the latter instances will seem incoherent to the compiler, That first most specific instance exhibits 3 type equalities: (t ~ Int. u ~ Int, t ~ u) So there's various ways to slice up the space. I think Instance Guards both have less lexical clutter, and help the compiler see what's coherent: > instance C Int Int where f = M > instance C t t | t /~ Int where f = N > instance C t u | t /~ u where f = N > [4-instance example elided] > ... we have taken one "intuitive" case and split it into > three apparently distinct branches ... I guess what's intuitive will depend on the application. It's difficult to make much claim in the abstract. > ... ---or made things easier for the compiler--- > since we now have four axiom clauses for class C > instead of two, and 6 coherence checks instead of none. The compiler author will love having precise rules for when instances are apart. And being able to check that when compiling the instance (not delay it to the usage site). And needing to validate only each pair of instances; not worry about overlaps of overlaps. I suspect that for the compiler, Instance Chains will be as problematic for type inference as with Closed Type Families: CTFs have a lot of searching under the covers to 'look ahead' for equations that can safely match. AntC

1 0

Re: [Haskell-cafe] Type-level GCD [Instance Chains]
by Anthony Clayden 01 Jun '17

01 Jun '17

> On Wed May 31 14:19:55 UTC 2017, J. Garrett Morris wrote: > [Apologies for breaking threading...] Thanks Garrett, my email client does horribler things to threading. Since the O.P. was about the aesthetics/readibility of code, I'm surprised you elided all the code. (I suppose de gustibus non disputandum.) >> On Wed May 31, Anthony Clayden wrote: >> Leaving aside the question of backtracking >> on instance non-match, >> would anybody write a type-level GCD like this? >Your question seems to be "would you use > the standard recursive statement of > Euclid's algorithm to demonstrate Euclid's algorithm?" > This certainly seemed to be a reasonable idea in 2010. I think the code I posted was using Euclid's algorithm. I agree it's difficult to cast one's mind back to what was reasonable Haskell in 2010, but I didn't use Type Families. > If your concern is efficiency, .. No, my concern is readability. >> (And Subt needs a nasty kludge in case you're trying to >> subtract the larger: it returns Z.) > What you call a nasty kludge, I call a standard operation > on commutative monoids. [https://en.wikipedia.org/wiki/Monus] Well, OK sometimes the kludge is justified ;-). Not for GCD, methinks. Because the equation guards specifically avoid the need. >> I think these days (esp with TypeFamilies/Assoc types), > You seem to be discovering that closed instance chains > can be implemented by writing out truth tables. I must admit I hadn't though of stand-alone instances as being like rows in truth tables. They're like separate lines of equations, each guarded by a condition. (In math, typically the condition is trailing with comma sep.) OK I'll mirror that style below. > I discussed this transformation at length, > and suggested that doing might make your code > harder to write and to read, ... Ok, let's see. Here's the math (adapted from wikipedia): gcd(m, n) = m , if m == n gcd(m, n) = gcd(m - n, n) , if m > n gcd(m, n) = gcd(m, n - m) , if m < n Here's some Haskell (this works in Hugs, just to make sure I'm getting the right vintage) > data Z; data S n > > data LT; data EQ; data GT > data If t > > class Gcd m n p | m n -> p where > -- methods for Gcd go here > > instance (GcdCase m n p (If d), Diff m n d) > => Gcd m n p where -- single 'catch all' instance > -- method definitions > > -- GcdCase instances mirror the Euclid equations > > class GcdCase m n p d | m n d -> p > instance (HTypeCast m p) > => GcdCase m n p (If (EQ, d')) > instance (Gcd d' n p) > => GcdCase m n p (If (GT, d')) > instance (Gcd m d' p) > => GcdCase m n p (If (LT, d')) > > class Diff m n d | m n -> d > instance Diff Z Z (EQ, Z) > instance Diff (S m') Z (GT, S m') > instance Diff Z (S n') (LT, S n') > instance (Diff m' n' d) => Diff (S m') (S n') d > > -- HTypeCast omitted, use standard HList > ... in my Haskell 2015 paper "Variations on Variants". OK, will study. I see that's focussing on Wadler's "expression problem", as does the Instance Chains paper. It's the Swiestra example there I want to get on to. > Of course, you'll have an easier time of it > if you limit yourself to only considering > type-level definitions, and not > the corresponding method definitions. > But doing so rather misses the point > of instance chains. I've used classes throughout the above. So could easily add methods. The idiom (following HList 2004) is some classes are type-level only. So I see no harm making those Type Families in 2017. (Whether they should be Closed TFs vs stand-alone instances is a separate debate.) AntC

2 1

data mining, or something like it
by Dennis Raddle 31 May '17

31 May '17

I have a general computer science question first, and then I will ask if Haskell might be helpful for this. I'm researching "algorithmic music composition," the construction of musical compositions through choices made my algorithms. No piece of music is ever 100% human-composed or 100% algorithmic -- so to be more clear, I'm interested in researching "musical fitness functions" that produce good results when searching the music space. Anything the computer composes will be listened to by me, and only the most promising fitness functions will be explored in greater depth. So my general question is about the following idea -- So in the course of generating lots of musical examples, and rating them as "good" or "bad," I'll end up with a database that can perhaps be "mined" for new fitness functions. I would start with a question. A random example of a question would be "is there a pattern in the density of dissonance, such that more dissonance in certain places in the composition tends to make it better (or worse)?" I would suspect, out of pure intuition, that it does, but I may not know the exact details. For instance, I might not know if dissonance matters more in certain places within a measure. So I could code up something that looks for patterns among the good and bad musical examples in my database to see if it can find something specific. So is this called "data mining" or something else? Second, are there any Haskell libraries that can help with this task? Thanks, D

3 3

is 'stack ghci' really experimental?
by Dennis Raddle 31 May '17

31 May '17

I noticed that the stack docs say 'stack ghci' is experimental. I assume it's a common need (certainly is for me) to interpret my code while developing. Is it safe to use 'stack ghci' or is there another way that is more robust? D

3 3

ANN: network-2.6.3.2
by evan＠evan-borden.com 31 May '17

31 May '17

Announcing network-2.6.3.2 This release includes many improvements to documentation and infrastructure as well as a few API additions. As always a huge thank you to the network contributors. Version 2.6.3.2 * Zero memory of `sockaddr_un` if abstract socket [#220](https://github.com/haskell/network/pull/220) * Improving error messages [#232](https://github.com/haskell/network/pull/232) * Allow non-blocking file descriptors via `setNonBlockIfNeeded` [#242](https://github.com/haskell/network/pull/242) * Update config.{guess,sub} to latest version [#244](https://github.com/haskell/network/pull/244) * Rename `my_inet_ntoa` to avoid symbol conflicts [#228](https://github.com/haskell/network/pull/228) * Test infrastructure improvements [#219](https://github.com/haskell/network/pull/219) [#217](https://github.com/haskell/network/pull/217) [#218](https://github.com/haskell/network/pull/218) * House keeping and cleanup [#238](https://github.com/haskell/network/pull/238) [#237](https://github.com/haskell/network/pull/237)

1 0

Re: [Haskell-cafe] Type-level GCD [Instance Chains]
by J. Garrett Morris 31 May '17

31 May '17

[Apologies for breaking threading...] On Wed May 31, Anthony Clayden <anthony_clayden at clear.net.nz> wrote: > Leaving aside the question of backtracking on instance > non-match, > would anybody write a type-level GCD like this? Your question seems to be "would you use the standard recursive statement of Euclid's algorithm to demonstrate Euclid's algorithm?" This certainly seemed to be a reasonable idea in 2010. If your concern is efficiency, I suggest that not using Peano numerals at all is probably a more profitable direction. > (And Subt needs a nasty kludge in case you're trying to > subtract the larger: it returns Z.) What you call a nasty kludge, I call a standard operation on commutative monoids. [https://en.wikipedia.org/wiki/Monus] > I think these days (esp with TypeFamilies/Assoc types), You seem to be discovering that closed instance chains can be implemented by writing out truth tables. I discussed this transformation at length, and suggested that doing might make your code harder to write and to read, in my Haskell 2015 paper "Variations on Variants". Of course, you'll have an easier time of it if you limit yourself to only considering type-level definitions, and not the corresponding method definitions. But doing so rather misses the point of instance chains. /g -- Prosperum ac felix scelus virtus vocatur -- Seneca

1 0

Type-level GCD [Instance Chains]
by Anthony Clayden 31 May '17

31 May '17

I'm re-reading the Instance Chains paper. http://dl.acm.org/citation.cfm?id=1863596 [2010, so before Type Families got off the ground] And wondering about some of [*] their motivating examples. [Disclaimer: with a view to writing up something I think is better.] Leaving aside the question of backtracking on instance non-match, would anybody write a type-level GCD like this? We have the usual type-level Naturals and Booleans: > {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies, > OverlappingInstances, EmptyDataDecls #-} > > data Z; data S n > > data T; data F And then: > class Gcd m n p | m n → p --p=gcd(m,n) > instance Gcd m m m -- OVERLAPPABLE OK > instance (Lte n m T, Subt m n m', Gcd m' n p) > ⇒ Gcd m n p > instance (Lte n m F, Subt n m n', Gcd m n' p) > ⇒ Gcd m n p Those latter two instances overlap (heads are identical) in an irresolvable way. (They're trying to distinguish the `m > n` vs `m < n` cases.) The code is closely following how you might write with Integers, I guess. But I'm not convinced it's such a good approach for Peanos. Class Lte compares two Peanos, tells which is the larger. Class Subt subtracts one from the other. They're both traversing the (S (S (S ... Z...))) nesting. (And Subt needs a nasty kludge in case you're trying to subtract the larger: it returns Z.) I think these days (esp with TypeFamilies/Assoc types), I'd write those latter two instances with a case helper. And a discriminator type fun `Diff` that provides the absolute diff, and tells which param is smaller. But to keep in the same style, I'll put `Diff` as a class: > instance (Diff m n d, GcdCase d m n p) > => Gcd m n p -- single 'catch all' instance > > class GcdCase d m n p | d m n -> p > instance (Gcd d' n p) > => GcdCase (T, d') m n p > instance (Gcd m d' p) > => GcdCase (F, d') m n p > > class Diff m n d | m n -> d > instance Diff Z (S n') (T, S n') > instance Diff (S m') Z (F, S m') > instance (Diff m' n' d) => Diff (S m') (S n') d Seems to me the code is more succinct, and easier to follow. (And by the way doesn't need egregious overlaps.) [*] Actually, I'm dubious about all of their examples. More to follow ... AntC

1 0

Re: [Haskell-cafe] [ghc-proposals/cafe] Partially applied type families
by Anthony Clayden 30 May '17

30 May '17

> On Mon May 15 16:20:09 UTC 2017, Richard Eisenberg wrote: > Lots to respond to! > Thanks Richard, phew! yes. Let's break it down a bit. > I do think think there's one overarching question/theme > here: Do we want functional dependencies or type-level > functions? Behind AntC's arguments, I see a thrust toward > functional dependencies. (Not necessarily their *syntax*, > but the idea of type improvement and flexible -- that is, > multidirectional -- type-level reasoning.) My dependent > types work pushes me toward type-level functions. Yes there is an overarching question. I don't think it's specifically FunDeps vs Type Functions. (Although I disagree the **Functional** Dependencies are somehow not "functional". Yes Mark Jones got the idea from Relational database theory. Where did Ted Codd get the idea from? Mathematical (binary) "relations", which are a set-theoretic account of, um, functions.) "Multidirectional type-level reasoning" is what all functional languages do: from Robinson's unification to Hindley-Milner to OutsideIn(X) to System F-subscript-superscript. There's been an example in Haskell's Prelude since ~1991: the `read` method's return type is 'demand-pulled' from context, not 'supply-pushed' from its parameter. Similarly if I write: > x :: Int > x = a + (b * c) We infer a, b, c must all be Int. Perhaps in another universe, Haskell had explicit type application from day 1, and insisted on giving type signatures for all vars (like nearly all procedural/OO languages). But we aren't in that universe, and I love Haskell/FP for being both type-safe and not pernickety in that way. > ... [big snip - I'll reply separately] > > I expect AntC would prefer disequality guards > over closed classes. Oh yes! I was about to say (repeating my earlier message): if we're going to ground type family instances in classes, then we need a way to distribute type instances as associated types, unless ... you're going to suggest something daft like closed classes. And then you did. > I would be interested to hear more from the > community on this choice -- they're really the same as > ordered equations under the hood, and it's just a choice > of syntax. Maybe we can even have both. > Yes please all chip in. There were strong views expressed 5~8 years ago. My two-penn'orth: I think we can mechanically translate closed equations to guards (equality and 'apart' tests). The example in my earlier post tried to show how. For class instances (with overlaps), I think there's also a mechanical translation, but only for 'well-behaved' sets of instances. (For Incoherent sets we don't have a chance.) And of course as soon as some imported instance overlaps, we have to start again to assess well-behavedness. > Now, on to individual points: > > ...the Hard Thought in order to be > backward compatible. (This backward compatibility > necessity is one of the reasons I love working with > Haskell. When adding a feature to the language, we just > can't take easy ways out!) > The backwards-compatibility I particularly want to preserve is "distributed instances". That is, putting the instance code close to type decls and other functions that build or consume that type. I also want to put explicitly *in the instance decl* the restraints on what types that instance applies for. Not implicit from where it appears in a closed but lengthy/voluminous sequence of equations. Yes there must be global coherence for the class/type instances. That's a mechanical check which compilers are good at, but humans not so much. > ... it was awkward to describe the overlap between two > branched instances. AntC might argue that, if we just had > disequality guards, it would all be much simpler. He might > be right. I'd argue it's simpler to understand each instance on its own grounds. Although a bunch of guards can get quite complex. (There was Andy A-M's example back in 2013.) The cumulative effect of the preceeding equations in the closed family is more complex. IMO. > > In retrospect, it would have been nice to have the > proposals process active when designing closed type > families; we might have come up with a better design. > There was a huge and rather repetitive (unfortunately) discussion in several rounds 2009~2012, somewhat prompted by trying to 'fix' the Haskell 2010 standard. So that we could include MPTCs in the standard. But you can't have MPTCs without FunDeps or Type Families, or without agreeing a position on overlaps. (good luck with that!) So although MPTCs were in both GHC and Hugs before 1998, they're still not 'official' >sigh<. MPTC's omission for Haskell2010 is what I meant by: > > we've lost 7~8 years of opportunity. > > My recollection at the time [of developing closed Families] > is that other approaches were > more functional-dependency-like in character. (To wit: > instance chains.) I wish Martin Sulzmann could have been more active at the time. (He occasionally expresses the intention of getting back into Haskell.) Instance guards are really a continuation of the CHR approach. So fit nicely into whole-of-program inference with type improvement. [I dislike the non-distributivity of instance chains for the same reason I dislike closed families. Although instance chains do have some nice features. Instance guards give me that feature more directly. Whereas closed type families don't give that feature at all.] > When I did the closed type family work, > I was thinking that type families were better than > functional dependencies; now, my view is much more nuanced > (leaning strongly toward fundeps instead of partial type > families). > I'm a little unsure what you mean at the top of the post about the "idea" of FunDeps vs their specific syntax. I can simulate FunDeps with superclass constraints using Type Funs and Equality constraints. This even achieves multi-directional improvement. Is that what you want to include? It took me a long time to realise this works out better than the FunDeps arrow business, especially with overlaps. The dreaded "Instances inconsistent with FunDeps" error is a devil to fiddle with. And often ends up breaking the coverage condition. [As Iavor frequently points out.] Martin pointed out that breaking coverage (using UndecidableInstances) is not as 'safe' as SPJ had been assuming. > > > I don't see what's so hard [about non-unifiability]. > > It's not nearly as hard from a fundep point of view. ... > ... [another big snip: thanks for the pointer to the paper.] > > I do have to say all this talk has made me think more > about apartness constraints in FC, at least. They might be > a touch simpler than the current story. > I think apartness is the criterion that's always applied to resolve instance selection under overlaps. The trouble is that the semantics for overlap has never been spelled out. (Nor, I suspect the criterion for a 'well-behaved' set of instances. I can volunteer that for you.) Apartness does not intrude inside constraints in the class/instance contexts, nor inside the body of a class instance/methods. It might help with instance selection wrt the rhs of type instance equations. AntC

3 3

Re: [Haskell-cafe] [ghc-proposals/cafe] Partially applied type families
by Anthony Clayden 30 May '17

30 May '17

> On Wed May 24 02:33:46 UTC 2017, Richard Eisenberg wrote: > ... > Thanks for getting me to think about all this > in a new way! Thanks Richard, yes I think we have large areas of agreement. So I'll cut to where we differ. > > > On May 15, 2017, at 9:26 PM, Anthony Clayden wrote: > > "Multidirectional type-level reasoning" is what all > > functional languages do: from Robinson's unification > > to Hindley-Milner to OutsideIn(X) > > to System F-subscript-superscript. > > I disagree here: the dependently typed languages don't > quite do this. Then I guess I remain to be convinced of the value of dependent typing within Haskell. > ...These languages still do multi-directional type inference, I guess you mean as needed for superclass constraints and instance constraints, so perhaps there's no practical difference. > > > > The backwards-compatibility I particularly > > want to preserve is "distributed instances". > > That is, putting the instance code > > close to type decls and other functions that > > build or consume that type. > > I think one other key difference between our viewpoints is > that I view the whole idea of "type instance" to be a bit > backward: I view type families as type-level functions. > Like other functions, I want the defining equations to be > all in one place. I'd like term-level functions to be more like instances. That is, with the equations distributed, see your example below. (Yes the set of equations must be coherent overall. That's something the compiler can check for me.) > > This isn't to argue that my viewpoint is right or that > other viewpoints are wrong. It's just a way to understand > why we both see things the way we do. Yes. > > > I'd argue it's simpler to understand each instance > > on its own grounds. > > Permit me to rewrite your sentence to something that > resonates better with me: > > > I'd argue it's simpler to understand each *equation* > > on its own grounds. > > I agree here, but it's a bit subtler. > We aren't confused when we see > > > f [] = False > > f _ = True Oh, yes I think a lot of people are confused. I think they expect the second equation is equivalent to: > f (x:xs) = True Maybe even > f ~(x:xs) = True But in the presence of bottom, that's a dangerous delusion. I'd say: if you want the True result to mean there's a non-empty list, then put that explicitly. And then we have two equations that are 'apart'. And they don't need to be sequential. Furthermore that delusion is doubly dangerous for type equations, because GHC knows nothing of closed Data Kinds. > > There was a huge and rather repetitive (unfortunately) > > discussion in several rounds 2009~2012, > > These dates might help to explain why I may be repeating > old arguments. I became active in the community somewhere > > in 2012. No, you're not repeating old arguments. Type Families, and esp. CTFs really came later. IIRC, at the time, there was a lot of suggestions, but not much push-back from anybody disagreeing. There was some doubt whether there could be a type-level disequality test. Chiefly GHC HQ just ignored the whole thing. Somebody at the time did try to write it up (viz. moi) https://ghc.haskell.org/trac/ghc/wiki/NewAxioms/DiscussionPage And someone from GHC HQ (viz. you) did acknowledge it rather later. > > I'm a little unsure what you mean at the top of the post > > about the "idea" of FunDeps vs their specific syntax. > > By "idea", I mean traits like multidirectionality and > attachment to classes. I maintain that the > function-application syntax of type families is better > than the relational syntax of fundeps. > OK I think you're saying that a class decl with superclass (~) constraints to type functions is preferable/more aesthetic. I agree. Furthermore overlap interferes with fundeps (or perhaps I mean v.v.) in horrible ways. > ...I'm not sure we need to allow ~ guards. > (I think allowing them would cause confusion, with > many people asking about the difference between an > equality constraint and an equality guard. Yes I can see the dangers of confusion. We could of course use a different operator. > ... They're different, but I think the equality guard is useless I see two main uses/benefits: 1. avoids the need for non-linear patterns in the head 2. visually points up the 'non-apartness' vs an, um. "apartness guard" (When I was figuring out Andy A-M's 2013 example, I rewrote the non-linear patterns with ~ guards, so I could figure out the apartness guards esp for the semi-apart instances. I posted the later workings to your blog https://typesandkinds.wordpress.com/2013/04/29/coincident-overlap-in-type-f… ) > [except as a type-level "let", I suppose].) No, they're not doing that: deliberately I don't allow guards to introduce new type vars. > ... partial type families ... > Of course, when you protect a > partial type family by a class constraint, then it's not > troublesome: that's the point of the Constrained Type > Families paper. Yes I got that loud and clear, and I agree. So the remaining issue is _how_ to protect them. > > > Sometimes I deliberately want there to be no instance > > for some specific pattern. > > Indeed yes. And now you can, with TypeError > (https://ghc.haskell.org/trac/ghc/wiki/Proposal/CustomType > Errors, which is now available in GHC 8). Ok thanks, yes that helps. Nevertheless it seems disergonomic to write an instance for a type-equal case, even with a helpful error message; when what you want is: no such instance. > > Bottom line: You win. I'm convinced. Apartness guards > (feel free to fight me on the name here -- I don't feel > strongly, but somehow I like "apartness guards" more than > "disequality guards") subsume OverlappingInstances (when > the author of the instances has a particular desired way > to resolve overlap) and closed type families. I think that > the syntax of closed type families is often what the user > wants, but I admit that CTFs don't cover all scenarios, > especially in the context of Constrained Type Families. So > I think we should keep CTFs (for now -- until Dependent > Haskell is here) but add this new syntax as well, which > would subsume the newly-proposed closed type classes. I've been (mostly in my head) calling them "Instance Guards", because I want both an eq guard and an apartness guard. > > Even better, I think apartness guards would be very easy > to implement. All the plumbing is already installed: we > basically just have to add a switch. > Yes that's what I guessed from your write-up of CTFs and "coincident overlap". What I can see will be awkward is backwards compatibility: can a class/type family with guards coexist with CTFs and with classes using overlap? > Next step: write a ghc-proposal. I'll support it. If I had > the time, I'd even implement it. I'll have a crack at the proposal. But implementing it is entirely beyond me. So thanks for saying "you win". But I'm not celebrating 'til something actually happens. (Been bitten too many times.) AntC

3 2

Re: [Haskell-cafe] Haskell performance when it comes to regex?
by Chris Dornan 30 May '17

30 May '17

Brandon Allbery allbery.b(a)gmail.com: > TDFA is pure Haskell and mostly exists for when you can't be certain that a faster C binding will support UTF8 > (most POSIX regex implementations do not, and PCRE only does so if someone built it with UTF8 support). > When it's usable, the C bindings will almost always be faster. I think we are in agreement, though I would generally recommend TDFA, unless you need the highest performance (as in this case) or Perl-style REs. But then again I like my REs plain and simple (and Posix) and packages with as few external dependencies as possible. Chris

2 1

Re: [Haskell-cafe] Haskell performance when it comes to regex?
by Chris Dornan 30 May '17

30 May '17

Hi Bram, Sorry for being a bit late to this -- I have been on the road. I have switched over you example to pre-compile the REs and use ByteString and can see 13x speedup on scan and a 9x speedup on mapping. Curiously, nearly all of that speedup seems to be gained by lifting the RE compilation out of the loop but I am pretty sure there are gains to be had from re-writing the loops. Do you have the Python code that was performing 80x better? Chris From: Alfredo Di Napoli <alfredo.dinapoli(a)gmail.com> Date: Monday, 22 May 2017 at 08:48 To: Bram Neijt <bneijt(a)gmail.com> Cc: Станислав Черничкин <schernichkin(a)gmail.com>, haskell-cafe <haskell-cafe(a)haskell.org>, Chris Dornan <chris(a)chrisdornan.com> Subject: Re: [Haskell-cafe] Haskell performance when it comes to regex? Hi Bram, you might be interested in the “regex” package from my colleague Chris Dornan: http://regex.uk/ I know some proper performance work still needs to be done, but I would be curious to hear your experience report ;) Alfredo On 19 May 2017 at 18:52, Bram Neijt <bneijt(a)gmail.com> wrote: Thank you! I already changed to Text instead, but I thought the regex was already memoized by GHC, so that should not be a problem. I'm trying regex-applicative now, maybe that will help, but it takes some time to figure out the syntax. I'll also try to see if precompilation helps. Greetings, Bram On Fri, May 19, 2017 at 1:17 PM, Станислав Черничкин <schernichkin(a)gmail.com> wrote: > Try to use Text or ByteString instead of strings. Try to use compile and > execute methods > (http://hackage.haskell.org/package/regex-tdfa-1.2.1/docs/Text-Regex-TDFA-By…) > make sure regex get compiled once. > > 2017-05-16 12:12 GMT+03:00 Bram Neijt <bneijt(a)gmail.com>: >> >> Dear reader, >> >> I decided to do a little project which is a simple search and replace >> program for large text files. >> >> Written in Haskell, it does a few different regex matches on each line >> and stores them in a leveldb key-value store to create a >> consistent/reviewable search-replace index. It should provide for some >> simple/brute-force anonymization of data and therefore I called it >> hanon (sorry, could not think of a better name). >> >> https://github.com/BigDataRepublic/hanon >> >> The code works, but I've done some benchmarking to compare it with >> Python and the code is about 80x slower then doing the same thing in >> Python, making it useless for larger data files. >> >> I'm obviously doing something wrong. >> >> Could you give me tips on improving the performance of this code? >> Probably mainly looking at >> >> https://github.com/BigDataRepublic/hanon/blob/master/src/Mapper.hs >> >> where the regex code lives? >> >> Greetings, >> >> Bram >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > > > > -- > Sincerely, Stanislav Chernichkin. _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

4 4

Re: [Haskell-cafe] Haskell performance when it comes to regex?
by Saurabh Nanda 30 May '17

30 May '17

Sorry for jumping in. IIUC the largest speedup was delivered by moving a reger compilation expression out of a loop. If the regex compilation is a pure function, being passed the exact same arguments during every invocation of the loop, shouldn't the compiler be smart enough to optimise it? Isnt this the basic premise of pure FP? On 30-May-2017 2:20 AM, "Brandon Allbery" <allbery.b(a)gmail.com> wrote: On Mon, May 29, 2017 at 3:53 PM, Chris Dornan <chris(a)chrisdornan.com> wrote: > * I switched from Text.Regex.TDFA to Text.Regex.PCRE (as I think you > observed, judging by your commit messages), it seems to be somewhat > faster, at lease for these relatively small data sets; > TDFA is pure Haskell and mostly exists for when you can't be certain that a faster C binding will support UTF8 (most POSIX regex implementations do not, and PCRE only does so if someone built it with UTF8 support). When it's usable, the C bindings will almost always be faster. -- brandon s allbery kf8nh sine nomine associates allbery.b(a)gmail.com ballbery(a)sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

1 0

A new type of newtype --- Type-level instance diversification and resolution (tl; dr)
by Albert Y. C. Lai 30 May '17

30 May '17

When you store elements in a binary search tree, wouldn't you love to custom-order the comparison order? Wouldn't you love to do so without newtype-wrapping the element type? In fact you may actually opine that your element type should not admit a standard order in the first place (e.g., complex numbers), and whichever order used for the sake of binary search trees should stay just that and not become a general-purpose default. Perhaps more pressing to most people is when you store elements in a HashSet and you want to customize the hash function, again without either newtype-wrapping or fighting over defaults. Here is how to do that. Have a parameterized Ord class like this: {-# LANGUAGE MultiParamTypeClasses, PolyKinds, KindSignatures #-} class MyOrd (resolver :: k) a where mycmp :: p resolver -> a -> a -> Ordering instance MyOrd () Int where mycmp _ x y = compare x y data Rev instance MyOrd Rev Int where mycmp _ x y = compare y x It is also possible to get rid of the proxy parameter and use TypeApplication instead. dmwit from IRC suggests that MyOrd could be tied back to standard Ord by: instance MyOrd () a => Ord a which helps with backward compatibility. So basically use () to resolve to the standard instances (wherever a community-wide standard makes sense) and have existing standard classes tied to the new parameterized classes by resolver ~ (). Now use the parameterized Ord class for binary search trees: {-# LANGUAGE ScopedTypeVariables #-} import Data.Proxy(Proxy(Proxy)) import Data.List(foldl') data BST (resolver :: k) a = Nil | Bin !(BST resolver a) a !(BST resolver a) empty :: BST r a empty = Nil insert :: forall r a. MyOrd r a => a -> BST r a -> BST r a insert a Nil = Bin Nil a Nil insert a t@(Bin left key right) = case mycmp (Proxy :: Proxy r) a key of EQ -> t LT -> Bin (insert a left) key right GT -> Bin left key (insert a right) fromList :: MyOrd r a => [a] -> BST r a fromList xs = foldl' (flip insert) Nil xs toAscList :: BST r a -> [a] toAscList t = run t [] where run Nil = id run (Bin left key right) = run left . (key :) . run right Now we have it. toAscList (fromList [3,1,4,15,9,2,6,5,38] :: BST () Int) evaluates to [1,2,3,4,5,6,9,15,38] toAscList (fromList [3,1,4,15,9,2,6,5,38] :: BST Rev Int) evaluates to [38,15,9,6,5,4,3,2,1] and both terms have the same type [Int]. The second term does not have to have type [Down Int]. Other applications include: Custom-making equivalence relations without calling them Eq; alternative interfaces to groupBy, sortBy, maximumBy, etc.; SML-style functorial programming; and liberating Complex from Ord. I thank jadrian from IRC for proposing "named instance": > so instead of "instance Num n => Monoid (Sum n) where" we'd write e.g. > "instance Sum of Num n => Monoid n where" and use it as "Sum.mempty" which stimulated me to think "oh we can emulate that by multiple parameter type class..."

3 2

Re: [Haskell-cafe] A new type of newtype --- Type-level instance diversification and resolution (tl; dr)
by Oleg 29 May '17

29 May '17

The idea of adding a label (`resolver') is very old. Here is the examples of how far you can take it: http://okmij.org/ftp/Haskell/TypeClass.html#Haskell1 We can represent all of Haskell98 classes plus functional dependencies with only one, predefined type class.

1 0

Call for participation: Trends in Functional Programming, 19-21 june 2017, University of Kent, Canterbury
by Peter Achten 29 May '17

29 May '17

----------------------------- C A L L F O R P A R T I C I P A T I O N ----------------------------- ======== TFP 2017 =========== 18th Symposium on Trends in Functional Programming 19-21 June, 2017 University of Kent, Canterbury https://www.cs.kent.ac.uk/events/tfp17/index.html The symposium on Trends in Functional Programming (TFP) is an international forum for researchers with interests in all aspects of functional programming, taking a broad view of current and future trends in the area. It aspires to be a lively environment for presenting the latest research results, and other contributions (see below). Authors of draft papers will be invited to submit revised papers based on the feedback receive at the symposium. A post-symposium refereeing process will then select a subset of these articles for formal publication. TFP 2017 will be the main event of a pair of functional programming events. TFP 2017 will be accompanied by the International Workshop on Trends in Functional Programming in Education (TFPIE), which will take place on 22 June. The TFP symposium is the heir of the successful series of Scottish Functional Programming Workshops. Previous TFP symposia were held in * Edinburgh (Scotland) in 2003; * Munich (Germany) in 2004; * Tallinn (Estonia) in 2005; * Nottingham (UK) in 2006; * New York (USA) in 2007; * Nijmegen (The Netherlands) in 2008; * Komarno (Slovakia) in 2009; * Oklahoma (USA) in 2010; * Madrid (Spain) in 2011; * St. Andrews (UK) in 2012; * Provo (Utah, USA) in 2013; * Soesterberg (The Netherlands) in 2014; * Inria Sophia-Antipolis (France) in 2015; * and Maryland (USA) in 2016. For further general information about TFP please see the TFP homepage. (http://www.tifp.org/) == SCOPE == The symposium recognizes that new trends may arise through various routes. As part of the Symposium's focus on trends we therefore identify the following five article categories. High-quality articles are solicited in any of these categories: Research Articles: leading-edge, previously unpublished research work Position Articles: on what new trends should or should not be Project Articles: descriptions of recently started new projects Evaluation Articles: what lessons can be drawn from a finished project Overview Articles: summarizing work with respect to a trendy subject Articles must be original and not simultaneously submitted for publication to any other forum. They may consider any aspect of functional programming: theoretical, implementation-oriented, or experience-oriented. Applications of functional programming techniques to other languages are also within the scope of the symposium. Topics suitable for the symposium include, but are not limited to: Functional programming and multicore/manycore computing Functional programming in the cloud High performance functional computing Extra-functional (behavioural) properties of functional programs Dependently typed functional programming Validation and verification of functional programs Debugging and profiling for functional languages Functional programming in different application areas: security, mobility, telecommunications applications, embedded systems, global computing, grids, etc. Interoperability with imperative programming languages Novel memory management techniques Program analysis and transformation techniques Empirical performance studies Abstract/virtual machines and compilers for functional languages (Embedded) domain specific languages New implementation strategies Any new emerging trend in the functional programming area If you are in doubt on whether your article is within the scope of TFP, please contact the TFP 2017 program chairs, Scott Owens and Meng Wang. == BEST PAPER AWARDS == To reward excellent contributions, TFP awards a prize for the best paper accepted for the formal proceedings. TFP traditionally pays special attention to research students, acknowledging that students are almost by definition part of new subject trends. A student paper is one for which the authors state that the paper is mainly the work of students, the students are listed as first authors, and a student would present the paper. A prize for the best student paper is awarded each year. In both cases, it is the PC of TFP that awards the prize. In case the best paper happens to be a student paper, that paper will then receive both prizes. == PAPER SUBMISSIONS == Acceptance of articles for presentation at the symposium is based on a lightweight peer review process of extended abstracts (4 to 10 pages in length) or full papers (20 pages). The submission must clearly indicate which category it belongs to: research, position, project, evaluation, or overview paper. It should also indicate which authors are research students, and whether the main author(s) are students. A draft paper for which ALL authors are students will receive additional feedback by one of the PC members shortly after the symposium has taken place. We use EasyChair for the refereeing process. Papers must be submitted at: https://easychair.org/conferences/?conf=tfp17 Papers must be written in English, and written using the LNCS style. For more information about formatting please consult the Springer LNCS web site: http://www.springer.com/computer/lncs?SGWID=0-164-6-793341-0 == INVITED SPEAKERS == Conor McBride University of Strathclyde (UK) Cătălin Hriţcu INRIA Paris (FR) == IMPORTANT DATES == Submission of draft papers: 5 May, 2017 Notification: 12 May, 2017 Registration: 11 June, 2017 TFP Symposium: 19-21 June, 2017 Student papers feedback: 29 June, 2017 Submission for formal review: 2 August, 2017 Notification of acceptance: 3 November, 2017 Camera ready paper: 2 December, 2017 == PROGRAM COMMITTEE == Co-Chairs Meng Wang University of Kent (UK) Scott Owens University of Kent (UK) PC Jeremy Yallop University of Cambridge (UK) Nicolas Wu University of Bristol (UK) Laura Castro University of A Coruña (ES) Gabriel Scherer Northeastern University (US) Edwin Brady University of St Andrews (UK) Janis Voigtländer Radboud University Nijmegen (NL) Peter Achten Radboud University Nijmegen (NL) Tom Schrijvers KU Leuven (BE) Matthew Fluet Rochester Institute of Technology (US) Mauro Jaskelioff CIFASIS/Universidad Nacional de Rosario (AG) Patricia Johann Appalachian State University (US) Bruno Oliveira The University of Hong Kong (HK) Rita Loogen Philipps-Universität Marburg (GE) David Van Horn University of Marylan (US) Soichiro Hidaka Hosei University (JP) Michał Pałka Chalmers University of Technology (SE) Sandrine Blazy University of Rennes 1 - IRISA (FR)

1 0

Ralf Lämmel gives a talk at Haskell User Group - Frankfurt, 21.6.17
by Peter Althainz 28 May '17

28 May '17

Dear All, we are happy to have Ralf Lämmel in Frankfurt, talking about: "An interpreter for every season", targeted at a Haskell-friendly audience. https://www.meetup.com/de-DE/Frankfurt-Haskell-User-Group/events/240346167 regards Peter

1 0