- Haskell-Cafe - Haskell.org

Arithmetic expressions with random operators
by Mahmoud Murad 08 Jun '17

08 Jun '17

I have the following problem, I want to randomly generate arithmetic expressions based on a number, for example: if I have n = 3, then the expression must have 3 operators like this (4)*(((3+5)-2)). Any advice or hint? I am relatively new to Haskell. Thanks.

4 4

Issue 58 :: Haskell Weekly
by Taylor Fausak 08 Jun '17

08 Jun '17

\ Haskell Weekly \/\/ Issue 58 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. - A Haskell cross compiler for iOS <https://medium.com/@zw3rk/a-haskell-cross-compiler-for-ios-7cc009abe208> So far we have built a Haskell cross compiler for Raspberry Pi, as well as a Haskell cross compiler for Android. To round this off, we will build a cross compiler for iOS as well. With the WWDC signaling the end of 32-bit devices, we will only build the 64-bit cross compiler. - Event sourced aggregates in Haskell <http://blog.akii.de/posts/2017-06-04-eventsourcing-in-haskell.html> In this first post I'll be digging into event sourced aggregates in Haskell. It basically means that instead of persisting some state like "Johns account balance is $100", you keep track of the changes to John's account: "First he deposited $125, then withdrew $25". - The round-trip property <http://teh.id.au/posts/2017/06/07/round-trip-property/index.html> We know that parsers and printers are supposed to be dual. We can simply treat this as a law, and write a property test to enforce it. This is both the simplest useful property test I can think of for a working engineer and the most likely to reliably identify bugs of consequence. - How well do you know your programming tools? Take the survey and test your skills! (ad) <http://vmob.me/DE3Q17Haskellweek> "It is a good survey which, in addition to remembering what I already knew, gave me new tools to learn about and work with." This is how developers feel about the Developer Economics survey. The survey also shows you how you compare to other developers in your country. Plus you may win an iPhone 7 or a Pixel 32GB phone. - Assume it worked and fix it later <https://hackernoon.com/assume-it-worked-and-fix-later-8436d18b7ed3> If your email service is down, it can be beneficial to have the signup succeed regardless. By decoupling the success of an email request from the success of account signup, you can improve the reliability of your application. - Flexible data with Aeson <https://mmhaskell.com/blog/2017/6/5/flexible-data-with-aeson> At a certain point, our Haskell programs have to be compatible with other programs running on the web. This is especially useful given the growing usage of micro-services as an architecture. Regardless, it's very common to be transferring data between applications on different stacks. - Tagless final encoding of a test language <https://wickstrom.tech/programming/2017/06/05/tagless-final-encoding-of-a-t…> I have experimented with a test language encoded in tagless final style, instead of algebraic data types, to support the typed combinators `beforeEach` and `beforeAll`. I want to share the Haskell prototype I ended up with, and explain how I got there. - Can't see the four-est for the trees <http://www.gigamonkeys.com/trees/> It's a fun puzzle so you may want to take a crack at it yourself before reading on. But this isn't really about that puzzle. This is about how sometimes when the mathematical insights aren't flowing it's good to be a programmer. - The Typeclassopedia is now up to date <https://byorgey.wordpress.com/2017/06/07/the-typeclassopedia-is-now-up-to-d…> The title pretty much says it all: I have finally finished (I hope) updating the Typeclassopedia to reflect various recent changes to the language and standard libraries (such as the AMP and BBP/FTP). Along the way I also added more links to related reading as well as more exercises. - Continuations from the ground up <http://blog.ielliott.io/continuations-from-the-ground-up/> It's difficult to learn functional programming without hearing about continuations. Often they're mentioned while talking about boosting the performance of pure functional code, sometimes there's talk of control flow, and occasionally with "time-travel" thrown in there to make it all seem more obscure. - How to send me a pull request <https://www.snoyman.com/blog/2017/06/how-to-send-me-a-pull-request> I find myself repeating a lot of the same comments in pull requests, so I decided to put together a list of what I consider the most important features of a good pull request. Other people will have different feelings on some of these, but the points below are what apply to my projects. Package of the week ------------------- This week's package of the week is Yesod, a web framework for productive development of type-safe, RESTful, high performance web applications. <https://www.stackage.org/package/yesod>

1 0

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