- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] Reading Haddock sources on hackage no longer possible with simple browsers?
by Johannes Waldmann 15 Nov '20

15 Nov '20

> I recently noticed that it is no longer possible > to read the source of a module, because extra type information > (which is likely hidden in a modern browser) > is inline with the actual sources. I confirmed your example, reading with lynx and w3m. It seems the extra text is the methods of the type classes (mentioned after "deriving") and it gets shown on on mouse-over in a graphical browser. (Re: "nobody writes code like this" - the compiler does? Some methods here seem auto-generated.) Looks like a bug in haddock, then? (Or in lynx' handling of CSS?) The actual HTML source looks legit, at least partially (see example below) This seems related: https://github.com/haskell/haddock/pull/1197 I will open an issue on accessibility. - J.W. deriving (Int -> ISBN -> ShowS [ISBN] -> ShowS ISBN -> String (Int -> ISBN -> ShowS) -> (ISBN -> String) -> ([ISBN] -> ShowS) -> Show ISBN forall a. (Int -> a -> ShowS) -> (a -> String) -> ([a] -> ShowS) -> Show a showList :: [ISBN] -> ShowS $cshowList :: [ISBN] -> ShowS show :: ISBN -> String $cshow :: ISBN -> String showsPrec :: Int -> ISBN -> ShowS $cshowsPrec :: Int -> ISBN -> ShowS Show

4 4

Reading Haddock sources on hackage no longer possible with simple browsers?
by Mario Lang 14 Nov '20

14 Nov '20

Hi. I have been using Lynx to read stuff on hacakge for a long time. I recently noticed that it is no longer possible to read the source of a module, because extra type information (which is likely hidden in a modern browser) is inline with the actual sources. This makes the go to source feature effectively useless. An example (from the ISBN package): deriving (Int -> ISBN -> ShowS [ISBN] -> ShowS ISBN -> String (Int -> ISBN -> ShowS) -> (ISBN -> String) -> ([ISBN] -> ShowS) -> Show ISBN forall a. (Int -> a -> ShowS) -> (a -> String) -> ([a] -> ShowS) -> Show a showList :: [ISBN] -> ShowS $cshowList :: [ISBN] -> ShowS show :: ISBN -> String $cshow :: ISBN -> String showsPrec :: Int -> ISBN -> ShowS $cshowsPrec :: Int -> ISBN -> ShowS Show, ISBN -> ISBN -> Bool (ISBN -> ISBN -> Bool) -> (ISBN -> ISBN -> Bool) -> Eq ISBN forall a. (a -> a -> Bool) -> (a -> a -> Bool) -> Eq a /= :: ISBN -> ISBN -> Bool $c/= :: ISBN -> ISBN -> Bool == :: ISBN -> ISBN -> Bool $c== :: ISBN -> ISBN -> Bool Eq) I know Haskell has a ton of extensions, but I am pretty sure nobody writes code like this :-) This is, frankly, pretty horrible. Can something be done to fix this? (I am aware that certain modernisations are unstoppable. However, this one looks like a bug.) -- CYa, ⡍⠁⠗⠊⠕

2 1

Generic Sorting
by Henry Laxen 14 Nov '20

14 Nov '20

Good evening Haskellers. I've done some searching but so far haven't found anything, which make me think this probably isn't possible. I am wondering if it is possible to do a "Generic Sort" on multilevel data structures. Suppose you have something like: data A = A Int [Int] data B = B Int [A] a1 = A 2 [2,1] a2 = A 1 [4,3] b = B 1 [a1,a2] genericSort b = B 1 [A 1 [3,4], A 2 [1,2]] note that not only are the A's sorted, but the list inside each A is sorted. It "sorted all the way down". Has Edward written such a thing yet? ;-) His "discrimination" library doesn't do this, in case you're wondering. Any ideas? Best wishes, Henry Laxen

3 3

support for ergonomic dependent types
by Richard Eisenberg 14 Nov '20

14 Nov '20

Hi all, The GHC Steering Committee has been struggling recently to decide on several related proposals. The struggle is all around whether we should favor making a design that is future-compatible with dependent types, or favor a design that is more cohesive with e.g. Haskell98. (Sometimes, we can have both. Those are good times.) This isn't about backward compatibility -- the design for dependent Haskell is fully backward compatible with Haskell98. It's more about how well the new features fit with the old ones. To clarify our thinking on it all, I've made a new proposal to discuss whether or not we want to favor keeping an avenue open to ergonomic dependent types in the future. If you have an opinion, please express it on the proposal. In particular, if you care about the possibility of ergonomic dependent types in Haskell, now is the time to show that support by thumbs-upping the proposal. The proposal is at https://github.com/ghc-proposals/ghc-proposals/pull/378. Thanks! Richard

1 0

Re: [Haskell-cafe] What to call Occult Effects
by Olaf Klinke 14 Nov '20

14 Nov '20

> First, instead of `const id` I will use `const`, that is, we shall > prove > > const = liftM2 const :: M a -> M b -> M a > > which I believe should be equivalent to your property. My belief was wrong, which is evident when using do-notation. Kim-Ee stated do {_ <- b; x <- a; return x} = a while I examined do {x <- a; _ <- b; return x} = a Since do {x <- a; return x} = a holds for any monad, Kim-Ee's property can be reduced to do {_ <- b; a} = a or more concisely b >> a = a which I called Kleisli-const in my previous post. As we seemed to have settled for "occlusive" I suggest calling b >> a = a "right-occlusive" or "occlusive from the right" because the right action occludes the side-effects of the left action, and do {x <- a; _ <- b; return x} = a should be called "left-occlusive" or "occlusive from the left" because the left action hides the effect of the right action. Under commutativity, both are the same but in general these might be different properties. I do not have a distinguishing counterexample, though, because all monads I come up with are commutative. David Feuer hinted at the possibility to define occlusiveness more generally for Applicative functors. Commutativity might be stated for Applicatives as liftA2 f a b = liftA2 (flip f) b a So far I can only see two classes of occlusive monads: The reader-like (Identity ~ Reader ()) and the set-like monads. Olaf

3 4

Advent of Haskell is still waiting for ideas
by Ida Bzowska 13 Nov '20

13 Nov '20

Hi there, Advent of Haskell is an advent calendar filled with Haskell content, obviously :) The first confirmations to "Advent of Haskell" participants' have been sent this week, but there are still a lot of open spots to go, so do not hesitate to submit your idea. All the details are available here: https://adventofhaskell.com Happy haskelling everyone! λCheers, Ida

1 0

caching ~/.cabal with github actions on windows
by Ben Franksen 13 Nov '20

13 Nov '20

I can't get this to work. It works perfectly fine on Linux and MacOS but on Windows cabal always re-builds all the dependencies. The cache post-action on Windows tells me that the cache hasn't changed, which means cabal actually re-created the ~/.cabal directory exactly as it was in the cache! Is this a known bug in cabal on Windows? Does anyone have a work-around? Cheers Ben

3 6

What to call Occult Effects
by Kim-Ee Yeoh 12 Nov '20

12 Nov '20

By an occult effect I mean that under the type signature (M a -> M b -> M b) of a particular monad M, the two expressions (const id) and (liftM2 $ const id) are equivalent. Occult here refers to how the effect of the second parameter blocks the effect of the first one. In your opinion, is there a better word than occult to describe the property of such monads? -- -- Kim-Ee

5 6

Re: [Haskell-cafe] What to call Occult Effects
by Kim-Ee Yeoh 12 Nov '20

12 Nov '20

On Thu, Nov 12, 2020 at 12:17 AM Justin Bailey <jgbailey(a)gmail.com> wrote: > Looking up the definition "occult" on duckduckgo > (https://duckduckgo.com/?t=ffab&q=occult+definition&ia=definition) > gives this response: > > adj. Of, relating to, or dealing with supernatural or magical > influences, agencies, or occurrences. > adj. Available only to the initiate; secret or mysterious: synonym: > mysterious. > adj. Beyond the realm of human comprehension; inscrutable. > > Doesn't seem to really apply to your type signature. If you mean in > the sense of "occlusion" or "occludes", I'd be specific ("occluded > effects"). Hi Justin, Thank you for heads up, it's just the nudge I need that "occult" probably isn't the right word although I had the astronomical usage in mind. My go-to solution is now "occlusive effects" unless something even better comes along. > > On Tue, Nov 10, 2020 at 3:24 PM Kim-Ee Yeoh <ky3(a)atamo.com> wrote: > > > > By an occult effect I mean that under the type signature (M a -> M b -> > M b) of a particular monad M, the two expressions (const id) and (liftM2 $ > const id) are equivalent. > > > > Occult here refers to how the effect of the second parameter blocks the > effect of the first one. > > > > In your opinion, is there a better word than occult to describe the > property of such monads? > > -- > > -- Kim-Ee > > _______________________________________________ > > 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. > -- -- Kim-Ee

1 0

Re: [Haskell-cafe] What to call Occult Effects (Kim-Ee Yeoh)
by Olaf Klinke 12 Nov '20

12 Nov '20

> By an occult effect I mean that under the type signature (M a -> M b > -> M > b) of a particular monad M, the two expressions (const id) and > (liftM2 $ > const id) are equivalent. > > Occult here refers to how the effect of the second parameter blocks > the > effect of the first one. > > In your opinion, is there a better word than occult to describe the > property of such monads? Dear Kim-Ee, TL;DR: Why not the simpler do {y <- b; a} = a My name for your property would be "distribution-like" or "lazy" because of an old post of mine [1]. In that thread we discussed models of probability and I emphasized the property fmap.const = const.return :: a -> M b -> M a (Functor-const) which we will see is equivalent to your occultness. Categorically it can be re-phrased as: "M as a functor maps constant functions to constant functions." First, instead of `const id` I will use `const`, that is, we shall prove const = liftM2 const :: M a -> M b -> M a (occultness) which I believe should be equivalent to your property. For the proof it will be convenient to use the following. Lemma: liftM2 f a b = a >>= (\x -> fmap (f x) b) Proof: We de-sugar the do-notation in the source code for liftM2. liftM2 f a b = a >>= (\x -> b >>= (\y -> return (f x y))) Now use the equation fmap h b = b >>= (\y -> return (h y)) with h instantiated to `f x` to obtain the desired identity. q.e.d. Armed with the Lemma we instantiate f = const. liftM2 const a b = a >>= (\x -> fmap (const x) b) If we now assume my property (Functor-const) then we may re-write to liftM2 const a b = a >>= (\x -> const (return x) b) = a >>= (\x -> return x) = a We have shown (Functor-const) implies (occultness). For the reverse implication, we shall prove (Functor-const) holds with the arguments swapped, that is, we prove the equation \b -> \x -> fmap (const x) b = \b -> \x -> return x Starting with the left-hand side, we eta-expand using the law (k :: a -> M b) x = return x >>= k and obtain \b -> \x -> (return x >>= (\x -> fmap (const x) b)) Using the Lemma we identify the expression in the outermost parentheses as liftM2 const (return x) b which by assumption equals return x, whence we re-write the entire term to \b -> \x -> return x q.e.d. Next consider a law with the same type as (occultness): (=<<).const = const :: M a -> M b -> M a (Kleisli-const) do {y <- b; a} = a (same in do-notation) Any MonadPlus fails this due to the law k =<< mzero = mzero. Categorically it can be re-phrased as "The functor from the Kleisli category of M to Hask preserves constant arrows." I will prove that if M is commutative then (Kleisli-const) implies (occultness). liftM2 const a b = do {x <- a; y <- b; return (const x y)} = do {y <- b; x <- a; return (const x y)} (by commutative) = do {y <- b; x <- a; return x} = do {y <- b; a} = a (by Kleisli-const) Probability distributions have property (Functor-const) because it essentially says that if you map any distribution through a constant function, you will end up with all mass in one place. It is related to lazyness because a priori const a :: M b -> M a is lazy in its argument whereas \b -> a >>= (\x -> fmap (const x) b) is not lazy a priori, i.e. may examine its argument b and execute side- effects. Such lazyness was desired in [1] because inspecting an argument in that context meant computationally expensive sampling of a random distribution. Are there concrete Haskell monads with this property? NonEmpty lists have this property up to multiplicity and order, that is, non-empty finite sets are an example of an occult M. The Reader monad is easily seen to have this property. And that seems to be all. Observe that my two example monads above are indeed commutative and have the property (Kleisli-const). I'm curious whether (Kleisli-const) makes sense in your application. Olaf [1] https://mail.haskell.org/pipermail/haskell-cafe/2019-October/131605.html

1 0

Three new Teaching Assistant positions in Nottingham
by Graham Hutton 11 Nov '20

11 Nov '20

Dear all, As part of a strategic expansion, the School of Computer Science at the University of Nottingham is seeking to make three new permanent appointments at Teaching Assistant level: https://www.nottingham.ac.uk/jobs/currentvacancies/ref/SCI290020 Applicants with expertise in functional programming are strongly encouraged! The deadline for applications is 11th December 2020. Best wishes, Graham — Professor Graham Hutton School of Computer Science University of Nottingham, UK http://www.cs.nott.ac.uk/~pszgmh This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please contact the sender and delete the email and attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. Email communications with the University of Nottingham may be monitored where permitted by law.

1 0

Re: [Haskell-cafe] Occult effects...
by Michal J Gajda 11 Nov '20

11 Nov '20

It is easier to understand it if: 1. You give some examples of such monads 2. Describe how this property arises 3. Tell how whether the law is unique or part of a list of laws applicable Most of mathematics we do is not entirely disconnected from applications. If I tell you there is a class of monoids `m` over a set of objects `o` : class Monoid m => T m o where i :: o -> t c :: t -> o -> Bool Such that the following laws are satisfied: Forall x y z m n. c (i x) x =True c mempty x = False c m y = True => c (m <> n) y = True c n y = True => c (m <> n) y = True What does it tell you about the definitions? Can you tell if this set of laws is correctly stated or exhaustive? Whether it models what I intend to do? Without further examples could I claim that it may be universal model for some phenomena f and g? Or would you rather see some examples or descriptions of i and c operations? PS you may respond to haskell-cafe, sure. I did not think that my previous question deserved sharing, but this answer certainly does. -- Cheers Michał On Wed, Nov 11, 2020, 14:04 Kim-Ee Yeoh <ky3(a)atamo.com> wrote: > Hi Michal, > > How is it hermetic? I think I fully described the property whose name I am > opening to discussion. > > What is lacking in the definition? > > Also, do you mind having this discussion at the cafe itself? You are > probably not the only one with this query. > > On Wed, Nov 11, 2020 at 7:37 PM Michał J Gajda <mjgajda(a)gmail.com> wrote: > >> Hi, >> Your post to haskell-cafe is somewhat hermetic if you do not provide >> additional examples. >> What do you use these for? >> -- >> Cheers >> Michał >> > -- > -- Kim-Ee >

1 0

Last Call for Contributions: BOB 2021 [Feb 26, Deadline Nov 13]
by Stefan Wehr 10 Nov '20

10 Nov '20

BOB Conference 2021 "What happens when we use what's best for a change?" http://bobkonf.de/2021/cfc.html Berlin, February 26 Call for Contributions Deadline: November 13, 2020 You are actively engaged in advanced software engineering methods, implement ambitious architectures and are open to cutting-edge innovation? Attend this conference, meet people that share your goals, and get to know the best software tools and technologies available today. We strive to offer a day full of new experiences and impressions that you can use to immediately improve your daily life as a software developer. If you share our vision and want to contribute, submit a proposal for a talk or tutorial! NOTE: The conference fee will be waived for presenters. Travel expenses will not be covered (for exceptions see "Speaker Grants"). Online or Onsite We do know yet whether BOB will happen onsite in Berlin or as an online event. Should BOB happen online, we will likely ask for pre-recorded talks to make room for questions and social interactions during the actual conference day. (Of course, we'll provide assistance making those recordings.) Tutorials will likely happen as a live-session. Speaker Grants -------------- BOB has Speaker Grants available to support speakers from groups under-represented in technology. We specifically seek women speakers, speakers of color, 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. Specifically: - advice on structure and presentation - review of talk slides - assistance with recording - review of recording, if applicable Topics ------ We are looking for talks about best-of-breed software technology, e.g.: - functional programming - persistent data structures and databases - event-based modelling and architecture - 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.: - introductory talks on technical background - overviews of a given field - demos and how-tos 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 or German. 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. Organisation ------------ - Direct questions to contact at bobkonf dot de - Proposal deadline: November 13, 2020 - Notification: November 27, 2020 - Program: December 6, 2020 Submit here: https://bobcfc.active-group.de/en/bob2021/cfp Program Committee ----------------- (more information here: https://bobkonf.de/2020/programmkomitee.html) - Matthias Fischmann, Wire - Matthias Neubauer, SICK AG - Nicole Rauch, Softwareentwicklung und Entwicklungscoaching - Michael Sperber, Active Group - Stefan Wehr, Hochschule Offenburg Scientific Advisory Board - Annette Bieniusa, TU Kaiserslautern - Torsten Grust, Uni Tübingen - Peter Thiemann, Uni Freiburg

1 0

Extended Deadline - Compiler Construction (CC) 2021
by Delphine Demange 08 Nov '20

08 Nov '20

ACM SIGPLAN 2021 International Conference on Compiler Construction (CC 2021) Co-located with CGO, HPCA and PPoPP Tue 2 - Wed 3 March 2021 https://conf.researchr.org/home/CC-2021 CALL FOR PAPERS The International Conference on Compiler Construction (CC) is interested in work on processing programs in the most general sense: analyzing, transforming or executing input that describes how a system operates, including traditional compiler construction as a special case. The abstract and full paper submission is now November 13, 2020. = IMPORTANT DATES = Abstract & Full Paper Submission: November 13, 2020 (EXTENDED) Author Response Period: December 7 - 9, 2020 Author Notification: December 22, 2020 Artifact Submission: January 5, 2021 AE Notification: January 20, 2021 Final Papers due: January 22, 2021 Conference: March 2 - 3, 2021 Original contributions are solicited on the topics of interest which include, but are not limited to: - Compilation and interpretation techniques, including program representation, analysis, and transformation; code generation, optimization, and synthesis; the verification thereof - Run-time techniques, including memory management, virtual machines, and dynamic and just-in-time compilation - Programming tools, including refactoring editors, checkers, verifiers, compilers, debuggers, and profilers - Techniques, ranging from programming languages to micro-architectural support, for specific domains such as secure, parallel, distributed, embedded or mobile environments - Design and implementation of novel language constructs, programming models, and domain-specific languages CC is an ACM SIGPLAN conference, and implements guidelines and procedures recommended by SIGPLAN (https://www.sigplan.org) Prospective authors should be aware of SIGPLAN’s Copyright policies. Proceedings will be made available online in the ACM digital library from one week before to one week after the conference. Full CfP: https://conf.researchr.org/track/CC-2021/cc-research-papers ARTIFACT EVALUATION Authors of accepted papers will be invited to submit their artifacts for the Artifact Evaluation (AE). The Artifact Evaluation process begins after the acceptance notification, and is run by a separate committee whose task is to assess how the artifacts support the work described in the papers. To ease the organization of the AE committee, we kindly ask authors to indicate at the time they submit the paper, whether they are interested in submitting an artifact. Papers that go through the Artifact Evaluation process successfully will receive a seal of approval printed on the papers themselves. Authors of accepted papers are encouraged, but not required, to make these materials publicly available upon publication of the proceedings, by including them as “source materials” in the ACM Digital Library. CC AE web page: https://conf.researchr.org/track/CC-2021/research-artifacts ORGANIZERS General Chair: Aaron Smith - Microsoft / University of Edinburgh Program Chairs: Delphine Demange - Univ Rennes, Inria, CNRS, IRISA Rajiv Gupta - UC Riverside Artifact Evaluation Chairs: Bruno Bodin - Yale-NUS College Michel Steuwer - University of Glasgow Web Chair: Martin Lücke - University of Edinburgh Steering Committee: Björn Franke (Chair) - University of Edinburgh Jose Nelson Amaral - University of Alberta Christophe Dubach - University of Edinburgh Sebastian Hack - Saarland University Manuel Hermenegildo - IMDEA Software Institute and T.U. of Madrid (UPM) Alexandra Jimborean - University of Murcia Milind Kulkarni - Purdue University Louis-Noël Pouchet - Colorado State University Peng Wu - Futurewei Technologies Jingling Xue - UNSW Sydney Ayal Zaks - Intel Corporation and Technion Program Committee: Guillaume Baudart - IBM Research Walter Binder - University of Lugano Simone Campanoni - Northwestern University Albert Cohen - Google Caroline Collange - Inria, Univ Rennes, CNRS, IRISA Huimin Cui - Institute of Computing Technology, CAS Christophe Dubach - McGill University Benoît Dupont de Dinechin - Kalray Bernhard Egger - Seoul National University Christine Flood - Red Hat Laure Gonnord - University of Lyon and LIP Myoungsoo Jung - KAIST Andrew Kennedy - Facebook Dongyoon Lee - Stony Brook University Christian Lengauer - University of Passau Xavier Leroy - Collège de France and Inria Yun Liang - Peking University Toby Murray - University of Melbourne and Data61 Biswabandan Panda - Indian Institute of Technology Kanpur Santosh Pande - Georgia Tech Louis-Noël Pouchet - Colorado State University Gabriel Rodríguez - Universidade da Coruña Jan Vitek - Northeastern University Jingling Xue - UNSW Sydney Zhijia Zhao - UC Riverside

1 0

Call for Workshop Proposals: ICFP 2021
by Sam Tobin-Hochstadt 05 Nov '20

05 Nov '20

CALL FOR WORKSHOP AND CO-LOCATED EVENT PROPOSALS ICFP 2021 26th ACM SIGPLAN International Conference on Functional Programming August 22 - 27, 2021 Daejon, Korea https://icfp21.sigplan.org/ The 26th ACM SIGPLAN International Conference on Functional Programming will be held in Daejon, Korea on August 22-27, 2021, with the possibility of a virtual conference. ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. Proposals are invited for workshops (and other co-located events, such as symposiums) to be affiliated with ICFP 2021 and sponsored by SIGPLAN. These events should be less formal and more focused than ICFP itself, include sessions that enable interaction among the attendees, and foster the exchange of new ideas. The preference is for one-day events, but other schedules can also be considered. The workshops are scheduled to occur on August 22rd (the day before ICFP) and 26-27th of August (the two days after ICFP). ---------------------------------------------------------------------- Submission details Deadline for submission: November 27, 2020 Notification of acceptance: December 15, 2020 Prospective organizers of workshops or other co-located events are invited to submit a completed workshop proposal form in plain text format to the ICFP 2021 workshop co-chairs (Leonidas Lampropoulos and Zoe Paraskevopoulou) via email to icfp-workshops-2021(a)googlegroups.com by November 27, 2020. (For proposals of co-located events other than workshops, please fill in the workshop proposal form and just leave blank any sections that do not apply.) Please note that this is a firm deadline. Organizers will be notified if their event proposal is accepted by December 15, 2020, and if successful, depending on the event, they will be asked to produce a final report after the event has taken place that is suitable for publication in SIGPLAN Notices. The proposal form is available at: http://www.icfpconference.org/icfp2021-files/icfp21-workshops-form.txt Further information about SIGPLAN sponsorship is available at: http://www.sigplan.org/Resources/Proposals/Sponsored/ ---------------------------------------------------------------------- Selection committee The proposals will be evaluated by a committee comprising the following members of the ICFP 2021 organizing committee, together with the members of the SIGPLAN executive committee. Workshop Co-Chair: Zoe Paraskevopoulou (Northeastern University) Workshop Co-Chair: Leonidas Lampropoulos (University of Maryland) General Chair: Sukyoung Ryu (KAIST) Program Chair: Ronald Garcia (University of British Columbia) ---------------------------------------------------------------------- Further information Any queries should be addressed to the workshop co-chairs (Zoe Paraskevopoulou and Leonidas Lampropoulos), via email to icfp-workshops-2021(a)googlegroups.com.

1 0

Announcing the Haskell Foundation
by Richard Eisenberg 04 Nov '20

04 Nov '20

I'm very pleased to announce the creation of the Haskell Foundation (HF), an independent, non-profit organisation dedicated to broadening Haskell adoption. Website: https://haskell.foundation/ <https://haskell.foundation/> Twitter: @haskellfound Founding whitepaper: https://haskell.foundation/whitepaper/ <https://haskell.foundation/whitepaper/> Simon Peyton Jones's announcement, with lots of Q&A: https://www.youtube.com/watch?v=MEmRarBL9kw <https://www.youtube.com/watch?v=MEmRarBL9kw> The "official" ask-me-anything on Reddit: https://www.reddit.com/r/haskell/comments/jnwg7i/haskell_foundation_ama/ <https://www.reddit.com/r/haskell/comments/jnwg7i/haskell_foundation_ama/> Mailing list for future HF announcements: https://mail.haskell.org/cgi-bin/mailman/listinfo/hf-announce <https://mail.haskell.org/cgi-bin/mailman/listinfo/hf-announce> Mailing list for HF discussion / involvement: https://mail.haskell.org/cgi-bin/mailman/listinfo/hf-discuss <https://mail.haskell.org/cgi-bin/mailman/listinfo/hf-discuss> Please join the conversation. We need your participation to realize the vision of the foundation as *our* foundation, not *their* foundation. Looking forward to seeing where this all leads! Richard

1 0

Re: [Haskell-cafe] Looking for maintainers or comaintainers on my Haskell projects
by Michal J Gajda 04 Nov '20

04 Nov '20

Hi Chris., > If you want to take xeno and make it into a publishable package, please do so. We have offered to take over xeno over a year ago, and this offer still stands backed by me personally. Since I have made a few contributions, you may know that I would deliver here. To add me as maintainer on Hackage: MichalGajda To add me on GitHub: mgajda -- Cheers Michał

1 0

Tomorrow: Simon PJ announces Haskell Foundation
by Richard Eisenberg 03 Nov '20

03 Nov '20

Tomorrow (Wednesday Nov 4) at 12:00 UTC, Simon PJ will announce the formation of the Haskell Foundation, an independent, non-profit organization dedicated to broadening Haskell adoption. This will be a part of Haskell eXchange, but this announcement will be free to attend, via YouTube. Much of the presentation will be time for Q&A; questions can be posed both within the Haskell eXchange HopIn platform and via comments on YouTube. Attend at https://youtu.be/MEmRarBL9kw <https://youtu.be/MEmRarBL9kw> Just to forestall any disappointment: I won't be answering any questions here until at least after the announcement -- but do please come and ask questions there and afterwards. Richard

1 0

Journal of Functional Programming - Call for PhD Abstracts
by Graham Hutton 03 Nov '20

03 Nov '20

Dear all, If you or one of your students recently completed a PhD in the area of functional programming, please submit the dissertation abstract for publication in JFP: simple process, no refereeing, open access, 200 published to date, deadline 30th November 2020. Please share! Best wishes, Graham Hutton ============================================================ CALL FOR PHD ABSTRACTS Journal of Functional Programming Deadline: 30th November 2020 http://tinyurl.com/jfp-phd-abstracts ============================================================ PREAMBLE: Many students complete PhDs in functional programming each year. As a service to the community, twice per year the Journal of Functional Programming publishes the abstracts from PhD dissertations completed during the previous year. The abstracts are made freely available on the JFP website, i.e. not behind any paywall. They do not require any transfer of copyright, merely a license from the author. A dissertation is eligible for inclusion if parts of it have or could have appeared in JFP, that is, if it is in the general area of functional programming. The abstracts are not reviewed. Please submit dissertation abstracts according to the instructions below. We welcome submissions from both the PhD student and PhD advisor/supervisor although we encourage them to coordinate. ============================================================ SUBMISSION: Please submit the following information to Graham Hutton <graham.hutton(a)nottingham.ac.uk> by 30th November 2020: o Dissertation title: (including any subtitle) o Student: (full name) o Awarding institution: (full name and country) o Date of PhD award: (month and year; depending on the institution, this may be the date of the viva, corrections being approved, graduation ceremony, or otherwise) o Advisor/supervisor: (full names) o Dissertation URL: (please provide a permanently accessible link to the dissertation if you have one, such as to an institutional repository or other public archive; links to personal web pages should be considered a last resort) o Dissertation abstract: (plain text, maximum 350 words; you may use \emph{...} for emphasis, but we prefer no other markup or formatting; if your original abstract exceeds the word limit, please submit an abridged version within the limit) Please do not submit a copy of the dissertation itself, as this is not required. JFP reserves the right to decline to publish abstracts that are not deemed appropriate. ============================================================ PHD ABSTRACT EDITOR: Graham Hutton School of Computer Science University of Nottingham Nottingham NG8 1BB United Kingdom ============================================================ This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please contact the sender and delete the email and attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. Email communications with the University of Nottingham may be monitored where permitted by law.

1 0

Hackage and searching for substrings
by Magnus Therning 02 Nov '20

02 Nov '20

Just now I thought I'd check what kind of lib waargonaut is. Being lazy I typed "waarg" into the package search box and found nothing! Is there a way to make Hackage find waargonaut without having to type the full package name? /M -- Magnus Therning OpenPGP: 0x927912051716CE39 email: magnus(a)therning.org twitter: magthe http://magnus.therning.org/ It is better to keep your mouth shut and appear stupid than to open it and remove all doubt. — Mark Twain

6 7

Intention to take over the pipes-text package
by Peter J. Jones 02 Nov '20

02 Nov '20

(This is a re-post from October 6, 2020 since the original did not make it into the archive.) The pipes-text [1] package on Hackage hasn't been updated in about 4 years and doesn't currently build due to outdated `build-depends'. Patches have been supplied to the GitHub [2] repository but none have been merged. The last commit was on Dec 2, 2016. I have attempted to reach out to the author (Michael Thompson) to offer assistance and have not received any response. As per the instructions on the Haskell Wiki, I'm posting this message to signal my intent to take over the pipes-text package as a maintainer. I have a working fork here [3]. Michael, if you prefer to keep the package under your control I'm more than happy to help you manage the GitHub project and get some patches merged. Otherwise I'll reach out to the Hackage administrators after a reasonable amount of time has passed. [1]: https://hackage.haskell.org/package/pipes-text [2]: https://github.com/michaelt/text-pipes [3]: https://github.com/pjones/pipes-text

2 1

GHC-8.6.3 question.
by David Duke 02 Nov '20

02 Nov '20

Dear colleagues I'm in the process of having to reinstall ghc-8.6.3 in order to use a library (gtk) where the last successful build is 8.6.3. I was able to do that on linux. However I'm now trying to repeat this under OSX. I couldn't find a binary version, so I've been trying to build from source- but i'm hitting an issue on 'make install': stage2/build/libHSghc-8.6.3_p.a: copyFile: does not exist (No such file or directory) I'm not seeing a stage2 directory in my build area, but I'm not seeing any earlier error messages so I'm unclear why the build is failing. If someone familiar with this release and/or th build process could suggest any causes or fixes that would be helpful. thanks, David Duke

3 3

2020 State of Haskell Survey
by Taylor Fausak 01 Nov '20

01 Nov '20

Hi friends! I am very excited to announce the fourth annual state of Haskell survey. It opens today (the 1st) and stays open for two weeks (the 15th). I would greatly appreciate it if you could take 10 minutes to fill it out. Thanks! https://haskellweekly.news/survey/2020.html

1 0

Re: [Haskell-cafe] Split the IsList class for OverloadedLists
by Olaf Klinke 31 Oct '20

31 Oct '20

> Hello Café, > > Right now the IsList class used by the OverloadedLists extension > requires both fromList, to construct something using list syntax, > and > toList, to pattern-match on something using list syntax. > > So types implementing that class are expected to be isomorphic to > lists. > This is a very strong restriction. In particular, this gets in the > way > of implementing IsList for aeson's Value type[1], since there's no > sensible total implementation of toList. > > [1]: That is a recently proposed idea > https://github.com/bos/aeson/issues/813 For constructing values from list syntax, I can understand that only fromList is used and Aeson's Value indeed contains lists. But if both fromList and toList are required, I would expect that fromList.toList=id and I can not see how that can ever be achieved with Aeson Values. Maybe a lightweight quasi-quoter can be syntactically almost as convenient for construction? MonoFoldable and MonoTraversable instances for Value might also be helpful: MonoFoldable gives you a toList function. > > > Proposal: split toList and fromList in two separate classes. > > (And modify the OverloadedLists extension accordingly.) > > Since they rely on an associated type family Item, it would be made > a > standalone family. > > > type family Item (l :: Type) :: Type > > class ToList l where > toList :: l -> [Item l] > > class FromList l where > fromList :: [Item l] -> l > fromListN :: Int -> [Item l] -> l > > > (Note: we can't just replace ToList with Foldable, because these > classes > have different kinds.) > > > - Any objections? An obvious concern is backwards compatibility. Is > that > a deal breaker? Are there other issues with this idea? You would lose the pattern matching functionality, it seems. It reminds me very much of OverloadedStrings and that is not always as convenient as you might think. The issue is that a previously monomorphic piece of syntax suddenly is polymorphic, so in some places with OveroadedStrings one must provide type annotations. And that destroys the brevity one was after. > > - Should that be a GHC proposal[2]? > > - Has this been discussed before? > > [2]: https://github.com/ghc-proposals/ghc-proposals > > > One alternative is to use RebindableSyntax, which already allows > users > to redefine toList and fromList however they want. The issue is it > might > also mess with all other kinds of syntactic sugar just enough that > the > unpleasantness is not worth the trouble. > > For example, if you wanted to use multiple list-like types in one > module, you would want an overloaded version of fromList/fromListN. > You > either roll your own or find a suitable dependency. Either way it's > overhead you might not be willing to pay for, as opposed to > something > that's already in base and Just Works. > > So even with some existing workarounds in mind, the above proposal > seems > a net improvement over the status quo. > > Maybe some day we'll also get to take fromInteger out of Num. > > Regards, > Li-yao >

2 1

[CFP]Agile and Functional Data Pipelines workshop
by mgajda＠mimuw.edu.pl 31 Oct '20

31 Oct '20

Dear Friends, The emerging interest in the rigorous and agile data science and functional ETL pipelines has driven the developments of many new libraries, frameworks and methodologies. We invite industry practitioners and academics to present their latest work on agile functional data pipelines as a workshop at the EDI'2021 conference. Call for papers =============== The following would be accepted: - Exposures of methodologies for building agile functional data pipelines - Presentations of frameworks used for data pipelines in industry and academia - Experience reports from building of data pipelines in industry and academia - Benchmarks and optimization of agile data pipeline frameworks - Solutions to data integration and exchange problems within ETL pipelines. In particular, we encourage: - Agile functional data methodologists - Authors of ETL frameworks, streaming libraries and databases, reactive streaming, streaming benchmarks, high-performance workflow engines - Position papers on the use of agile and functional data methodologies - Descriptions of environments for interactive and live programming with data - Benchmarks of state-of-the-art solutions for agile functional data pipelines. Details at https://afdp.github.io Important dates =============== Abstract registration deadline : December 15th, 2020 Submission deadline : December 22nd, 2020 Acceptance notification : January 12th 2021 Final manuscripts : January 23rd, 2021 Presentation at the conference : March 23rd-26th 2021 Submission instructions ======================= Original, unpublished papers are solicited for presentation at the AFDP workshop. Prospective authors are invited to submit papers (electronically, PDF only) that are no longer than 6 pages for full papers, including all figures and references. For work-in-progress, we also solicit extended abstracts for presentations. The submitted paper must be formatted according to the guidelines of Procedia Computer Science. All accepted papers will be published in Procedia Computer Science. Location ======== This workshop will be held as a part of [The 4th International Conference on Emerging Data and Industry 4.0 (EDI40)](http://cs-conferences.acadiau.ca/EDI40-21/) held on March 23 - 26, 2021 in Warsaw, Poland. -- Best regards MichaB

1 0

Re: [Haskell-cafe] Panmusic?
by Johannes Waldmann 30 Oct '20

30 Oct '20

> Is anyone working on the universal music notation > converter in Haskell? https://github.com/music-suite/music-suite http://music-suite.github.io/docs/ref/ I think this intends to be "the pandoc of music". I was looking into lilypond parsing for that, see my fork https://github.com/jwaldmann/lilypond-parse#goals but I'm currently stalled on this, for lack of time - and for the thorough mess that lilypond makes of mixing lexing, parsing, and semantics. It's as bad as TeX ... - J.

2 2

Split the IsList class for OverloadedLists
by Li-yao Xia 30 Oct '20

30 Oct '20

Hello Café, Right now the IsList class used by the OverloadedLists extension requires both fromList, to construct something using list syntax, and toList, to pattern-match on something using list syntax. So types implementing that class are expected to be isomorphic to lists. This is a very strong restriction. In particular, this gets in the way of implementing IsList for aeson's Value type[1], since there's no sensible total implementation of toList. [1]: That is a recently proposed idea https://github.com/bos/aeson/issues/813 Proposal: split toList and fromList in two separate classes. (And modify the OverloadedLists extension accordingly.) Since they rely on an associated type family Item, it would be made a standalone family. type family Item (l :: Type) :: Type class ToList l where toList :: l -> [Item l] class FromList l where fromList :: [Item l] -> l fromListN :: Int -> [Item l] -> l (Note: we can't just replace ToList with Foldable, because these classes have different kinds.) - Any objections? An obvious concern is backwards compatibility. Is that a deal breaker? Are there other issues with this idea? - Should that be a GHC proposal[2]? - Has this been discussed before? [2]: https://github.com/ghc-proposals/ghc-proposals One alternative is to use RebindableSyntax, which already allows users to redefine toList and fromList however they want. The issue is it might also mess with all other kinds of syntactic sugar just enough that the unpleasantness is not worth the trouble. For example, if you wanted to use multiple list-like types in one module, you would want an overloaded version of fromList/fromListN. You either roll your own or find a suitable dependency. Either way it's overhead you might not be willing to pay for, as opposed to something that's already in base and Just Works. So even with some existing workarounds in mind, the above proposal seems a net improvement over the status quo. Maybe some day we'll also get to take fromInteger out of Num. Regards, Li-yao

1 0

2nd Call for Contributions: BOB 2021 [Feb 26, Deadline Nov 13]
by Stefan Wehr 30 Oct '20

30 Oct '20

BOB Conference 2021 "What happens when we use what's best for a change?" http://bobkonf.de/2021/cfc.html Berlin, February 26 Call for Contributions Deadline: November 13, 2020 You are actively engaged in advanced software engineering methods, implement ambitious architectures and are open to cutting-edge innovation? Attend this conference, meet people that share your goals, and get to know the best software tools and technologies available today. We strive to offer a day full of new experiences and impressions that you can use to immediately improve your daily life as a software developer. If you share our vision and want to contribute, submit a proposal for a talk or tutorial! NOTE: The conference fee will be waived for presenters. Travel expenses will not be covered (for exceptions see "Speaker Grants"). Online or Onsite We do know yet whether BOB will happen onsite in Berlin or as an online event. Should BOB happen online, we will likely ask for pre-recorded talks to make room for questions and social interactions during the actual conference day. (Of course, we'll provide assistance making those recordings.) Tutorials will likely happen as a live-session. Speaker Grants -------------- BOB has Speaker Grants available to support speakers from groups under-represented in technology. We specifically seek women speakers, speakers of color, 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. Specifically: - advice on structure and presentation - review of talk slides - assistance with recording - review of recording, if applicable Topics ------ We are looking for talks about best-of-breed software technology, e.g.: - functional programming - persistent data structures and databases - event-based modelling and architecture - 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.: - introductory talks on technical background - overviews of a given field - demos and how-tos 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 or German. 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. Organisation ------------ - Direct questions to contact at bobkonf dot de - Proposal deadline: November 13, 2020 - Notification: November 27, 2020 - Program: December 6, 2020 Submit here: https://bobcfc.active-group.de/en/bob2021/cfp Program Committee ----------------- (more information here: https://bobkonf.de/2020/programmkomitee.html) - Matthias Fischmann, Wire - Matthias Neubauer, SICK AG - Nicole Rauch, Softwareentwicklung und Entwicklungscoaching - Michael Sperber, Active Group - Stefan Wehr, Hochschule Offenburg Scientific Advisory Board - Annette Bieniusa, TU Kaiserslautern - Torsten Grust, Uni Tübingen - Peter Thiemann, Uni Freiburg

1 0

Re: [Haskell-cafe] Haskell-Cafe Digest, Vol 206, Issue 17
by Michal J Gajda 30 Oct '20

30 Oct '20

Hi Ly-Xia, Compl, I would argue that `Maybe` does not scale well to debugging issues in big files. When parsing a large dataset you want: 1. Get precise coordinates and description of each fault so you can fix it. 1. Be able to parse it as far as possible to get overview of entire dataset before it can be handled in error-free way. Because of this I suggest adding resilience at the level of collections: 1. Each list of declarations, record fields etc, can be parsed with resilient version of `listOf` or `sepBy` combinators and return valid entries. In context where it replaces `forM` or `mapM` I named it `forData`: 2. Invalid entries should be put into logging monad (`WriterT [Error]` that keeps a list of errors and their coordinates). This approach can be used in monad that processes a list of records, as well as in the parser: ``` forData :: (a -> m (Either Error b)) -> WriterT [Error] m [b] type Parser e -- error type m -- monad a -- result = WriterT [e] m b parseList :: (a -> Parser m b) -> Parser m [b] ``` Argument is expanded in my Haskell.Love presentation: https://www.youtube.com/watch?v=KY27LsV11Rg&t=1281s When you want to gradually expand information on errors you can also use contravariant logging operator: ``` withErrorInfo :: (e -> f) -> Parser e m a -> Parser f m a data InFile e = InFile FilePath e parseFile filename = do addErrorInfo (InFile filename) $ do input <- liftIO (readFile filename) parseFile input ``` This gradual enrichment of error messages is frequently seen in IOHK project's state machines if you enjoy reading their source code. (If you want to make it more efficient by immediately processing errors instead of tagging them along in alist, please look at contravariant logging, But I usually recommend error aggregation as a last stage of processing to discover the most serious issues.) -- Cheers Michał ________________________________ Hi Compl, At least, for the example you gave on this list, it can be fixed by returning Nothing instead of using the facility for failure baked into (mega)parsec. (Proposed diff for reference: https://github.com/complyue/dcp/pull/3) "Returning Nothing" can be seen as adding a new channel for errors, turning the Parser monad into `MaybeT Parser`. Then `return Nothing` is how `empty` is defined by `MaybeT`, allowing that error to be caught and recovered from at the point where it was thrown, no backtracking. (And the original failure mode of Parser becomes `lift empty`.) Does that address your problem? Cheers, Li-yao On 10/28/2020 5:18 AM, Compl Yue wrote: > > I'm still not fully clear about the confusion regarding megaparsec's > behavior that I posted lately here. But now comes to my mind that it may > have some problem rooted in the lacking of recoverability semantic with > respect to parser combinators, some quoting from > http://hackage.haskell.org/package/parser-combinators/docs/Control-Applicat… > > The *A note on backtracking* section > > > Combinators in this module are defined in terms Applicative and > Alternative operations. > > And `empty`'s doc: > > > This parser fails unconditionally without providing any information > about the cause of the failure. > > Clearly `empty` is used to express failure, but there is seemingly no > device to explicitly express whether a failure is recoverable. Then I > observed megaparsec's implicit rule as currently implemented is like: > > *) a failure with no input consumed can be recovered by rest parsers > *) a failure with some input consumed can not be recovered by rest parsers > > This works to great extent, but I would think the expressiveness can be > further extended for a parser from the application, to tell the library > that some input induces recoverable failure. > > I have no expertise to suggest whether `MonadPlus` and/or `MonadFail` > are suitable devices to be considered, but as megaparsec has implemented > instances for them, I do feel some tweaks would be possible and meaningful. On Thu, Oct 29, 2020 at 1:01 PM <haskell-cafe-request(a)haskell.org> wrote: > > Send Haskell-Cafe mailing list submissions to > haskell-cafe(a)haskell.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > or, via email, send a message with subject or body 'help' to > haskell-cafe-request(a)haskell.org > > You can reach the person managing the list at > haskell-cafe-owner(a)haskell.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Haskell-Cafe digest..." > Today's Topics: > > 1. Re: Consider adding recoverability to the vocabulary of > parser combinators (Li-yao Xia) > 2. Re: Consider adding recoverability to the vocabulary of > parser combinators (Compl Yue) > 3. Re: Consider adding recoverability to the vocabulary of > parser combinators (Compl Yue) > > > > ---------- Forwarded message ---------- > From: Li-yao Xia <lysxia(a)gmail.com> > To: Compl Yue <compl.yue(a)gmail.com> > Cc: "Haskell Café" <haskell-cafe(a)haskell.org> > Bcc: > Date: Wed, 28 Oct 2020 08:19:52 -0400 > Subject: Re: [Haskell-cafe] Consider adding recoverability to the vocabulary of parser combinators > Hi Compl, > > At least, for the example you gave on this list, it can be fixed by > returning Nothing instead of using the facility for failure baked into > (mega)parsec. (Proposed diff for reference: > https://github.com/complyue/dcp/pull/3) > > "Returning Nothing" can be seen as adding a new channel for errors, > turning the Parser monad into `MaybeT Parser`. Then `return Nothing` is > how `empty` is defined by `MaybeT`, allowing that error to be caught and > recovered from at the point where it was thrown, no backtracking. (And > the original failure mode of Parser becomes `lift empty`.) > > Does that address your problem? > > Cheers, > Li-yao > > On 10/28/2020 5:18 AM, Compl Yue wrote: > > (sorry for repost, seems GMail's html processing on my last email has > > rendered it barely readable, so again with plain text here) > > > > Dear Cafe, > > > > I'm still not fully clear about the confusion regarding megaparsec's > > behavior that I posted lately here. But now comes to my mind that it may > > have some problem rooted in the lacking of recoverability semantic with > > respect to parser combinators, some quoting from > > http://hackage.haskell.org/package/parser-combinators/docs/Control-Applicat… > > > > The *A note on backtracking* section > > > > > Combinators in this module are defined in terms Applicative and > > Alternative operations. > > > > And `empty`'s doc: > > > > > This parser fails unconditionally without providing any information > > about the cause of the failure. > > > > Clearly `empty` is used to express failure, but there is seemingly no > > device to explicitly express whether a failure is recoverable. Then I > > observed megaparsec's implicit rule as currently implemented is like: > > > > *) a failure with no input consumed can be recovered by rest parsers > > *) a failure with some input consumed can not be recovered by rest parsers > > > > This works to great extent, but I would think the expressiveness can be > > further extended for a parser from the application, to tell the library > > that some input induces recoverable failure. > > > > I have no expertise to suggest whether `MonadPlus` and/or `MonadFail` > > are suitable devices to be considered, but as megaparsec has implemented > > instances for them, I do feel some tweaks would be possible and meaningful. > > > > Best regards, > > Compl > > > > > > _______________________________________________ > > 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. > > > > > > > ---------- Forwarded message ---------- > From: Compl Yue <compl.yue(a)gmail.com> > To: Li-yao Xia <lysxia(a)gmail.com> > Cc: "Haskell Café" <haskell-cafe(a)haskell.org> > Bcc: > Date: Wed, 28 Oct 2020 21:37:11 +0800 > Subject: Re: [Haskell-cafe] Consider adding recoverability to the vocabulary of parser combinators > Hi Li-yao, > > I appreciate your help especially the PR as a working fix. > > But personally I don't like the overall method of your solution, I can see Monad Transformers are powerful enough to tackle similar problems, but I'm not satisfied by the ergonomics in composing monads with transformers. `ParsecT` had already caused me much pain to get started in the beginning, and I'm still not fluent (comfortable) in transforming monads, especially I'm afraid I will have to transform much of the standard combinator functions, in order to get the real case parser working, as its resulting AST is much more complex. > > I still have faith in the improvement of megaparsec as a well known parser combinator library (I regard it as the best for engineering needs among other libraries), and I must admit megaparsec already elegantly works 99% out of my current use cases, and the very issue we are talking about is a nice-to-have rather than must-to-have, so I would think we still have time to anticipate more options to come out. > > And I particularly like to see parser combinators have this issue addressed in its own design space. > > Thanks again with best regards, > Compl > > > On Wed, Oct 28, 2020 at 8:19 PM Li-yao Xia <lysxia(a)gmail.com> wrote: >> >> Hi Compl, >> >> At least, for the example you gave on this list, it can be fixed by >> returning Nothing instead of using the facility for failure baked into >> (mega)parsec. (Proposed diff for reference: >> https://github.com/complyue/dcp/pull/3) >> >> "Returning Nothing" can be seen as adding a new channel for errors, >> turning the Parser monad into `MaybeT Parser`. Then `return Nothing` is >> how `empty` is defined by `MaybeT`, allowing that error to be caught and >> recovered from at the point where it was thrown, no backtracking. (And >> the original failure mode of Parser becomes `lift empty`.) >> >> Does that address your problem? >> >> Cheers, >> Li-yao >> >> On 10/28/2020 5:18 AM, Compl Yue wrote: >> > (sorry for repost, seems GMail's html processing on my last email has >> > rendered it barely readable, so again with plain text here) >> > >> > Dear Cafe, >> > >> > I'm still not fully clear about the confusion regarding megaparsec's >> > behavior that I posted lately here. But now comes to my mind that it may >> > have some problem rooted in the lacking of recoverability semantic with >> > respect to parser combinators, some quoting from >> > http://hackage.haskell.org/package/parser-combinators/docs/Control-Applicat… >> > >> > The *A note on backtracking* section >> > >> > > Combinators in this module are defined in terms Applicative and >> > Alternative operations. >> > >> > And `empty`'s doc: >> > >> > > This parser fails unconditionally without providing any information >> > about the cause of the failure. >> > >> > Clearly `empty` is used to express failure, but there is seemingly no >> > device to explicitly express whether a failure is recoverable. Then I >> > observed megaparsec's implicit rule as currently implemented is like: >> > >> > *) a failure with no input consumed can be recovered by rest parsers >> > *) a failure with some input consumed can not be recovered by rest parsers >> > >> > This works to great extent, but I would think the expressiveness can be >> > further extended for a parser from the application, to tell the library >> > that some input induces recoverable failure. >> > >> > I have no expertise to suggest whether `MonadPlus` and/or `MonadFail` >> > are suitable devices to be considered, but as megaparsec has implemented >> > instances for them, I do feel some tweaks would be possible and meaningful. >> > >> > Best regards, >> > Compl >> > >> > >> > _______________________________________________ >> > 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. >> > > > > > > ---------- Forwarded message ---------- > From: Compl Yue <compl.yue(a)gmail.com> > To: Li-yao Xia <lysxia(a)gmail.com> > Cc: "Haskell Café" <haskell-cafe(a)haskell.org> > Bcc: > Date: Wed, 28 Oct 2020 21:48:37 +0800 > Subject: Re: [Haskell-cafe] Consider adding recoverability to the vocabulary of parser combinators > (sorry I forgot the text color again, maybe https://darkreader.org is > to blame, anyway plain text mode I should use) > > Hi Li-yao, > > I appreciate your help especially the PR as a working fix. > > But personally I don't like the overall method of your solution, I can > see Monad Transformers are powerful enough to tackle similar problems, > but I'm not satisfied by the ergonomics in composing monads with > transformers. `ParsecT` had already caused me much pain to get started > in the beginning, and I'm still not fluent (comfortable) in > transforming monads, especially I'm afraid I will have to transform > much of the standard combinator functions, in order to get the real > case parser working, as its resulting AST is much more complex. > > I still have faith in the improvement of megaparsec as a well known > parser combinator library (I regard it as the best for engineering > needs among other libraries), and I must admit megaparsec already > elegantly works 99% out of my current use cases, and the very issue we > are talking about is a nice-to-have rather than must-to-have, so I > would think we still have time to anticipate more options to come out. > > And I particularly like to see parser combinators have this issue > addressed in its own design space. > > Thanks again with best regards, > Compl > > On Wed, Oct 28, 2020 at 8:19 PM Li-yao Xia <lysxia(a)gmail.com> wrote: > > > > Hi Compl, > > > > At least, for the example you gave on this list, it can be fixed by > > returning Nothing instead of using the facility for failure baked into > > (mega)parsec. (Proposed diff for reference: > > https://github.com/complyue/dcp/pull/3) > > > > "Returning Nothing" can be seen as adding a new channel for errors, > > turning the Parser monad into `MaybeT Parser`. Then `return Nothing` is > > how `empty` is defined by `MaybeT`, allowing that error to be caught and > > recovered from at the point where it was thrown, no backtracking. (And > > the original failure mode of Parser becomes `lift empty`.) > > > > Does that address your problem? > > > > Cheers, > > Li-yao > > > > On 10/28/2020 5:18 AM, Compl Yue wrote: > > > (sorry for repost, seems GMail's html processing on my last email has > > > rendered it barely readable, so again with plain text here) > > > > > > Dear Cafe, > > > > > > I'm still not fully clear about the confusion regarding megaparsec's > > > behavior that I posted lately here. But now comes to my mind that it may > > > have some problem rooted in the lacking of recoverability semantic with > > > respect to parser combinators, some quoting from > > > http://hackage.haskell.org/package/parser-combinators/docs/Control-Applicat… > > > > > > The *A note on backtracking* section > > > > > > > Combinators in this module are defined in terms Applicative and > > > Alternative operations. > > > > > > And `empty`'s doc: > > > > > > > This parser fails unconditionally without providing any information > > > about the cause of the failure. > > > > > > Clearly `empty` is used to express failure, but there is seemingly no > > > device to explicitly express whether a failure is recoverable. Then I > > > observed megaparsec's implicit rule as currently implemented is like: > > > > > > *) a failure with no input consumed can be recovered by rest parsers > > > *) a failure with some input consumed can not be recovered by rest parsers > > > > > > This works to great extent, but I would think the expressiveness can be > > > further extended for a parser from the application, to tell the library > > > that some input induces recoverable failure. > > > > > > I have no expertise to suggest whether `MonadPlus` and/or `MonadFail` > > > are suitable devices to be considered, but as megaparsec has implemented > > > instances for them, I do feel some tweaks would be possible and meaningful. > > > > > > Best regards, > > > Compl > > > > > > > > > _______________________________________________ > > > 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. > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -- Pozdrawiam Michał

4 4

Panmusic?
by Mario Lang 30 Oct '20

30 Oct '20

Hi. With all this recent talk of parsing, and me being in the process of redoing my homepage with Hakyll (read, Pandoc) I can not help but think of a long-term project of mine. I've written two different programs to handle braille music code. FreeDots[1] (Java) which converts MusicXML to Braille Music Code, and BMC[2] (C++) which converts Braille Music Code to LilyPond and MusicXML. Combining the insight that Haskell is perfect for writing compilers, and Pandoc being one of the most successful Haskell applications, I can not help but wonder: Maybe I am after Panmusic? Before another wasted attempt of stupidly reinventing the wheel, I need to ask: Is anyone working on the universal music notation converter in Haskell? If not yet, would you be interested to? The colest thing I know to a versatile format converter right now is music21[3]. However, I'd much rather see this job done in Haskell then in any other language. [1] https://github.com/mlang/freedots [2] https://github.com/mlang/bmc [3] https://github.com/cuthbertLab/music21 -- CYa, ⡍⠁⠗⠊⠕

1 0

UNSUBSCRIBE
by Elan-Mentholer 29 Oct '20

29 Oct '20

UNSUBSCRIBE

1 0

Consider adding recoverability to the vocabulary of parser combinators
by Compl Yue 29 Oct '20

29 Oct '20

Dear Cafe, I'm still not fully clear about the confusion regarding megaparsec's behavior that I posted lately here. But now comes to my mind that it may have some problem rooted in the lacking of recoverability semantic with respect to parser combinators, some quoting from http://hackage.haskell.org/package/parser-combinators/docs/Control-Applicat… The *A note on backtracking* section > Combinators in this module are defined in terms Applicative <http://hackage.haskell.org/package/base-4.12.0.0/docs/Control-Applicative.h…> and Alternative <http://hackage.haskell.org/package/base-4.12.0.0/docs/Control-Applicative.h…> operations. And `empty`'s doc: > This parser fails unconditionally without providing any information about the cause of the failure. Clearly `empty` is used to express failure, but there is seemingly no device to explicitly express whether a failure is recoverable. Then I observed megaparsec's implicit rule as currently implemented is like: *) a failure with no input consumed can be recovered by rest parsers *) a failure with some input consumed can not be recovered by rest parsers This works to great extent, but I would think the expressiveness can be further extended for a parser from the application, to tell the library that some input induces recoverable failure. I have no expertise to suggest whether `MonadPlus` and/or `MonadFail` are suitable devices to be considered, but as megaparsec has implemented instances for them, I do feel some tweaks would be possible and meaningful. Best regards, Compl

2 1

Consider adding recoverability to the vocabulary of parser combinators
by Compl Yue 28 Oct '20

28 Oct '20

(sorry for repost, seems GMail's html processing on my last email has rendered it barely readable, so again with plain text here) Dear Cafe, I'm still not fully clear about the confusion regarding megaparsec's behavior that I posted lately here. But now comes to my mind that it may have some problem rooted in the lacking of recoverability semantic with respect to parser combinators, some quoting from http://hackage.haskell.org/package/parser-combinators/docs/Control-Applicat… The *A note on backtracking* section > Combinators in this module are defined in terms Applicative and Alternative operations. And `empty`'s doc: > This parser fails unconditionally without providing any information about the cause of the failure. Clearly `empty` is used to express failure, but there is seemingly no device to explicitly express whether a failure is recoverable. Then I observed megaparsec's implicit rule as currently implemented is like: *) a failure with no input consumed can be recovered by rest parsers *) a failure with some input consumed can not be recovered by rest parsers This works to great extent, but I would think the expressiveness can be further extended for a parser from the application, to tell the library that some input induces recoverable failure. I have no expertise to suggest whether `MonadPlus` and/or `MonadFail` are suitable devices to be considered, but as megaparsec has implemented instances for them, I do feel some tweaks would be possible and meaningful. Best regards, Compl

2 3

Does it violate the laws of Alternative/Monoid to implement empty/mempty with mzero from MonadPlus?
by Olaf Klinke 27 Oct '20

27 Oct '20

I used to think that an Alternative is just an Applicative which is also a Monoid but apparently there is no consensus about this [1,2]. Actually it kind of makes sense to make the 'empty' parser fail: Consider the parser combinator choice = Data.Foldable.asum = foldr (<|>) empty which folds over a list of Alternatives. Its semantics can be regarded analogous to 'any' for a list of Booleans, and in the latter the empty list evaluates to False. Put differently: The parser (p <|> q) matches at least as many inputs than either p or q. Hence the neutral element for <|> ought to be the parser that matches the least amount of inputs, but a parser that succeeds on the empty string _does_ match some input. It would be the neutral element for the monoid operation that concatenates parsers. Olaf [1] https://en.wikibooks.org/wiki/Haskell/Alternative_and_MonadPlus [2] https://wiki.haskell.org/MonadPlus

4 10

[Job] Cross Compass is hiring Haskell developers
by Ramin Honary 27 Oct '20

27 Oct '20

Cross Compass ( https://www.cross-compass.com/ ) is a data science and machine learning consultancy located in Tokyo, Japan. We are hiring Haskellers to work on a machine learning platform. We are mainly looking for people skilled in either web programming, machine learning, or embedded development. Technical skills used on our team ================================= Our machine learning platform has quite a few moving parts: - two web frontends (one written in PureScript, and one written in TypeScript) - two backends (one written in Haskell, and one written in Ruby) - a deep learning engine (written in Haskell, calling out to Caffe2) - a library for running models on embedded devices (written in C, C++ and CUDA calling out to oneDNN and cuDNN) Given these various parts, we end up touching a lot of different technologies: - Haskell, including the following libraries: - conduit - JuicyPixels - lens - servant - PureScript, including the following libraries: - affjax - argonaut - protobuf - react-basic - Nix (and a little Docker) - Ruby - TypeScript - C (and a little C++ and CUDA) - machine learning (we are currently mostly focused on deep learning) We have long-term plans to move away from Ruby and TypeScript (and towards Haskell and PureScript), but no concrete time-frame for when this will happen. What sort of developers are we looking for? =========================================== In the short term, we are planning on hiring two developers. We want to hire developers who know some combination of the above technologies, or would be interested in learning. We imagine hiring one developer who is familiar with Ruby, TypeScript, and Haskell. Machine learning experience wouldn't be necessary, but helpful. They would start out with web development in Ruby and Typescript, along with some Haskell work. Over time they would probably move more towards doing web development in Haskell and PureScript. We imagine hiring one other developer who is familiar with machine learning, Haskell, and possibly embedded development. They would help with the Haskell deep learning engine, as well as the C-based embedded library. They would probably also have the chance to help with the Haskel web backend and PureScript web frontend. We are also interested in any other candidates that have unique combinations of the above skills, or interesting backgrounds. Please don't hesitate to apply based on your background or skills. Previous working experience with Haskell or any of the other technologies listed above is not a requirement. Non-technical requirements ========================== We would prefer to hire developers that can work locally from Tokyo. We sponsor visas for developers who want to move to Japan. If we don't find anyone who is willing to relocate to Japan, we will considering hiring remote-only candidates. Most of our meetings take place in the afternoon in JST (UTC+9), which is around 5 AM UTC. Although we are flexible on this point. https://www.timeanddate.com/worldclock/converter.html?iso=20201104T050000&p… We prefer to hire developers who want to work full time (40 hours per week). Pay ==================== The salary range for this position is 6 to 8 million yen (about USD $57,000 to $75,000). Application and hiring process ============================== If this sounds interesting, please feel free to email us at recruit(a)cross-compass.com . We are not too big on standard resumes, but you are welcome to send us any information that you think would catch our attention, including things like: - relevant work history (e.g. work somewhere before using Haskell? Or maybe doing frontend development with TypeScript?) - relevant education history (e.g. took a class on machine learning?) - open-source software links (e.g. author any interesting libraries? have a cool machine learning project?) - papers, articles, blog posts, social media, or anything else which reflects well on you We'd also like to know your situation regarding on-premise work vs. remote, including whether or not you would be interested in moving to Japan. There will be one interview to learn more about you and for you to ask us questions. We will invite promising candidates to a part-time, one-month paid trial period. During this trial period we see what it is like working with you, and you get to see how we work as a team. Ideally, you'd be able to work at least a couple hours a week (so we both have an idea what is it like to work with each other when the month is over), but we are flexible with the details here. We would make you an offer after the trial-period. Haskellers at Cross Compass =========================== There are already a few Haskellers at Cross Compass. You may have interacted with us online or at various meetups and conferences. - Viktor Kronvall ( https://github.com/considerate ) - Jonas Carpay ( https://github.com/jonascarpay ) - Ramin Honary ( https://github.com/RaminHAL9001 ) - James Brock ( https://github.com/jamesdbrock ) - Dennis Gosnell ( https://functor.tokyo/ ) Other Considerations ==================== - We would consider hiring someone part-time with a lot of experience, although we would probably only do this if we don't find someone willing to work full time. - Being able to speak Japanese is not a requirement. - HR will often help employees new to Japan with things like finding an apartment, opening a bank account, getting a cell phone, etc. - We don't particularly have any requirements regarding years of experience. Coronavirus =========== - It is currently possible for people to get a work visa and come to Japan. (At one point foreigners weren't able to enter Japan, but this restriction has been relaxed and now people can enter with a work visa.) - Over the last few months, there are on average a couple hundred cases per day in Tokyo. - Most people in Cross Compass have been working remotely since Coronavirus became a problem in Tokyo. Some people go in to the office once or twice a week. I imagine this will continue until cases of Coronavirus start to drop. I don't know what the plans for what the remote working situation will be like when Coronavirus is no longer a problem. If you're concerned about this, please make sure to ask about this in your application email.

1 0

error when running stack
by Dennis Raddle 26 Oct '20

26 Oct '20

I get this error when running stack: Downloading lts- xxxx building plan aesonException "Error in $['system-info']: key \"os\" not present" running "stack update" didn't help. I'm very confused because I don't remember what I did that provoked this error. Anyone know what's going on? Dennis

3 4

Does it violate the laws of Alternative/Monoid to implement empty/mempty with mzero from MonadPlus?
by Compl Yue 26 Oct '20

26 Oct '20

Dear Cafe, Regarding the Alternative instance of ParsecT from Megaparsec here: https://github.com/mrkkrp/megaparsec/blob/ccf314b0b940bdbfec3820b18f42d241e… (https://link.getmailspring.com/link/34AABC73-FAC8-4126-8356-62E7FE0DA273@ge…) -- | 'empty' is a parser that __fails__ without consuming input. instance (Ord e, Stream s) => Alternative (ParsecT e s m) where empty = mzero (<|>) = mplus I come to this question, does it violate the laws of Alternative/Monoid to implement empty/mempty with mzero from MonadPlus? First of all, can I somehow regard Alternative as a repurposed Monoid? So this question applies similarly to Monoid as well? Then I think the lack of failure semantic in Alternative/Monoid might have two different interpretations: 1) It must NOT fail 2) Whether it can fail or not is not cared Which one is correct? I feel 1) is in spirit of purism, that pure code should not fail, but it's a monad, then 2) may in monad's spirit to be effectful and composable with other effects including failing. I'd think it violates the law when interpretation 1) is taken. Background about my confusion: https://github.com/mrkkrp/megaparsec/issues/429#issuecomment-716170935 (https://link.getmailspring.com/link/34AABC73-FAC8-4126-8356-62E7FE0DA273@ge…) The parsing of whitespaces is so handled in Megaparsec's idiom that every lexeme should consume (discard) all whitespaces following it. But after tinkered around with some related issues, I by now would think a silent, joinable empty / mempty might be more sense making for each whitespace block to be parsed individually, i.e. without association with any lexeme while neither will fail the overall parsing. The demand comes in that I'd like the doc comment parser to evaulate to empty and contribute nothing to an enclosing many , in case all following it is whtespaces till eof; while in case it's followed by some artifact definition, the doc comment parser should evaluate to a syntactic doc node assoicated with that artifact. empty seems an ideal device for that purpose, but in the fact it is implemented with mzero, the overall parsing will fail, which makes it infeasible. Best regards, Compl

1 0

How to encode *NoMatch* after consumed some input in a parser
by YueCompl 25 Oct '20

25 Oct '20

Dear Cafe, This is a followup question to my previous one. Also asked as a Megaparsec question issue at https://github.com/mrkkrp/megaparsec/issues/429 <https://github.com/mrkkrp/megaparsec/issues/429> As I observed (have no idea where a canonical definition could live for this) that for the contract of parser combinators: fail with no input consumed will have next alternative to be tried with possible success fail with some input consumed will err out immediately regardless rest alternatives Am I right about these rules? Where is the official specification of such rules? Then I guess that empty result of a parser could mean NoMatch even after consumed some input, and want to leverage this semantic, but encountered error with current implementation https://github.com/complyue/dcp/blob/5be688396b7e2bda00ea80fd99d2a7b3ec5c78… <https://github.com/complyue/dcp/blob/5be688396b7e2bda00ea80fd99d2a7b3ec5c78…> artifactDecl :: Parser ArtDecl artifactDecl = do artCmt <- immediateDocComments (eof >> empty) <|> do artBody <- takeWhileP (Just "artifact body") (not . flip elem (";{" :: [Char])) if T.null $ T.strip artBody then empty -- this is not possible in real cases else return (artCmt, artBody) $ cabal run dcp < samples/full.txt Up to date dcp: 73:1: | 73 | <empty line> | ^ expecting "{#", "{##", or artifact body CallStack (from HasCallStack): error, called at src/Parser.hs:151:14 in main:Parser So how can I achieve that? Background is I'm trying to prototype an implementation of doc comment parsing as described at #428 <https://github.com/mrkkrp/megaparsec/issues/428> Best regards, Compl

1 0

Reason about a Megaparsec error
by YueCompl 25 Oct '20

25 Oct '20

Dear Cafe, I find myself unable to reason about an error that `optional` in a parser err out instead of return Nothing, I asked the question at StackOverflow, and would like to seek your help here as well. https://stackoverflow.com/questions/64522568/why-optional-in-a-parser-can-e… <https://stackoverflow.com/questions/64522568/why-optional-in-a-parser-can-e…> https://github.com/complyue/dcp <https://github.com/complyue/dcp> is a minimum working example to reprod this error $ cabal run dcp:dcp < samples/basic.txt Up to date dcp: 10:1: | 10 | method doXXX() pass | ^ unexpected 'm' expecting ';' CallStack (from HasCallStack): error, called at src/Parser.hs:149:14 in main:Parser $ I believe it's optionalSemicolon causing the failure: https://github.com/complyue/dcp/blob/1df7ad590d78d4fa9a017eb53f9f265e291bdf… <https://github.com/complyue/dcp/blob/1df7ad590d78d4fa9a017eb53f9f265e291bdf…> findIt = do -- ignore leading whitespaces and an optional semicolon in between nbsc >> optionalSemicolon >> nbsc -- try get a doc comment block getIt >>= \case And it's defined like this: https://github.com/complyue/dcp/blob/1df7ad590d78d4fa9a017eb53f9f265e291bdf… <https://github.com/complyue/dcp/blob/1df7ad590d78d4fa9a017eb53f9f265e291bdf…> optionalSemicolon :: Parser Bool optionalSemicolon = fromMaybe False <$> optional (True <$ symbol ";") I can't reason about why it can fail like this. Best regards, Compl

2 10

CFP: TCAD Special Issue on Compiler Frameworks and Co-design Methodologies for Heterogeneous Systems-on-Chip
by Tobias Grosser 21 Oct '20

21 Oct '20

We are pleased to inform you about a Special Issue titled "Compiler Frameworks and Co-design Methodologies for Heterogeneous Systems-on-Chip" that will appear in the IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems (TCAD). We encourage you and your collaborators to submit new significant research-based technical contributions within the scope of this journal. SCOPE AND TOPICS ---------------------------------------------------------------------------- Nowadays, heterogeneous architectures are employed to limit the cost per function and boost energy efficiency in several computing domains, from high-performance computing (HPC) to embedded systems. Advanced heterogeneous systems-on-chip combine diverse processing elements, such as general-purpose processors (GPP), graphics processor units (GPU), digital signal processors (DSP), field-programmable gate arrays (FPGA), and many application-specific hardware accelerators. To fully exploit the power of these platforms and overcome the limits of conventional architectures, system and application designers need new tools and methodologies to address the increasing hardware/software complexity and achieve high productivity. This special issue aims to provide the targeted readers with the new advances and challenges in the area of compiler frameworks, hardware/software methodologies, and related tools to aid the design of complex heterogeneous systems. Relevant topics include, but are not limited to, the following: * Compiler frameworks and co-design workflows for heterogeneous hardware * End-to-end frameworks targeting heterogeneous specialized units * Application-specific co-design methodologies for heterogeneous platforms * Synergistic HW/SW techniques to promote parallelism in heterogeneous computing * Novel programming paradigms to promote heterogeneous design * Source-to-source translation and (semi-)automatic code generation for heterogeneous architectures * Methodologies to improve software portability across heterogeneous targets MANUSCRIPT PREPARATION AND SUBMISSION --------------------------------------------------------------------------- Submissions to this Special Issue must represent original material that has been neither submitted to, nor published in, any other journal. All submitted manuscripts must follow the TCAD guidelines: https://ieee-ceda.org/publication/tcad-publication/tcad-paper-submission Please submit your manuscript in electronic form through Manuscript Central website: https://mc.manuscriptcentral.com/tcad On the first page of the submission form, select this special issue in the "Type" field choosing this option: "SI on Compiler Frameworks and Co-design Methodologies" GUEST EDITORS --------------------------------------------------------------------------- * Luca Benini, Full Professor, Università di Bologna / ETH Zürich (lbenini(a)iis.ee.ethz.ch<mailto:lbenini@iis.ee.ethz.ch>) * Luca Carloni, Full Professor, Columbia University (luca(a)cs.columbia.edu<mailto:luca@cs.columbia.edu>) * Giuseppe Tagliavini, Assistant Professor, University of Bologna (giuseppe.tagliavini(a)unibo.it<mailto:giuseppe.tagliavini@unibo.it>) * Tobias Grosser, Associate Professor, University of Edinburgh (tobias.grosser(a)ed.ac.uk<mailto:tobias.grosser@ed.ac.uk>) TIMELINE --------------------------------------------------------------------------- * Submission Deadline: November 15, 2020 * Reviews Completed: January 15, 2021 * Major Revisions Due: February 15, 2021 * Reviews of Revisions Completed: March 15, 2021 * Notification of Final Acceptance: March 31, 2021 * Publication Materials for Final Manuscripts Due: April 10, 2021 * Publication: May 2021 -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

Release a book about math and programming in Haskell
by Xinyu LIU 21 Oct '20

21 Oct '20

Hi, I recently released a book about mathematics and programming in github: https://github.com/liuxinyu95/unplugged I mainly provide examples, and code snippets in Haskell. The PDF can be downloaded under GNU FDL license. There are 7 chapters together with 108 problems as exercise. I also included all the answers in the appendix. Here are the table of content: Preface - A story about isomorphism. Chapter 1, Natural numbers. Peano Axiom, list and folding; Chapter 2, Recursion. Euclidean algorithm, Lambda calculus, and Y-combinator; Chapter 3, Symmetry. Group, Ring, and Field. Galois Theory; Chapter 4, Category theory and type system; Chapter 5, Deforest. Build-fold fusion law, optimization, and algorithm deduction; Chapter 6, Infinity. Set theory, Infinity and stream; Chapter 7, Logic paradox, Gödel's incompleteness theorems, and Turing halting problem. Answers to the exercise. Xinyu LIU https://github.com/liuxinyu95/unplugged *e*^(*π*i)+1 = 0

2 1

Clarification on uniWhite lexical definition
by Immanuel Litzroth 20 Oct '20

20 Oct '20

The haskell report says: uniWhite → any Unicode character defined as whitespace it's not clear to me whether this means that the unicode character should have "Zs" as it's general category ;; Zs Space_Separator a space character (of various non-zero widths) or whether it should be defined as whitespace as in https://www.unicode.org/Public/UCD/latest/ucd/PropList.txt Any clarification appreciated, Immanuel -- -- Researching the dual problem of finding the function that has a given point as fixpoint.

3 2

F-IDE 2021 - Call for Papers
by Andrei Paskevich 19 Oct '20

19 Oct '20

****************************************************************** F-IDE 2021: 6th Workshop on Formal Integrated Development Environment Affiliated with NASA Formal Methods 2021 May 24-28, 2021 -- held online https://cister-labs.pt/f-ide2021 ****************************************************************** Important Dates * Abstract submission: Mon, Feb 22, 2021 * Full paper submission: Mon, Mar 1, 2021 * Notification: Mon, Apr 19, 2021 * Camera-ready: Mon, May 3, 2021 * Workshop: May 24-28, 2021 Overview High levels of safety, security, and privacy standards require the use of formal methods to specify and develop compliant software (sub)systems. Any standard comes with an assessment process, which requires a complete documentation of the application to ease the justification of design choices and the review of code and proofs. Ideally, an F-IDE dedicated to such developments should comply with several requirements. The first one is to associate a logical theory with a programming language, in a way that facilitates the tightly coupled handling of specification properties and program constructs. The second is to offer a language and/or an environment simple enough to be usable by most developers, even if they are not fully acquainted with higher-order logics or set theory, in particular by making development of proofs as easy as possible. The third is to offer automated management of application documentation. It may also be expected that developments done with such an F-IDE are reusable and modular. Tools for testing and static analysis may be embedded within F-IDEs to support the assessment process. Topics The workshop is open to contributions on all aspects of a system development process, including specification, design, implementation, analysis, and documentation. It welcomes the presentation of tools, methods, techniques, and experiments. Topics of interest include, but are not limited to, the following: * F-IDE building: design and integration of languages, development of user-friendly front-ends * How to make high-level logical and programming concepts palatable to industrial developers * Integration of object-oriented and modularity features * Integration of static analyzers * Integration of automated proof tools, theorem provers, and testing tools * Documentation tools * Impact of tools on certification * Experience reports on developing F-IDEs * Experience reports on using F-IDEs * Experience reports on formal methods-based assessments in industrial applications Submission Guidelines We accept both long (15 pages) and short (6 pages) paper submissions. The page limit does not include the bibliography. Submitted papers must present original contributions whose main results and conclusions have not been published or submitted elsewhere. Each submission will be reviewed by at least three members of the Program Committee. We expect that one author of every accepted paper will present their work at the workshop. Submitted papers must be written in English and follow the EPTCS LaTeX format (http://style.eptcs.org) Authors are invited to submit the following types of contributions: * Research papers providing new concepts and results * Experience reports * Position papers and research perspectives * Tool presentations Papers should be submitted via EasyChair at F-IDE 2021's workshop page: https://easychair.org/conferences/?conf=f-ide2021. Preliminary proceedings will be made available in electronic form at the workshop. Post-proceedings will be published in the Electronic Proceedings in Theoretical Computer Science (EPTCS). Program Committee * Andrew Reynolds, University of Iowa, USA * Bernhard Rumpe, RWTH Aachen University, Germany * Carlo A. Furia, Chalmers University of Technology, Sweden * César Muñoz, NASA Langley, USA * Cinzia Bernardeschi, University of Pisa, Italy * Claudio Sacerdoti Coen, University of Bologna, Italy * Enrico Tassi, Inria, France * François Pessaux, ENSTA ParisTech, France * José Creissac Campos, University of Minho, Portugal * Kenneth Lausdahl, Aarhus University, Denmark * Laurent Voisin, Systerel, France * Lucas Wagner, Collins Aerospace, USA * Makarius Wenzel, sketis.net * Markus A. Kuppe, Microsoft Research, USA * Mattias Ulbrich, Karlsruhe Institute of Technology, Germany * Pierre-Yves Strub, LIX, École Polytechnique, France * Rosemary Monahan, Maynooth University, Ireland * Silvia Lizeth Tapia Tarifa, University of Oslo, Norway * Simão Melo de Sousa, Universidade Beira Interior, Portugal * Stefan Mitsch, Carnegie Mellon University, USA * Stephan Merz, Inria, France * Virgile Prevosto, Institut List, CEA Tech, Université Paris-Saclay, France * Yannick Moy, AdaCore, France * Yi Zhang, Massachusetts General Hospital, USA PC Chairs * Andrei Paskevich, Université Paris-Saclay, France * José Proença, CISTER/ISEP, Portugal Steering Committee * Catherine Dubois, Samovar, ENSIIE, France * Paolo Masci, US National Institute of Aerospace (NIA), USA * Dominique Méry, LORIA, Université de Lorraine, France

1 0

Need help to get started
by tech＠jimtyrerrobotics.ca 18 Oct '20

18 Oct '20

hello, I'm an industrial robot tech and the code I write seems to be composed of 99% side-effects ;-) That's the big dumb ones bolted to the floor that make cars and stuff. Decades of imperative sequence coding seem to have fossilized something in my brain. Trying to teach myself Haskell and going nowhere very slowly. Spent the last 8 weeks slowly plodding through "Real World Haskell" and "Learn you a Haskell" with the intention of re-writing a bash script in Haskell. I've normally learned programming by writing something I need instead of tutorials with which I seem to have an attention deficit problem. I use Linux for work and have written a bash script that uses bc and heredocs to write an .adoc file and then calls asciidoctor-pdf to generate an invoice. It's about 90 lines so I am not a scripting pro either. So typing './invoice Wk38' rolls a file called Wk38-of-2020-Invoice.pdf to send to clients. It was while writing this script that I stumbled upon pandoc and then Haskell. And that's where the trouble started. Tha abstraction and macro-approach of Haskell could provide a whole bag of tools for maintaining code (text files) on lines of multiple robots. About the existing script: I write plain text files on my phone that look like this: 14 Sep 0745 1600 Foo y 15 Sep 0815 1500 Foo y 16 Sep 0745 1400 Foo y 17 Sep 0745 1430 Foo y 18 Sep 0745 1400 Foo y and this one is called Wk38 and the fields are: |Date|Time In|Time Out|Proj|Lunch. Then I email it to myself and run the script. So I would be very grateful if someone could write some code for me and put my bootstraps in my fumbling hands: Get the name of the Wkxx file from the command line when running a Haskell standalone executable. fileName <- getArgs Load the lines of the file into a list of list of String[[]]. (or a better way?) lines <- fmap Text.lines (Text.readFile fileName) Recurse through each line of the list(s) and: *: Construct a date::String from the first two fields. (just a string, does not need a real "Date") *: Calc dailyElapsedTime::Double from difference between fields 4 and 3. *: Subtract 0.5hr lunch from dailyElapsedTime if field 6 == "y" *: Add dailyElapsedTime to accumlatedWeekTime::Double. *: Charge = If accumlatedWeekTime < 40hrs then multiply by rate1 *: elseif accumlatedWeekTime > 40hrs then multiply by rate2 *: Append |Date|Time In|Time Out|Charge|Project| to adoc file. If I could load it into ghci and step through it the lights may come on. Thanks very much Noodles

4 3

Re: [Haskell-cafe] ANN: stack-2.5.1
by waldmann 17 Oct '20

17 Oct '20

> Doesn't compile for me GHC 8.10.2 when building using cabal [...] for stack-2.5.0.1, this worked: cabal install --constraint 'base16-bytestring==0.1.1.7' --constraint 'optparse-applicative==0.15.1.0' https://github.com/commercialhaskell/stack/issues/5298#issuecomment-7023387… NB : seems to me there's a whole recent-social-history-of-haskell essay waiting to be written around that question (build 'stack' with 'cabal'). - J.W.

1 0

ANN: stack-2.5.1
by Emanuel Borsboom 15 Oct '20

15 Oct '20

See https://haskellstack.org/ for installation and upgrade instructions. **Changes since v2.3.3** Major changes: * Add the `snapshot-location-base` yaml configuration option, which allows to override the default location of snapshot configuration files. This option affects how snapshot synonyms (LTS/Nightly) are expanded to URLs by the `pantry` library. * `docker-network` configuration key added to override docker `--net` arg Behavior changes: * File watching now takes into account specified targets, old behavior could be restored using the new flag `--watch-all` [#5310](https://github.com/commercialhaskell/stack/issues/5310) Other enhancements: * `stack ls dependencies json` now includes fields `sha256` and `size` for dependencies of `type` `archive` in `location`. [#5280](https://github.com/commercialhaskell/stack/issues/5280) * Build failures now show a hint to scroll up to the corresponding section [#5279](https://github.com/commercialhaskell/stack/issues/5279) * Customisable output styles (see `stack --help` and the `--stack-colors` option, and `stack ls stack-colors --help`) now include `info`, `debug`, `other-level`, `secondary` and `highlight`, used with verbose output. Bug fixes: * Fix `stack test --coverage` when using Cabal 3 * `stack new` now generates PascalCase'd module name correctly. [#5376](https://github.com/commercialhaskell/stack/issues/5376) * Connection issues to Casa server no longer cause builds to failure. Casa acts only as an optimizing cache layer, not a critical piece of infrastructure. * Fix modified time busting caches by always calculating sha256 digest during the build process. [#5125](https://github.com/commercialhaskell/stack/issues/5125) **Thanks to all our contributors for this release:** * Andrea Condoluci * Andreas Herrmann * Andres Schmois * Ariel D. Moya Sequeira * Brandon Chinn * Cheah Jer Fei * DerpyCrabs * Emanuel Borsboom * Felix Yan * Jannik Theiß * Jens Petersen * Junji Hashimoto * Kirill Zaborsky * Michael Snoyman * Mihai Maruseac * Mike Pilgrem * Niklas Hambüchen * Ondřej Slámečka * Piper McCorkle * Thomas Lopatic * tomjaguarpaw

2 1

Re: [Haskell-cafe] Overlapping instances: are functions and typeclass methods treated differently?
by Daniel Díaz 13 Oct '20

13 Oct '20

On Thu, Oct 8, 2020 at 2:12 PM Henning Thielemann < lemming(a)henning-thielemann.de> wrote: > > On Thu, 8 Oct 2020, Daniel Díaz wrote: > > > But now consider this instance: > > > > > newtype Wrapper a = Wrapper (Maybe a) > > > instance Show a => Show (Wrapper a) where > > > show (Wrapper x) = show x > > > > This compiles just fine, despite—to my mind—suffering from the exact > same problem that the "foo" function had. > > Why does it work? > > There is an instance Show (Maybe a) in Prelude, but no instance Show > (Wrapper a), so no overlapping. Sorry, I wasn't very clear there. The problem is not with the "Show (Wrapper a)" instance itself, but with its implementation of "show". It depends (just as the function "foo" did) on "Show (Maybe a)", for which there are overlapping instances. And yet "foo" compiles without problem, while the typeclass method doesn't.

3 2

showing execution steps
by Luc Duponcheel 05 Oct '20

05 Oct '20

Hi, Is there a way to let ghci (or executable code generated by ghc) show all intermediate rewrite results when an expression is evaluated to its final result? Luc -- __~O -\ <, (*)/ (*) reality goes far beyond imagination

3 2

ghc-9 needs type declaration where ghc-8 didn't (with RankNTypes)
by Johannes Waldmann 02 Oct '20

02 Oct '20

Dear Cafe, and thanks, Georgi, for answering my previous question here's another difference I noticed (based on real code, but reduced to a minimal test case) GHCi, version 9.0.0.20200925: https://www.haskell.org/ghc/ :? for help Prelude> :set -XRankNTypes Prelude> let f :: (forall a . a -> ()) -> () ; f = g ; g x = undefined <interactive>:2:43: error: • Couldn't match type ‘p0’ with ‘forall a. a -> ()’ Expected: (forall a. a -> ()) -> () Actual: p0 -> () Cannot instantiate unification variable ‘p0’ with a type involving polytypes: forall a. a -> () • In the expression: g In an equation for ‘f’: f = g The declaration is accepted by ghc-8. For ghc-9, I have to give a type signature for g (copy that of f), or replace `f = g` with `f x = g x`. - J.W.

4 4

Novel error triggered building aeson on Mac
by Vanessa McHale 01 Oct '20

01 Oct '20

Hi all, I recently ran into the following interesting bug (reproducible on Mac; I used ghcup to install GHC and cabal-install): cabal unpack aeson-1.2.1.0 cabal build -w ghc-8.0.2 (yields this error log) Configuring library for aeson-1.2.1.0.. Preprocessing library for aeson-1.2.1.0.. Building library for aeson-1.2.1.0.. [ 1 of 23] Compiling Data.Attoparsec.Time.Internal ( attoparsec-iso8601/Data/Attoparsec/Time/Internal.hs, dist/build/Data/Attoparsec/Time/Internal.o ) [ 2 of 23] Compiling Data.Attoparsec.Time ( attoparsec-iso8601/Data/Attoparsec/Time.hs, dist/build/Data/Attoparsec/Time.o ) [ 3 of 23] Compiling Data.Aeson.Types.Internal ( Data/Aeson/Types/Internal.hs, dist/build/Data/Aeson/Types/Internal.o ) [ 4 of 23] Compiling Data.Aeson.Types.Generic ( Data/Aeson/Types/Generic.hs, dist/build/Data/Aeson/Types/Generic.o ) [ 5 of 23] Compiling Data.Aeson.Parser.UnescapePure ( pure/Data/Aeson/Parser/UnescapePure.hs, dist/build/Data/Aeson/Parser/UnescapePure.o ) [ 6 of 23] Compiling Data.Aeson.Parser.Unescape ( Data/Aeson/Parser/Unescape.hs, dist/build/Data/Aeson/Parser/Unescape.o ) [ 7 of 23] Compiling Data.Aeson.Parser.Time ( Data/Aeson/Parser/Time.hs, dist/build/Data/Aeson/Parser/Time.o ) [ 8 of 23] Compiling Data.Aeson.Parser.Internal ( Data/Aeson/Parser/Internal.hs, dist/build/Data/Aeson/Parser/Internal.o ) <command line>: can't load .so/.DLL for: /Users/vmchale/.cabal/store/ghc-8.0.2/lib/libHStm-lcl-cmpt-0.1.1.5-83154f89-ghc8.0.2.dylib (dlopen(/Users/vmchale/.cabal/store/ghc-8.0.2/lib/libHStm-lcl-cmpt-0.1.1.5-83154f89-ghc8.0.2.dylib, 5): REBASE_OPCODE_SET_SEGMENT_AND_OFFSET_ULEB has segment 2 which is not a writable segment (__LINKEDIT) in /Users/vmchale/.cabal/store/ghc-8.0.2/lib/libHStm-lcl-cmpt-0.1.1.5-83154f89-ghc8.0.2.dylib) Seems to be new; I guess the past libraries didn’t trigger it? I can’t tell if it’s a cabal-install bug, GHC bug, mac novelty… Cheers, Vanessa McHale

1 0