- Haskell-Cafe - Haskell.org

[ANNOUNCE] comprehensions-ghc: ApplicativeComprehensions as a GHC plugin
by Matthew Farkas-Dyck 09 Apr '19

09 Apr '19

https://hackage.haskell.org/package/comprehensions-ghc See description for instructions how to use. A comprehension makes more sense than a `do` expression for `Applicative` types — `ApplicativeDo` relies on a kludge: checking whether the last expression has the form `pure _` or `return _`. Indeed, for an `Applicative` term, it can ultimately (modulo aliases, let-expressions, η-expansion, etc) have no other! So far, however, the plugin merely rewrites each comprehension as a `do` expression. (It ignores comprehensions with features which can't be converted.) My most compelling use case so far has been context-free-parsing records (for examples: with `optparse-applicative` or `regex-applicative`). It lets one write the following: `[Options {..} | foo <- parseFoo, bar <- parseBar]` Cheers, happy hacking ☺

1 0

Re: [Haskell-cafe] streaming with logs / metadata
by Olaf Klinke 08 Apr '19

08 Apr '19

Dear Evan, Probably you want to have a look whether the mtl package has something for you. Anything beyond the Functor instance for (Either e), though, models exceptions that abort the computation as soon as the first Left arises. You seem to use the type in a different way which may be one reason why you do not find your functions implemented elsewhere. For logging or warnings, most Haskellers use something like a writer monad transformer. The underlying monad, Writer w a = (w,a) for some monoid w, is exceptionally versatile because of the function Functor f => Writer w (f a) -> f (Writer w a) which in combination with traverse lets you move the (Writer w) type in and out of nested types easily. Cheers, Olaf

2 1

GHC extensions
by Michel Haber 08 Apr '19

08 Apr '19

Hello Cafe, So I've been learning a bit about the GHC extensions from https://github.com/i-am-tom/haskell-exercises. But the lessons say nothing about how the extensions work behind the scenes. For example, I've assumed that RankNTypes would require something similar to dynamic dispatch in imperative languages in order to work. But this is just an assumption. So I was wondering where I can get a quick succinct read (or a summary at least) about how these extensions are implemented, as well as their performance cost (or gain!). Also if someone knows other tutorials and lessons for these, and other extensions, please feel free to share them :p Thank you, Michel :)

4 4

[ANNOUNCE] GHC 8.6.5-rc1 is now available
by Ben Gamari 08 Apr '19

08 Apr '19

Hello everyone, The GHC team is proud to announce the first release candidate of 8.6.5. The source distribution, binary distributions, and documentation are available at https://downloads.haskell.org/~ghc/8.6.5-rc1 This release fixes a handful of issues with 8.6.4: - Binary distributions once again ship with Haddock documentation including syntax highlighted source of core libraries (#16445) - A build system issue where use of GCC with `-flto` broke `configure` was fixed (#16440) - An bug affecting Windows platforms wherein XMM register values could be mangled when entering STG has been fixed (#16514) - Several Windows packaging issues resulting from the recent CI rework. (#16408, #16398, #16516) Since this is a relatively small bugfix release we are bypassing the alpha releases and moving right to the release candidate stage. If all goes well the final release will be cut next week. As always, if anything looks amiss do let us know. Happy testing! Cheers, - Ben

1 0

[ANN] Haskell.Org Discourse Instance
by Jasper Van der Jeugt 08 Apr '19

08 Apr '19

Hello all, We would like to announce a new discourse-based forum for the Haskell community, at: https://discourse.haskell.org/ This is inspired by the Rust, Nix and Elm discourse instances, where these forums have had a strong positive effect on the community. We will run this as a "beta" for 6 months and then evaluate its usefulness. It is meant as an extra alternative to Haskell-cafe, reddit and Haskell IRC, but it does not replace any of those. Discourse is completely open source and easily accessible using an email client. We would like to thank the Haskell.Org admin team for provisioning a server and Matthew Pickering for suggesting this and doing the hard work setting up the instance. Warm regards, Jasper Van der Jeugt on behalf of the Haskell.Org Committee

4 3

streaming with logs / metadata
by Evan Laforge 08 Apr '19

08 Apr '19

I have a pattern that's come up several times, and I'm wondering if there's a name for it, or a better way to do it. It has to do with processing streams, which in the presence of laziness and the absence of effects can be done with just lists. For instance, imagine a parser that produces [Token], then various processing stages that go [Token] -> [x], [x] -> [y], [y] -> [Output]. If I have a transform function that works on a single element 1:1 and is stateless, then I can express it with 'map'. If it needs simple state, then I can switch 'map' for 'mapAccumL', which is just a specialization of the State monad. If it needs to know the next element, I can compose a 'zipNext' (zip xs (drop 1 xs)) on the front. If it returns multiple elements, there's concatMap, and of course mapM for arbitrary monads. Now suppose it needs warnings, or logging, so to preserve streaming I wind up with '[Either e a] -> [Either e b]'. I still want to do all the same stuff, but factor out the Lefts so I don't have to be explicitly passing through all the time. So I start reimplementing the usual list functions: module E where map :: (a -> b) -> [Either e a] -> [Either e b] mapE :: (a -> Either e b) -> [Either e a] -> [Either e b] concatMap :: (a -> [b]) -> [Either e a] -> [Either e b] concatMapE :: (a -> [Either e b]) -> [Either e a] -> [Either e b] mapAccumL :: (state -> a -> (state, Either e b)) -> state -> [Either e a] -> (state, [Either e b]) And of course the monadic / applicative variants: mapM :: Applicative m => (a -> m b) -> [Either e a] -> [Either e b] mapEM :: Monad m => (a -> m (Either e b)) -> [Either e a] -> m [Either e b] ... etc. But to deal with supplying extra state, or looking into the future or filtering I have to reinvent those too: zip :: [a] -> [Either e b] -> [Either e (a, b)] zip{2,3,4,...} :: ... zipNexts :: [Either e a] -> [Either e (a, [a])] filter :: (a -> Bool) -> [Either e a] -> [Either e a] The zips become asymmetrical, but they're in service of a common pattern which I'm not sure how to describe, but is used to get the Lefts out of the way. E.g. if a duration can be derived from a Right value, to annotate Rights with start times: 'E.zip (scanl (+) 0 (map durationOf (Either.rights xs))) xs'. It's a bit unsatisfying because it relies on the transformation preserving 1:1 with its input, or at least new elements are added only at the end and I can ignore them. 'scanl . map' happens to have this property, but it's not obvious or guaranteed. My questions are, is this a known pattern? Is there an implementation on hackage, or at least a good thing to call it? And then, is there a a way to construct these functions systematically, or to compose them from smaller parts? The 1:1 stateless ones like 'map' and 'mapM' work out nicely because they're just 'fmap . fmap' or 'traverse . traverse', and I can implement 'concatMapM' and then implement a lot of other kinds of maps as specializations, though efficiency may suffer. But for the zips and filters and takeWhiles I wind up just rewriting the recursion. They feel ad-hoc and unsatisfying, that if I were more clever I would figure out how to abstract out the Lefts in one spot, once and for all. There is a general way to get all of the '[a] -> [b]' functions into '[Either e a] -> [Either e b]', and that's to partitionsEithers, apply second, then concat, but of course it spoils streaming and is inefficient if there are lots of Lefts. Still, it's the only way I can think of to get those Lefts out of the picture in a modular way. Using a Writer I think is equivalent. There's a similar problem with being able factor out annotations, similar to the way I want to factor out logs / warnings / other metadata above. E.g. if we have '[(annot, a)] -> [(annot, b)]' then we start with a simple fmap.fmap, but any more complicated transforms means you either have to intersperse the "ignore annotation" logic and clutter things up with 'snd's and 'second's everywhere, or come up with a whole new map filter zip toolkit.

1 0

Call for Contributions--First miniKanren and Relational Programming Workshop
by William Byrd 05 Apr '19

05 Apr '19

DEADLINE: 15 May 2019, (Any time in the world) WEBSITE: https://icfp19.sigplan.org/home/minikanren-2019 LOCATION: Berlin, Germany (co-located with ICFP) DATE: 22 August 2019 The 2019 First miniKanren and Relational Programming Workshop is calling for submissions. Full papers are due 15 May 2019. Authors will be notified by 15 June 2019. Camera-ready versions are due 30 June 2019. All deadlines are (23:59 UTC-12), "Anywhere on Earth". The miniKanren and Relational Programming Workshop is a new workshop for the miniKanren family of relational (pure constraint logic programming) languages: miniKanren, microKanren, core.logic, OCanren, Guanxi, etc. The workshop solicits papers and talks on the design, implementation, and application of miniKanren-like languages. A major goal of the workshop is to bring together researchers, implementors, and users from the miniKanren community, and to share expertise and techniques for relational programming. Another goal for the workshop is to push the state of the art of relational programming---for example, by developing new techniques for writing interpreters, type inferencers, theorem provers, abstract interpreters, CAD tools, and other interesting programs as relations, which are capable of being "run backwards," performing synthesis, etc. Submission Information Submission Page: https://minikanren19.hotcrp.com/ Paper submissions must use the format acmart and its sub-format acmlarge. They must be in PDF, printable in black and white on US Letter size. Microsoft Word and LaTeX templates for this format are available at: http://www.sigplan.org/Resources/Author/ As this is the first iteration of the workshop, we want to encourage all kinds of submissions. We expect short papers as well as longer papers. As a rough guideline, with the new ACM format a short paper would be 2 to 7 pages and a long paper 8 to 25 pages. Authors are encouraged to publish any code associated to their papers under an open source license, so that reviewers may try the code and verify the claims. Proceedings will be printed as a Technical Report at Harvard University. Publication of a paper at this workshop is not intended to replace conference or journal publication, and does not preclude re-publication of a more complete or finished version of the paper at some later conference or in a journal. Sincerely, William E. Byrd, General Chair Nada Amin, Program Committee Chair Program Committee: Claire Alvis, Sparkfund Tom Gilray, University of Alabama, Birmingham Jason Hemann, Northeastern University Eric Holk, Google Kanae Tsushima, National Institute of Informatics

1 0

Call for Contributions: Summer BOB 2019 [Aug 21, Berlin, deadline May 17]
by Matthias Fischmann 05 Apr '19

05 Apr '19

[Online version of this email: https://bobkonf.de/2019-summer/cfc.html] Summer BOB Conference 2019 "What happens when we use what's best for a change?" http://bobkonf.de/2019-summer/cfc.html Berlin, August 21 co-located with ICFP 2019 Call for Contributions Deadline: May 17, 2019 You are engaged in software development or software architecture, and have an interesting story to tell about an advanced tools, technique, language or technology that you're using? Or a gnarly problems that these tools fail to address but should? Summer BOB is a one-time-only event, in the spirit of the spectacular Winter BOB. The International Conference on Functional Programming is coming to town, and Summer BOB will be right in the middle of it, on the last day of ICFP proper, prior to all the workshops. Summer BOB will feature two tracks: one from practitioners, and one from researchers, and foster communication and cross-pollination between these communities. If you share our vision and want to contribute, submit a proposal for a talk! NOTE: The conference fee will be waived for presenters. Travel expenses will not be covered (for exceptions see "Speaker Grants"). Topics ------ We are looking for talks about best-of-breed software technology, e.g.: - functional programming - persistent data structures and databases - types - formal methods for correctness and robustness - abstractions for concurrency and parallelism - metaprogramming - probabilistic programming - math and programming - controlled side effects - beyond REST and SOAP - effective abstractions for data analytics - … everything really that isn’t mainstream, but you think should be. Presenters should provide the audience with information that is practically useful for software developers. We're especially interested in experience reports. Other topics are also relevant, e.g.: - demos and how-tos - reports on problems that cutting-edge languages and tools should address but don't - overviews of a given field Requirements ------------ We accept proposals for presentations of 45 minutes (40 minutes talk + 5 minutes questions), as well as 90 minute tutorials for beginners. The language of presentation should be either English. Your proposal should include (in your presentation language of choice): - An abstract of max. 1500 characters. - A short bio/cv - Contact information (including at least email address) - A list of 3-5 concrete ideas of how your work can be applied in a developer's daily life - additional material (websites, blogs, slides, videos of past presentations, …) - Don't be confused: The system calls a submission event. Submit here ----------- https://bobcfc.active-group.de/bob2019-summer/cfp Speaker Grants -------------- BOB has Speaker Grants available to support speakers from groups under-represented in technology. We specifically seek women speakers and speakers who are not be able to attend the conference for financial reasons. Shepherding The program committee offers shepherding to all speakers. Shepherding provides speakers assistance with preparing their sessions, as well as a review of the talk slides. Organisation ------------ - Direct questions to contact at bobkonf dot de - Proposal deadline: May 17, 2019 - Notification: May 31, 2019 - Program: June 14, 2019 Program Committee ----------------- - Matthias Fischmann, zerobuzz UG - Matthias Neubauer, SICK AG - Nicole Rauch, Softwareentwicklung und Entwicklungscoaching - Michael Sperber, Active Group - Stefan Wehr, factis research Scientific Advisory Board - Annette Bieniusa, TU Kaiserslautern - Torsten Grust, Uni Tübingen - Peter Thiemann, Uni Freiburg More information here: http://bobkonf.de/2019-summer/programmkomitee.html

1 0

Hackage Down
by Ara Adkins 04 Apr '19

04 Apr '19

Is anybody else unable to access Hackage? I'm seeing a 502 bad gateway. _ara

2 2

Feedback on plan for checking code requirements in a GHC plugin
by Chris Smith 03 Apr '19

03 Apr '19

Hey everyone, I'm converging on a design for a new feature of CodeWorld, the Haskell-based educational programming environment that I teach with. I'm wondering if anyone has done something like this before. The goal is that when I give an assignment in a class (e.g., "modify this starting code to generalize the repeated pattern using a function"), I want the user to see a checklist of assignment requirements when they run the code. A prototype implementation is here: https://code.world/haskell#PpwpTF1wv3qIvwhohCfvSrQ There are all sorts of possible requirements, such as: "No lines longer than 80 characters", or "there must be a function called foo", or "all top-level definitions must have type signatures", or "your code must define at least 10 top-level variables, and use at least 3 where clauses", or "your definition of var should be equivalent to this one" (see Joachim Breitner's inspection testing work), or even "the function f must satisfy this QuickCheck property". It's been suggested that the requirements language also include the ability to match patterns in the AST, which I think is a good idea. The current prototype uses a pre-compile step that parses the code using haskell-src-exts, and doesn't implement dynamic requirements (runtime-evaluated) at all. My ultimate plan, though, is to send these requirements to GHC via a plugin, then have it evaluate the static ones at compile time, and generate code to check the dynamic ones. Finally, the plugin would add new code to the beginning of main that will invoke a configurable function with the results of the requirement check (hard-coding the static ones, and evaluating dynamic ones on the fly). (In the CodeWorld environment, this function would display the checklist in the web UI, for example.) Has anyone done anything like this before? Any wisdom to share, or ideas to contribute? Thanks, Chris

3 3