- Haskell-Cafe - Haskell.org

ghc-9 strictness annotations change?
by Johannes Waldmann 01 Oct '20

01 Oct '20

Dear Cafe, did something change w.r.t. placement of the bang? GHCi, version 9.0.0.20200925: https://www.haskell.org/ghc/ :? for help Prelude> data T = T { foo :: ! Int } <interactive>:1:21: error: Operator applied to too few arguments: ! Prelude> data T = T { foo :: !Int } Prelude> - J.W.

2 1

Re: [Haskell-cafe] I think I discovered my first Monoid instance
by David Banas 30 Sep '20

30 Sep '20

> > But we're talking about xor for the Word64 type, so it is slightly more > complicated to prove that it has a unit. Here's a proof in Agda: -- Agda proof that zero is the unit (i.e. - left and right identity) -- for the XOR operation. import Relation.Binary.PropositionalEquality as Eq open Eq using (_≡_; refl; cong; sym) open import Data.Nat using (ℕ; zero; suc; _+_; _*_; _∸_; _^_) -- Binary data. data Bin : Set where ⟨⟩ : Bin _O : Bin → Bin _I : Bin → Bin _xor_ : Bin → Bin → Bin ⟨⟩ xor y = y (x O) xor ⟨⟩ = x O (x O) xor (y O) = (x xor y) O (x O) xor (y I) = (x xor y) I (x I) xor ⟨⟩ = x I (x I) xor (y O) = (x xor y) I (x I) xor (y I) = (x xor y) O lemma : ∀ (b : Bin) ------------ → b xor ⟨⟩ ≡ b lemma ⟨⟩ = refl lemma (b O) = refl lemma (b I) = refl _ : ( ⟨⟩ I O O I O I I O ) xor ( ⟨⟩ O I I I O O O O ) ---------------------- ≡ ( ⟨⟩ I I I O O I I O ) _ = refl -- Left & right identity proofs. postulate binO : (⟨⟩ O) ≡ ⟨⟩ -- Just accomodating a syntactical nuisance. xor-idₗ : ∀ (b : Bin) ---------------- → (⟨⟩ O) xor b ≡ b xor-idₗ ⟨⟩ rewrite binO = refl xor-idₗ (b O) = refl xor-idₗ (b I) = refl xor-idᵣ : ∀ (b : Bin) ---------------- → b xor (⟨⟩ O) ≡ b xor-idᵣ ⟨⟩ rewrite binO = refl xor-idᵣ (b O) rewrite lemma b = refl xor-idᵣ (b I) rewrite lemma b = refl -db

1 0

Re: [Haskell-cafe] [Haskell] [ANNOUNCE] Glasgow Haskell Compiler 9.0.1-alpha1 released
by Dan Burton 30 Sep '20

30 Sep '20

That's great news! Thank you for your hard work. Does this address the Windows issue with GHC 8.10.2? Will there still be a GHC 8.10.3 release? See: https://gitlab.haskell.org/ghc/ghc/-/issues/18550 (Pardon the dupe; I had the wrong address on haskell-cafe) -- Dan Burton On Tue, Sep 29, 2020 at 5:23 PM Dan Burton <danburton.email(a)gmail.com> wrote: > That's great news! Thank you for your hard work. > > Does this address the Windows issue with GHC 8.10.2? Will there still be a > GHC 8.10.3 release? > See: https://gitlab.haskell.org/ghc/ghc/-/issues/18550 > > -- Dan Burton > > > On Mon, Sep 28, 2020 at 3:16 PM Ben Gamari <ben(a)well-typed.com> wrote: > >> Hello all, >> >> The GHC team is very pleased to announce the availability of the first >> alpha release in the GHC 9.0 series. Source and binary distributions are >> available at the usual place: >> >> https://downloads.haskell.org/ghc/9.0.1-alpha1/ >> >> This first alpha comes quite a bit later than expected. However, we have >> done a significant amount of testing on this pre-release and therefore >> hope to be able to move forward quickly with a release candidate next >> week and with a final release in mid-October. >> >> GHC 9.0.1 will bring a number of new features: >> >> * A first cut of the new LinearTypes language extension [1], allowing >> use of linear function syntax and linear record fields. >> >> * A new bignum library (ghc-bignum), allowing GHC to be more easily >> used with integer libraries other than GMP. >> >> * Improvements in code generation, resulting in considerable >> performance improvements in some programs. >> >> * Improvements in pattern-match checking, allowing more precise >> detection of redundant cases and reduced compilation time. >> >> * Implementation of the "simplified subsumption" proposal [2] >> simplifying the type system and paving the way for QuickLook >> impredicativity in GHC 9.2. >> >> * Implementation of the QualifiedDo extension [3], allowing more >> convenient overloading of `do` syntax. >> >> * Improvements in compilation time. >> >> And many more. See the release notes [4] for a full accounting of the >> changes in this release. >> >> Do note that there are a few things that we expect will change before >> the final release: >> >> * We expect to sort out a notarization workflow for Apple Darwin, >> allowing our binary distributions to be used on macOS Catalina >> without hassle. >> >> Until this has been sorted out Catalina users can exempt the >> current macOS binary distribution from the notarization requirement >> themselves by running `xattr -cr .` on the unpacked tree before >> running `make install`. >> >> * We will likely transition the Alpine binary distribution to be fully >> statically-linked, providing a convenient, distribution-independent >> packaging option for Linux users. >> >> * We will be merging a robust solution for #17760 which will introduce >> a new primitive, `keepAlive#`, to the `base` library, subsuming >> most uses of `touch#`. >> >> As always, do test this release and open tickets for whatever issues you >> encounter. To help with this, we will be publishing a blog post >> describing use of our new `head.hackage` infrastructure to ease testing >> of larger projects with Hackage dependencies later this week. >> >> Cheers, >> >> - Ben >> >> >> [1] >> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0111-l… >> [2] >> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0287-s… >> [3] >> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0216-q… >> [4] >> https://downloads.haskell.org/ghc/9.0.1-alpha1/docs/html/users_guide/9.0.1-… >> _______________________________________________ >> Haskell mailing list >> Haskell(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell >> >

1 0

Re: [Haskell-cafe] Proposed "Restructuring" of State Monad page in Haskell Wikibooks
by Olaf Klinke 30 Sep '20

30 Sep '20

> Hello – I’m proposing to restructure this< > https://en.wikibooks.org/wiki/Haskell/Understanding_monads/State>;, > and I have a draft here< > https://en.wikibooks.org/wiki/Davjam2:Example/StateMonad>;. I’ve > given my main reasons for the restructuring at the top of the draft > page. > > I’d very much like feedback before updating the real page, especially > if people don’t like the new one much. +1 for the new version by David. In addition to the content already present, I'd like to see examples (and exercises! these are great!) of State used with other common monadic combinators. You covered sequence, but what about mapM a.k.a. traverse, what about foldM? Can filterM be put to good use with state monads? You could introduce another type TurnstileInput = Push | Coin and combine pushS, coinS into a single function of type TurnstileInput -> State TurnstileState TurnstileOutput which can be used in mapM. Your exercises of different people can then be implemented as mapM of a single function (namely the FSM) over finite sequences of TurnstileInputs. As a side-note, Data.Traversable.mapAccumR is implemented using a StateR that passes the state backwards. Only an Applicative instance is given in Data.Functor.Utils. I wonder whether this is a lawful monad or not. The comment says so, but I don't see how. Here is a departure from the otherwise very concrete and down-to-earth explanation of State, but a fun exercise nevertheless: Implement return and (>>=) for type State s a = s -> (s,a) using the following two functions and the Functor instance of ((->) s). iso :: ((s,a) -> b) -> a -> s -> b iso uncurried = curry (uncurried . Data.Tuple.swap) iso' :: (a -> s -> b) -> (s,a) -> b -- inverse of iso iso' curried = uncurry (flip curried) Olaf

1 0

ANN: first release candidate for stack-2.5.x
by Emanuel Borsboom 29 Sep '20

29 Sep '20

Download binaries from here: https://github.com/commercialhaskell/stack/releases/tag/v2.5.0.1 **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 overwrite 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)

1 0

Re: [Haskell-cafe] Proposed "Restructuring" of State Monad page in Haskell Wikibooks
by Tom Smeding 29 Sep '20

29 Sep '20

Hi all, Branimir wrote: > Two years is not enough to do anything serious in Haskell. That is beyond demo programs. This statement carries a lot of assumptions, some of which may be true in this case, some of which may not -- I don't know David James -- but I think it isn't good to let this statement stand on its own like that. If a student who has never programmed before starts learning Haskell, they will not be able to succeed professionally after just two years unless they have other useful background knowledge and/or talent (let's not discuss whether talent is a thing or not). However, the email by David James did not sound like he is a beginner in the act of programming; indeed, with experience in imperative (C++, VB), declarative (SQL), functional (Lisp) and logic (Prolog) programming languages, that certainly does not count as "has never programmed before". And I think we can agree that someone with sufficient experience in programming at large can learn to use Haskell effectively in two years (which is quite a long time, even if it's irregular practice). At least, I strongly believe this until proven otherwise. If that is indeed not the case, then something is seriously wrong on Haskell's side, as Gregory has noted below. David: I haven't read your rewritten State monad tutorial, for which my apologies; also apologies for kind of derailing this thread. Cheers, and have a great day, Tom Smeding P.S. This message wasn't accepted by the mailing list earlier, so was just sent to some people personally. Sorry for duplicate emails. On Tue, 29 Sep 2020 at 15:14, Gregory Guthrie <guthrie(a)miu.edu> wrote: > If this is true, Haskell will probably never move up into even the top 40 > of used languages, which would be too bad! And it would be interesting to > see why – certainly people find good productivity in the mainstream IP > languages in even 6-9 months. > > (Look at salaries from bootcamp placements.) > > > > Currently Haskell is significantly below Cobol, Fortran, Lisp, and Pascal > in the language usage/ratings. :-( > > > > > > Dr. Gregory Guthrie > > Maharishi International University > > ---------------------------------------------------------------- > > > > *From:* Haskell-Cafe <haskell-cafe-bounces(a)haskell.org> *On Behalf Of *Branimir > Maksimovic > *Sent:* Tuesday, September 29, 2020 7:17 AM > *To:* haskell-cafe(a)haskell.org > *Subject:* Re: [Haskell-cafe] Proposed "Restructuring" of State Monad > page in Haskell Wikibooks > > > > Two years is not enough to do anything seroius in Haskell. That is beyond > demo programs. > > > > Greets, Branimir. > > > > On 9/28/20 6:37 PM, David James wrote: > > Hello – I’m proposing to restructure this > <https://en.wikibooks.org/wiki/Haskell/Understanding_monads/State>, and I > have a draft here > <https://en.wikibooks.org/wiki/Davjam2:Example/StateMonad>. I’ve given my > main reasons for the restructuring at the top of the draft page. > > > > I’d very much like feedback before updating the real page, especially if > people don’t like the new one much. > > > > I’m new here, so should probably say a bit about myself. I’ve been > learning-by-doing Haskell for about two years. Sometimes I feel I’m > starting to get it, but these feelings don’t usually last long. I’m > certainly not an expert, and don’t have a PhD in Very Clever Things. I do > have quite an extensive IT background, originally programming in Lisp and > Prolog, then (sadly) C++, VB and SQL but have had quite a long break from > programming (doing dumb things like architecting systems and project > managing) before looking at Haskell. I built this website > <https://decimos.net/> and this library > <https://hackage.haskell.org/package/MapWith>, just for my own amusement. > > > > Apologies if this isn’t the right place to send this. (But then where is?) > I’ve already put a note on the page itself about the new draft, but I’ve no > idea whether anyone will notice it. > > > > Thanks very much, > > David. > > > > > > > > > > > > > > > > > > _______________________________________________ > > 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 > 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.

2 1

[TFPIE'21] First Call For Papers: Trends in Functional Programming *in Education* 2021, 16 February (with Lambda Days 2021 & TFP 2021)
by Peter Achten 29 Sep '20

29 Sep '20

-------------------------------- TFPIE 2021 Call for papers -------------------------------- https://wiki.tfpie.science.ru.nl/TFPIE2021#TFPIE_2021 (February 16 2021, co-organized with TFP 2021 and Lambda Days 2021) The goal of the International Workshops on Trends in Functional Programming in Education is to gather researchers, professors, teachers, and all professionals that use or are interested in the use of functional programming in education. TFPIE aims to be a venue where novel ideas, classroom-tested ideas, and work in progress on the use of functional programming in education are discussed. The one-day workshop will foster a spirit of open discussion by having a review process for publication after the workshop. TFPIE 2021 welcomes submissions in the above mentioned areas. This year many teaching programmes have had to make a rapid transition to online teaching, and we explicitly solicit papers that explore this area of teaching functional programming. Topics of interest include, but are not limited to: - FP and beginning CS students - FP and Computational Thinking - FP and Artificial Intelligence - FP in Robotics - FP and Music - Advanced FP for undergraduates - FP in graduate education - Engaging students in research using FP - FP in Programming Languages - FP in the high school curriculum - FP as a stepping stone to other CS topics - FP and Philosophy - The pedagogy of teaching FP - FP and e-learning: MOOCs, automated assessment etc. - Best Lectures - more details below In addition to papers, we are requesting best lecture presentations. What's your best lecture topic in an FP related course? Do you have a fun way to present FP concepts to novices or perhaps an especially interesting presentation of a difficult topic? In either case, please consider sharing it. Best lecture topics will be selected for presentation based on a short abstract describing the lecture and its interest to TFPIE attendees. The length of the presentation should be comparable to that of a paper. On top of the lecture itself, the presentation can also provide commentary on the lecture. Submissions Potential presenters are invited to submit an extended abstract (4-6 pages) or a draft paper (up to 20 pages) in EPTCS style. The authors of accepted presentations will have their preprints and their slides made available on the workshop's website. Papers and abstracts can be submitted via easychair at the following link: https://easychair.org/conferences/?conf=tfpie2021 After the workshop, presenters are invited to submit (a revised version of) their article for review. The PC will select the best articles. We plan to publish them in the Electronic Proceedings in Theoretical Computer Science (EPTCS). Articles rejected for presentation and extended abstracts will not be formally reviewed by the PC. Dates - Submission deadline: January 11 2021, Anywhere on Earth. - Notification: January 15 2021 - Workshop: February 16 2021 - Submission for formal review: April 20 2021, Anywhere on Earth. - Notification of full article: June 7 2021 - Camera ready: July 1st 2021 Program Committee (under construction) - Peter Achten, Radboud University, Netherlands (chair) - Edwin Brady, University of St Andrews, UK - Laura Castro, Universidade da Coruña, Spain - Stephen Chang, University of Massachusetts Boston, USA - Youyou Cong, Tokyo Institute of Technology, Japan - Matthew Flatt, University of Utah, USA - Alex Gerdes, University of Gothenburg, Sweden - Prabhakar Ragde, University of Waterloo, Canada - Melinda Tóth, Eötvös Loránd University, Hungary Registration TFPIE is part of Lambda Days. Please visit the Lambda Days 2021 pages when registration information becomes available. Registration is mandatory for at least one author of every paper that is presented at the workshop. Only papers that have been presented at TFPIE may be submitted to the post-reviewing process. Information on Lambda Days is available at https://www.lambdadays.org/lambdadays2021 Information on TFP is available at http://tfp2021.org

1 0

[TFP'21] first call for papers: Trends in Functional Programming 2021, 17-19 February (with Lambda Days 2021 & TFPIE 2021)
by Peter Achten 29 Sep '20

29 Sep '20

------------------------------------------------------------------------- First call for papers 22nd Symposium on Trends in Functional Programming tfp2021.org ------------------------------------------------------------------------- The symposium on Trends in Functional Programming (TFP) is an international forum for researchers with interests in all aspects of functional programming, taking a broad view of current and future trends in the area. It aspires to be a lively environment for presenting the latest research results, and other contributions. * TFP offers a supportive reviewing process designed to help less experienced authors succeed, with two rounds of review, both before and after the symposium itself. Authors have an opportunity to address reviewers' concerns before final decisions on publication in the proceedings. * TFP offers two "best paper" awards, the John McCarthy award for best paper, and the David Turner award for best student paper. * TFP is co-located with Lambda Days in beautiful Krakow. Lambda Days is a vibrant developer conference with hundreds of attendees and a lively programme of talks on functional programming in practice. Due to the covid pandemic, the event is online with a lot of attention to interaction and getting to socialize with the community. Important Dates --------------- Submission deadline for pre-symposium review: 20th November, 2020 Submission deadline for draft papers: 15th January, 2021 Symposium dates: 17-19th February, 2021 * We strongly encourage authors to submit their work for the first deadline. Authors whose papers are accepted for presentation, but not immediately for the proceedings in this first round, will have almost two months to address the reviewers' concerns. Papers submitted for the first deadline will also have priority for the presentation slots at the symposium. Visit tfp2021.org for more information.

1 0

Proposed "Restructuring" of State Monad page in Haskell Wikibooks
by David James 29 Sep '20

29 Sep '20

Hello – I’m proposing to restructure this<https://en.wikibooks.org/wiki/Haskell/Understanding_monads/State>, and I have a draft here<https://en.wikibooks.org/wiki/Davjam2:Example/StateMonad>. I’ve given my main reasons for the restructuring at the top of the draft page. I’d very much like feedback before updating the real page, especially if people don’t like the new one much. I’m new here, so should probably say a bit about myself. I’ve been learning-by-doing Haskell for about two years. Sometimes I feel I’m starting to get it, but these feelings don’t usually last long. I’m certainly not an expert, and don’t have a PhD in Very Clever Things. I do have quite an extensive IT background, originally programming in Lisp and Prolog, then (sadly) C++, VB and SQL but have had quite a long break from programming (doing dumb things like architecting systems and project managing) before looking at Haskell. I built this website<https://decimos.net/> and this library<https://hackage.haskell.org/package/MapWith>, just for my own amusement. Apologies if this isn’t the right place to send this. (But then where is?) I’ve already put a note on the page itself about the new draft, but I’ve no idea whether anyone will notice it. Thanks very much, David.

6 5

I think I discovered my first Monoid instance
by Mario Lang 29 Sep '20

29 Sep '20

Hi. A common theme of some Haskell talks seems to be to motivate people to go and hunt for instances of standard typeclasses. As the hobbyist Haskell programmer that I am, I kept on wondering if I would ever find some. It feels sort of unrealistic, or at least unlikely, that I should suddenly start to see meaningful structure in code just because I think I know some typeclasses. I think I finally discovered a Monoid instance that helps to express a concept in code pretty well. However, unsure about the soundness of my blundering about, I'd like to confirm (or disprove!) my findings before I fall in love with the approach too much. In my chess library (chessIO) I use bitboards to represent chess positions. data QuadBitboard = QBB { black :: {-# UNPACK #-} !Word64 , pbq :: {-# UNPACK #-} !Word64 , nbk :: {-# UNPACK #-} !Word64 , rqk :: {-# UNPACK #-} !Word64 } deriving (Eq) A quad bitboard is a space optimisation based on the observation that a square can only be occupied by one piece. occupied QBB{pbq, nbk, rqk} = pbq .|. nbk .|. rqk pnr QBB{pbq, nbk, rqk} = pbq `xor` nbk `xor` rqk white = liftA2 xor occupied black pawns = liftA2 (.&.) pnr pbq knights = liftA2 (.&.) pnr nbk bishops = liftA2 (.&.) pbq nbk rooks = liftA2 (.&.) pnr rqk queens = liftA2 (.&.) pbq rqk kings = liftA2 (.&.) nbk rqk We can create a bitboard with a single occupied square: square :: Int -> Word4 -> QuadBitboard square !sq !nb = QBB (f 0) (f 1) (f 2) (f 3) where !b = bit sq f !n = fromIntegral ((nb `unsafeShiftR` n) .&. 1) * b And, as an aside, we can even use pattern synonyms to give these nibbles meaningful names. pattern NoPiece = 0 pattern WhitePawn = 2 pattern WhiteKnight = 4 pattern WhiteBishop = 6 pattern WhiteRook = 8 pattern WhiteQueen = 10 pattern WhiteKing = 12 pattern BlackPawn = 3 pattern BlackKnight = 5 pattern BlackBishop = 7 pattern BlackRook = 9 pattern BlackQueen = 11 pattern BlackKing = 13 But what felt really like a cool discovery, is combination: instance Monoid QuadBitboard where mempty = QBB 0 0 0 0 -- | bitwise XOR instance Semigroup QuadBitboard where QBB b0 b1 b2 b3 <> QBB b0' b1' b2' b3' = QBB (b0 `xor` b0') (b1 `xor` b1') (b2 `xor` b2') (b3 `xor` b3') With this, we can pretty easily define a function to create a quad bitboard from a string: instance IsString QuadBitboard where fromString = go (7, 0) mempty where go _ !qbb "" = qbb go (!r,_) qbb ('/':xs) = go (r - 1, 0) qbb xs go (!r,!f) !qbb (x:xs) | inRange ('1','8') x = go (r, f + (ord x - ord '0')) qbb xs | otherwise = go (r, f + 1) (qbb <> square (r*8+f) nb) xs where nb = case x of 'P' -> WhitePawn 'N' -> WhiteKnight 'B' -> WhiteBishop 'R' -> WhiteRook 'Q' -> WhiteQueen 'K' -> WhiteKing 'p' -> BlackPawn 'n' -> BlackKnight 'b' -> BlackBishop 'r' -> BlackRook 'q' -> BlackQueen 'k' -> BlackKing _ -> error $ "QuadBitBoard.fromString: Illegal FEN character " <> show x standard :: QuadBitboard standard = "rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR" The rest of the module builds on the Monoid instance of QuadBitboard. Again, this is the first time a instance like this turns up in my Haskell experiments. It feels extremely satisfying having discovered this. But maybe I am violating some laws (I hear instances do that sometimes!) or some other thing is totally wrong. One might say I am not fully trusting the peace. https://hackage.haskell.org/package/chessIO/docs/Game-Chess-QuadBitboard.ht… -- CYa, ⡍⠁⠗⠊⠕

6 9

Status of Haskell on the browser?
by Bryan Richter 28 Sep '20

28 Sep '20

A perennial question, I'm sure. I've been trying out some browser-side programming lately, and I'm curious if anyone in the community has any vision for where things are going. GHCJS looks like it hasn't had any updates in a while. Is it approaching its twilight years, or do people still have plans for it? Asterius looks interesting, but I'm not too clear on where WASM sits in the web space. Would a suitably-advanced Asterius cover all of our Haskell-on-the-browser needs, or would there still be a need for a separate javascript backend? Basically, I'm curious to know what people are working on in this realm! -Bryan

1 0

Compiler Construction (CC) 2021 - Call for Papers
by Delphine Demange 28 Sep '20

28 Sep '20

ACM SIGPLAN 2021 International Conference on Compiler Construction (CC 2021) Co-located with CGO, HPCA and PPoPP Sat 27 February - 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. = IMPORTANT DATES = Abstract Submission: November 8, 2020 Full Paper Submission: November 10, 2020 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: February 27 - March 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

Virtual Munich Haskell Meeting, 2020-09-28 @ 19:30
by Leah Neukirchen 25 Sep '20

25 Sep '20

Dear all, Next week, our monthly Munich Haskell Meeting will take place again on Monday, September 28 at 19:30. **Due to meetup limitations in Bavaria, this meeting will take place online!** For details see here: https://muenchen.haskell.bayern/dates.html Everybody is welcome, especially the Haskellers from Bavaria that do not usually come to our Munich meetings due to travel distance! cu, -- Leah Neukirchen <leah(a)vuxu.org> https://leahneukirchen.org/

1 0

Open Kattis Problem Srednji: Hints to improve my algorithm
by Dominik Bollmann 25 Sep '20

25 Sep '20

Hi Haskell-Cafe, I've been trying to solve the Open Kattis Problem called Srednji recently, unfortunately without success. Given a sequence A and a number B within that sequence this problem asks to find all odd sub-sequences of A that, when sorted, have B as their median in the middle. That is, from A we may remove some prefix and/or suffix and if the resulting sub-sequence -- when sorted -- contains B in the middle, then this sub-sequence is a solution. The problem asks to find the number of all solutions. Check out https://open.kattis.com/problems/srednji for the details. My Haskell solution below tries to find the number of odd sub-sequences by first locating the median and then repeatedly moving left and right from that median to find larger and larger sub-sequence candidates. Each found candidate is checked to have B in the middle when sorted in order to become a solution. Moreover, I also extend each such candidate further to the left (and to the right, respectively) to determine whether these leftward or rightward extensions are solutions, too. I think with this approach I systematically enumerate all solutions. Unfortunately, though, this approach is too slow and times out on the 11th hidden test cases. I'd therefore be thankful for hints about different approaches to solving this problem more efficiently. Thanks! Dominik. ==================================================================== My current, slow Haskell code is this: import Data.Maybe import Data.Sequence (Seq, (<|), (|>)) import qualified Data.Sequence as Seq import qualified Data.Vector.Unboxed as Vec data SubSeq = SubSeq { getBalance :: {-# UNPACK #-} !Int , getSubSeq :: Seq Int , from :: {-# UNPACK #-} !Int , to :: {-# UNPACK #-} !Int } balancedSubSeqs :: [Int] -> Int -> [SubSeq] balancedSubSeqs seq med = do candidate <- leftRight [val0] let lefts = leftLeft candidate [] rights = rightRight candidate [] candidate ?: lefts ++ rights where medidx = fromJust (Vec.findIndex (== med) arr) val0 = SubSeq 0 (Seq.singleton med) medidx medidx arr = Vec.fromList seq leftRight cands@(SubSeq balance seq i j : _) | i-1 < 0 || j+1 >= Vec.length arr = cands | otherwise = let v1 = arr Vec.! (i-1) v2 = arr Vec.! (j+1) balance' = newBalance balance v1 v2 seq' = (v1 <| seq) |> v2 in leftRight (SubSeq balance' seq' (i-1) (j+1) : cands) leftLeft cand@(SubSeq balance seq i j) sols | i-2 < 0 = sols | otherwise = let v1 = arr Vec.! (i-2) v2 = arr Vec.! (i-1) balance' = newBalance balance v1 v2 seq' = v1 <| v2 <| seq newCand = SubSeq balance' seq' (i-2) j in leftLeft newCand (newCand ?: sols) rightRight cand@(SubSeq balance seq i j) sols | j+2 >= Vec.length arr = sols | otherwise = let v1 = arr Vec.! (j+1) v2 = arr Vec.! (j+2) balance' = newBalance balance v1 v2 seq' = seq |> v1 |> v2 newCand = SubSeq balance' seq' i (j+2) in rightRight newCand (newCand ?: sols) newBalance old n1 n2 | n1 < med, n2 < med = old - 2 | n1 > med, n2 > med = old + 2 | otherwise = old infixr 5 ?: --(?:) :: SubSeq -> [SubSeq] -> [SubSeq] x@(SubSeq b _ _ _) ?: xs | b == 0 = x : xs | otherwise = xs main :: IO () main = do [len, median] <- fmap read . words <$> getLine seq <- fmap read . words <$> getLine let solutions = balancedSubSeqs seq median print (length solutions)

3 5

Re: [Haskell-cafe] Are explicit exports and local imports desirable in a production application?
by Olaf Klinke 23 Sep '20

23 Sep '20

Dear Ignat, have you seen https://wiki.haskell.org/Import_modules_properly https://wiki.haskell.org/Qualified_names I find the arguments convincing. Even in my own packages I sometimes get lost where a certain function was imported from. When neither exports nor imports are done explicitly, you usually have only two choices: 1. search all sources (e.g. with grep -l) 2. rely on the haddock index Maybe your IDE can do that for you, but you can't expect all downstream users or all your colleagues to do the same. -- Olaf

8 10

Re: [Haskell-cafe] Readable Haskell
by Ignat Insarov 22 Sep '20

22 Sep '20

Hello Ian and Mario. > > We have retina screens, GPU accelerated rendering and magical > > auto-completion. > > Who's "we"? 1 and 2 are constrained by money. 1 and 3 are also > constrained by personal preference. > > I need a _big_ screen because I also do photo processing beside coding, > and I can't afford 2 screens, one big and another high density. > > Command shell is a very old and peculiar human interface — if human at > > all. They had 80 character wide screens and visibly lagging connexion. > > We have retina screens, GPU accelerated rendering and magical > > auto-completion. > > You might have that. I, as a blind braille display user, > have one line of at most 80 characters. When I am traveling, I > typically only have 40 characters. Given these constraints, I still > consider a command line interface superior to any sort of buttonized > nonesense. But thats just me, apparently. This is not how I expected my message to be understood. I did not mean to imply that every Haskell programmer has or should have a retina screen and a high performance GPU — only that, as a profession, we have way better tools now than back then. In humanities, it is usual for there to be either a normal distribution or a Pareto distribution in any large enough sample of data. So, unlike in precise sciences, a counter-example does not refute a proposition. What matters is that there is a trend. And there is a trend associated with larger and finer displays. It dawns on even the most _«old school»_ people by now. See for example a letter on Linux Kernel Mailing List.[1] > When I tile my terminal windows on my display, I can have 6 terminals > visible at one time, and that's because I have them three wide. And I > could still fit 80% of a fourth one side-by-side. > > And guess what? That's with my default "100x50" terminal window (go to > your gnome terminal settings, you'll find that the 80x25 thing is just > an initial default that you can change), not with some 80x25 one. And > that's with a font that has anti-aliasing and isn't some pixelated > mess. I have no specific insight about how to optimize readability for people that listen to code[2] or sense it with their hands. What I am sure of is that there are better ways to go about it than dwelling in the past. [1]: https://lkml.org/lkml/2020/5/29/1038 [2]: https://www.vincit.fi/fi/software-development-450-words-per-minute/

4 4

Readable Haskell
by Misja Alma 21 Sep '20

21 Sep '20

Hi, I have been writing Haskell in my spare time for a couple of years now, but when I showed some code lately to a friend he remarked that he didn't find it very readable. Actually I agree, when I look at my own code of a couple of months old I have trouble figuring out too what exactly it is doing. I'm coming from a Java and Scala background and there, especially for Java, are some generally accepted best practices that make sure that your teammates don't have too much trouble reading your code. E.g. write short functions with a single responsibility, use variable, class and function names that explain what they are meant for, etc. I think some of those best practices, like short functions with single responsibility, are useful for Haskell as well. But Haskell is a different language than Java and has its own strong points and pitfalls regarding readability, so it probably needs different coding standards as well. I have been looking on the Internet if I could find some tips about improving readability but all I could find was http://www.haskellforall.com/. Although there are some useful tips in there, this site seems to be aimed at making Haskell easier to read for newcomers from other languages. What I am interested in are tips from real projects that are built by real teams. Does anybody have any tips, or are there some sites or books that I could read about this topic? Thanks, Misja

15 20

Re: [Haskell-cafe] Readable Haskell
by Taeer Bar-Yam 21 Sep '20

21 Sep '20

Can we agree that it's possible to go too far? Even in the global scope. https://github.com/Quotation/LongestCocoa. I think another factor that comes into play is how frequently you use the function/value. If it comes up only once in a while, then every time someone encounters it they are likely to have to remind themselves what all the abreviations mean. If it comes up more frequently, then they likely already saw it 10 lines ago, and remember. If it comes up very frequently, then whatever name you assign it takes on its own meaning. Think about `map` or, in bash land `ls` and `cd`. Unless you just started using bash, you're not going to think "Oh. cd stands for 'change directory'". It's just… cd. And at the same time, using a long name for something that's going to come up every couple of lines is, IMO, distracting. Having all of the information be within what your eye can easily take in at once has huge advantages. Not to mention, can you imagine writing `changeDirectory` and `printDirectoryContents` every time? It's a balancing act. Obviously, the opposite extreme carries its own problems. --Taeer

6 5

[ANN] Reanimate v1.0
by Lemmih 20 Sep '20

20 Sep '20

It is my great pleasure to announce version 1.0 of the Reanimate animation library. Reanimate aims to be a batteries-included way of creating animations and illustrations. To see it in action, visit: https://reanimate.github.io/ Reanimate wouldn't be here without help and I'd like to thank Jan Hrček for writing the Elm viewer, Shaurya Gupta for performance improvements, William Yaoh for writing documentation, Mike Pilgrem for ImageMagick v7 support, and Xie Ruifeng for LaTeX and text encoding fixes. Furthermore, I'd like to thank Eve, Joe, Rodrigo, Brad, Aron, and Ben for their help and support. Finally, I'd like to thank the GitHub sponsors who are financing server costs and making Reanimate the best it can be. Hackage: https://hackage.haskell.org/package/reanimate Haddock: https://hackage.haskell.org/package/reanimate/docs/Reanimate.html Tutorial: https://reanimate.readthedocs.io/en/latest/tut_equation/ GitHub: https://github.com/reanimate/reanimate/ Website: https://reanimate.github.io/ Discord: https://discord.gg/Qs28Dv6 Sponsors: https://github.com/sponsors/Lemmih Best wishes, David.

1 0

program description based programming
by Luc Duponcheel 18 Sep '20

18 Sep '20

Hellot Just started with the new version of the PDBP library. https://github.com/PDBP Work in progress. Expect frequent additions (and changes). Luc -- __~O -\ <, (*)/ (*) reality goes far beyond imagination

1 0

Are explicit exports and local imports desirable in a production application?
by Ignat Insarov 18 Sep '20

18 Sep '20

I apologize if this topic has already been clarified elsewhere — please refer me. The present message can also be seen _(and answered)_ on the Haskell Discourse board.[1] To clarify, an explicit export: module X (…) where … An explicit import: import X (…) ## I would like to question the desirability of explicit exports and local imports in a production application. I want to make two cases: * That explicit exports are never necessary. Moreover, that explicit exports are harmful as they make checking of non-exported definitions impossible. * That explicit imports are not necessary when importing a module from the same package. By default, I make an easy claim that none are desirable since they incur mindless typing effort and thereby unfairly tax the programmer. Let us then consider the justifications for their use despite that. ### Explicit exports. When there are no explicit exports, everything is exported from a module. Recall a case when this is disadvantageous: abstract types. The values of abstract types must only be obtained via smart constructors. So their definitions should not be made available. Explicit exports may provide that. However, there is another practice: putting dangerous definitions of the supposedly abstract type `X` into a module `X.Internal`, then importing them to module `X` and defining smart constructors there. By default, a module only exports the definitions defined in itself — there are no re-exports. So, a user importing `X` cannot invoke unsafe constructors from `X.Internal`, and they know better than to import the dangerous module directly. In the former case above, the internal definitions remain out of reach for a test suite. In the latter case, they may be freely checked as needed. ### Explicit imports. Recall the scenario in which explicit imports are useful. * A module `"p" X` from package `p` imports a module `"q" Y` from package `q v0.0.0`. * The package `q` bumps the third version number and exports a definition `Y.d` which name coincides with an already defined definition `X.d`. What happens? * If imports are explicit, nothing happens. The maintainers of `p` are safe if they set a restriction as weak as `q ^>= 0.0`. * If imports are implicit, there would be a clash of names if `p` is built against `q v0.0.1`, but the build would pass if it is built against a less recent version `q v0.0.0.1`. The maintainers of `p` might not even notice that the package does not build in some cases. When they do, they would have to set a restriction `q ^>= 0.0.0` But surely there is only one version to build against if the two modules reside in the same package. So the overlapping names will necessarily result in an error that would immediately be rectified. It is no different from any other compile time error. ## Are my considerations fair? [1]: https://discourse.haskell.org/t/are-explicit-exports-and-local-imports-desi…

3 8

ghcxxxx.exe in Local\Temp in Windows
by Sumit Raja 18 Sep '20

18 Sep '20

Hi, Running ghc 8.8.4 + cabal 3.2 on Windows. M365 malware scanner identified that ghcbdbc.exe in my temp directory was the Wacatac malware. I checked and there is a large number of these ghcxxxx.exe files in there. They look like build artefacts from cabal repl. The malware scanner process tree is cabal -> gcc -> realgcc -> collect2 with ld.exe being the exec that created it. Admin is confident that Wacatac was removed or it was a false alarm but I need to provide some details on why this build artefact is created. Anyone know what these files are? Thanks Sumit

1 0

[ANN] base16-bytestring-1.0.0.0
by Emily Pillmore 17 Sep '20

17 Sep '20

Hello Everyone, I'm pleased to announce version 1.0.0.0 of the `base16-bytestring` library. This release marks an epochal change in the library's structure, changing some existing features, and adding others. There was only on PR contribution marking this release, but it was a big omnibus one. In the latest release, we... * Improved performance by 3-4x for encode, 4-5x for decode. * Changed the ` decode` signature to return an error message with offset. The signature will now be ` ByteString -> Either String ByteString` in alignment with other encoding standards. * Actually test using the test vectors defined in the RFC, and uses property tests to ensure invariants hold. * Added lenient decoders to the API * Added ` -XTrustworthy` annotations to the relevant exposed modules * Rewrote the haddocks to be more up to date and fancy-styled. * Added benchmarks to the `.cabal` file as opposed to being a separate target, so they can be run at toplevel, and can exist as an integral part of the spec. * Bumped the Cabal version to 1.12 Thanks to Herbert and Mikhail for helping make this happen. Cheers, Emily

1 0

Design for DatatypeContexts: what was the idea, anyway?
by Anthony Clayden 15 Sep '20

15 Sep '20

Quite prosaically: the design for DatatypeContexts seems to have materialised with no visible discussion, neither agreement nor disagreement; and persisted almost unchanged until they got deprecated nearly 20 years later. I can guess there was a verbal discussion amongst the Committee circa 1990/91; that somebody was deputed to write down the conclusion (memo March 1991 [1]) ; and the implementers (both Committee members) went to work in Hugs and GHC. Much later (1999, while preparing the Haskell 1998 Report, published 2002) a fresh set of eyes spotted an under-explicitness that had been interpreted differently by the implementers; and there was a Committee thread resolving it. That thread is the best place from which to understand the intent, particularly Phil Wadler's comments [2]. Historical context: typeclasses/constraints/contexts were the new shiny thing, still rapidly evolving (Wadler early 1989, Wadler & Blott late 1989 but with several open questions). They were initially tied to overloading methods; by 1990 the Haskell report v1.0 included constraints for Numeric Literals, but with several caveats. The mailing lists had much back-and-forth about ambiguities and defaulting and (of course) the Dreaded Monomorphism Restriction for constrained terms. I see comments about the "dictionary transfer problem" and dictionaries "shared lazily between all applications to each elt [in a data structure]". The syntax of prefixing the context to the type constructor name (syntax in the 1990 Haskell Report, along with the admittedly vague descriptions there), suggests to me they were thought of as for numeric literals: `5 :: Num a => a` so `(ConsSet 5 NilSet) :: Num a => Set a`, where Set's `Eq a` is implied, as a superclass of Num. There's no visible method invocation. If the intent had been that the context attached only inside the data constructors, I'd expect syntax like one of these: data Set a = NilSet | (Eq a) => ConsSet a (Set a) data Set a = NilSet | ConsSet (Eq a) => a (Set a) (Syntax closer to that second did arrive later with GADTs.) The 1999 discussion concluded that the context should be exposed outside of a pattern match, even though a match only 'consumes' an already constructed value. Exposing makes sense if all data constructors enforce the context, but from the 1991 design, `NilSet`'s type doesn't mention the context (because there's no argument to the constructor to ground the type?). I'm confused by that: if Haskell 1990 supported `5 :: Num a => a`, what's wrong with `NilSet :: Eq a => Set a`? I sense quite a bit of exasperation in that 1991 memo: "Nobody has been able to give a satisfactory account", "Nobody has been able to explain", several phrases in block caps. The so-called "simplifications" are almost what Parliamentarians would call a 'wrecking amendment' (undermining or nullifying the intent of a proposal) or even applying Cunningham's Law (the quickest way to get the right answer is not to ask a question, but to post a wrong answer) -- except nobody (visibly) pushed back. And there's hints of dissent unresolved up to the 1999 exchange: "a broken feature of H98", "What you propose, I think, offers the worst of both worlds ", "a compile-time language feature can be hard to understand if it is not directly tied to run-time behaviour.", "Live and learn.". (Who should learn? Is that a self-admonition or aimed at others?) It's well known that SPJ dubbed the feature "stupid theta". The thing is: the scribe in 1991 was SPJ; even if he was only writing from dictation, why specify and then implement a "broken feature"? Or did it only earn the "stupid" as a result of the 1999 decision? Then it's notable in that decision that Hugs' behaviour was preferred; GHC was changed to align; but then GADTs design reverted to the GHC pre-1999 behaviour (which is reasonable considering different constructors have different constraints and return types). Pattern Synonyms support double-contexts in the signature, to be explicit about what's exposed/required outside a pattern match. I see much recent traffic (say on StackOverflow) that GADTs are DatatypeContexts 'done right'. I can't agree with that: GADTs are addressing a different set of use cases vs. the motivation Wadler explains in 1999 -- to enforce invariants -- which makes sense to me. AntC [1] http://web.archive.org/web/20160320062120/http://code.haskell.org/~dons/has… [2] http://web.archive.org/web/20151001115936/http://code.haskell.org/~dons/has… (The question is posed in the preceding message in the thread; follow the thread through to see the number of luminaries disagreeing with GHC's then behaviour.)

1 0

Need help to get started with GHC.Generics
by YueCompl 15 Sep '20

15 Sep '20

Dear Cafe, I'm tinkering with the idea for arbitrary Haskell functions to be easily called from scripting code, I see auto derive with GHC.Generics might be the most promising tool, but I'm lost after read https://wiki.haskell.org/GHC.Generics <https://wiki.haskell.org/GHC.Generics> and hackage docs. I have no clue so far with how to start with it. Specifically I want the section highlighted in blue get auto generated, within the following `runghc` ready example: ``` {-# LANGUAGE BangPatterns #-} module Main where import Prelude import GHC.Generics import Data.Dynamic -- * minimum data structures as interface with scripting code type AttrKey = String data AttrVal = NilValue | IntValue !Integer | StrValue !String deriving (Eq, Ord, Typeable) instance Show AttrVal where show NilValue = "nil" show (IntValue !x) = show x show (StrValue !x) = show x data ArgsPack = ArgsPack { positional'args :: [AttrVal] , keyword'args :: [(AttrKey, AttrVal)] } instance Semigroup ArgsPack where (ArgsPack p1 kw1) <> (ArgsPack p2 kw2) = ArgsPack (p1 ++ p2) (kw1 ++ kw2) instance Monoid ArgsPack where mempty = ArgsPack [] [] class Callable a where call :: a -> ArgsPack -> (AttrVal -> IO ()) -> IO () -- * functions to be callable from scripting code newtype Assert = Assert ( Expect -> Maybe Target -> Message -> IO Message ) type Expect = AttrVal type Target = AttrVal type Message = String instance Callable Assert where -- can this get auto-generated ? with https://wiki.haskell.org/GHC.Generics call (Assert !assert) (ArgsPack !args !kwargs) !exit = do (expect, target, message) <- parseApk result <- assert expect target message exit $ StrValue result where parseApk :: IO (Expect, Maybe Target, Message) parseApk = goParse (Left "missing arg: expect", Nothing, Left "missing arg: message") args kwargs goParse (got'expect, got'target, got'message) [] [] = case got'expect of Left msg -> error msg Right expect -> case got'message of Left msg -> error msg Right message -> return (expect, got'target, message) goParse (got'expect, got'target, got'message) args' ((name, val) : kwargs') = case name of "expect" -> case got'expect of Right{} -> error "duplicate arg: expect" Left{} -> goParse (Right val, got'target, got'message) args' kwargs' "target" -> case got'target of Just{} -> error "duplicate arg: target" Nothing -> goParse (got'expect, Just val, got'message) args' kwargs' "message" -> case got'message of Right{} -> error "duplicate arg: message" Left{} -> case val of StrValue message -> goParse (got'expect, got'target, Right message) args' kwargs' _ -> error "bad arg type for: message" _ -> error "unexpected keyword args" goParse (got'expect, got'target, got'message) (val : args') [] = case got'expect of Left{} -> goParse (Right val, got'target, got'message) args' [] Right{} -> case got'target of Nothing -> goParse (got'expect, Just val, got'message) args' [] Just{} -> case got'message of Left{} -> case val of StrValue message -> goParse (got'expect, got'target, Right message) args' [] _ -> error "bad arg type for: message" Right{} -> error "extranous positional args" -- mockup & test out main :: IO () main = call (Assert assert) (ArgsPack [IntValue 333, StrValue "as good will"] [("target", IntValue 333)] ) $ \result -> putStrLn $ "Got result: " <> show result -- | plain Haskell function meant to be easily called by scripting code assert :: Expect -> Maybe Target -> Message -> IO Message assert !expect !maybeTarget !message = case maybeTarget of Nothing -> return $ "* assertion not applicable: " <> message Just target -> if expect == target then return $ "* assertion passed: " <> message else error $ "* assertion failed: " <> message ``` I tried to understand how The compiler can provide a default generic implementation for parseJSON <https://hackage.haskell.org/package/aeson-1.5.4.0/docs/Data-Aeson.html#v:pa…>. is implemented in [aeson](https://hackage.haskell.org/package/aeson <https://hackage.haskell.org/package/aeson>) and it is overwhelming to me at the moment ... Is there easier scaffold template for me to start with GHC.Generics? Or there're even better techniques to achieve my final goal? Help please! Best regards, Compl

6 12

TypeApplications and Proxy
by Johannes Waldmann 15 Sep '20

15 Sep '20

Dear Cafe, since GHC has TypeApplication, we don't need Proxy that much? `natVal (Proxy :: Proxy w)` can be written as `natVal @w Proxy` but then, the argument `Proxy` looks unnecessary. I can define nat :: forall (n::Nat) . KnownNat n => Int nat = fromIntegral $ natVal @n Proxy and then use `nat @w`. (with -XAllowAmbiguousTypes.) I just wonder if that's already in some library. But then, what about the other direction (from value to type)? Is there a shorter way to write, e.g., reifyNat (read e) $ \ (_ :: Proxy w) -> run @w ... I see that Data.Reflection suggests `reifyNat (read 3) run` but then `run` needs the Proxy argument. Thanks, J.W.

5 6

GADT is not great - sometimes: can be almost as stupid as stupid theta
by Anthony Clayden 15 Sep '20

15 Sep '20

The sweet spot for GADTs is representing ASTs for EDSLs typefully. The characteristics of those use cases is that each data constructor: carries different constraints; returns a more specific type than `T a`; similarly recursion may be to a more specific type. There's a different use case (which is I suspect what was in mind for DatatypeContexts), with characteristics for each data constructor: * the constraints are the same for all the type's parameters; * the return type is bare `T a` * any recursion is also to bare `T a` So it's the same type `a` all the way down, and therefore the same instance for the constraint(s). Consider (adapted from the H98 Report for DatatypeContexts): {-# LANGUAGE GADTs #-} data SetG a where NilSetG :: Eq a => SetG a ConsSetG :: Eq a => a -> SetG a -> SetG a sillySetG = undefined :: SetG (Int -> Int) -- accepted, but useless -- sillySetG = NilSetG :: SetG (Int -> Int) -- rejected no Eq instance (DatatypeContext's equiv with NilSet constructor at `(Int -> Int)` is accepted, so some improvement.) elemSG x NilSetG = False elemSG x (ConsSetG y ys) | x == y = True | otherwise = elemSG x ys -- ===> elemSG :: a -> SetG a -> Bool -- no Eq a inferred The elem pattern matching test makes use of ConsSetG's Eq instance, but doesn't expose that in the inferred type. Whereas: headS (ConsSetG x _) = x -- hide the pattern match tailS (ConsSetG _ xs) = xs elemSh x NilSetG = False elemSh x yss | x == headS yss = True | otherwise = elemSG x $ tailS yss -- ==> elemSh :: Eq a => a -> SetG a -> Bool -- Eq a inferred A 'morally equivalent' elem test but with a different inferred type, exposing the `Eq a` constraint. If you give an explicit signature for `elemSh`, you must specify `Eq a` -- which is annoying same as with DatatypeContexts; an explicit signature for elemSG needn't -- which gives a more annoying imprecise type that'll get reported at some usage site. I'm concluding that for this use case, a GADT doesn't 'fix' all of the stupidness with stupid theta. AntC

2 2

Re: [Haskell-cafe] GADT is not great - sometimes: can be almost as stupid as stupid theta
by Anthony Clayden 14 Sep '20

14 Sep '20

> On Fri Sep 11 08:08:54 UTC 2020, Viktor Dukhovni wrote: > This, as I am sure you're aware, is correct, Hmm. If you mean 'working as per spec' (the OutsideIn paper), then OK. > but I'd also say unsurprising. The function indeed works for all `a`, it is just that for many `a` (those without an 'Eq' instance) the type `SetG a` is uninhabited, so the function is correct vacuously. On the basis that 'well-typed programs can't go wrong'; it allows a well-typed program that crashes. That's not correct. And it's not vacuous: `elemSG` matches on constructor; the only value of `sillySG`'s type is bottom -- i.e. no constructor. I can compile sillyElem = elemSG (id :: Int -> Int) sillySetG -- inferred type Bool Why is that not ill-typed, in the absence of an instance `Eq (Int -> Int)` ? Running that crashes *** Exception: Prelude.undefined. Whereas `elemSh (id :: Int -> Int) sillySetG` is not well-typed. I could of course specify a signature for `elemSG` with explicit `Eq a =>`, but needing to do that is exactly what people complain of with DatatypeContexts. > I wouldn't describe this situation as there being something "stupid" with GADTs. To be clear: I'm not saying there's something as stupid as with DatatypeContexts. I am saying there's a family of use-cases for which GADTs are not a good fit. The example you show using DatatypeContexts fails to compile `No instance for (Eq (Int -> Int))`, which is entirely reasonable; it does compile if supplied an instance, as you go on to show. > With this particular type, I'd argue the real problem is adding the constraints to the constructors in the first place. > With the constructors unconstrained, one gains the ability to define Functor instances, use Applicatives, ... No. Missing out the constraints is a craven surrender to the limitations in Haskell. Signatures/constraints should give maximum help to the compiler to accept only well-behaved programs. That limitation is because Functor, Applicative, etc are trying to keep backwards compatibility with H98 Prelude. One approach would be for their methods to have a signature with a type family defined constraint. Or the 'Partial Type Constructors' paper shows a possible approach -- which is really orthogonal to its main topic. AntC

2 3

Re: [Haskell-cafe] Recommended reading on non-algebraic types.
by Olaf Klinke 14 Sep '20

14 Sep '20

Dear Ignat, In the paper you linked to one should state more clearly that the two graph operations overlay and connect use an implicit equivalence relation between vertices of the two graphs involved. So these operations can be thought of as a traditional algebraic operation followed by a quotient. You might want to learn about domain semantics in general and domain environments in particular. Big names are Dana Scott and Gordon Plotkin, to name just two. Domain theory is the science of assigning (via a functor) an object of a category of partially ordered sets to each type of a (typed) lambda calculus and to each term of the calculus an arrow of that category. It turns out that algebraic domains are suitable for representing programs on algebraic data types. And if the category is just right and the lambda calculus is rich enough, then one can go the other way: Then you can prove that for each arrow in the category of domains there is a program that has that arrow as semantics. Algebraic domains match very nicely the way we build up complex data types via tuples, sums, function types and type recursion and how we build up functions via pattern matching and recursion. And every finite algebraic domain is a directed cycle-free graph. The little (free online) book by Thomas Streicher [1] might be a good start on domain semantics. A comprehensive mathematical theory of domains (not only algebraic ones) can be found in [2] but that book is expensive and hard to obtain. Sadly, with vanilla type systems such as Haskell's you can specify only algebraic domains. Anything beyond that is via "soft" definitions, meaning it can not be expressed in the type system, as you already observed. And domain theory provides mathematical proofs for this fact. Representing types like the prime numbers is possible with dependently- typed languages, but as far as I know these languages can also not go beyond algebraic domains, anyone please correct me if I'm wrong. Of course people have thought about representing other structures that are not algebraic domains. There are at least two ways I can think of: (1) What you call a sub-type: A subset of an algebraic domain. If the sub-type in question somehow sits "at the top" of the domain, then the surrounding algebraic domain is called a domain environment of the type in question. For example, the infinite binary tree is a domain environment of the type of infinite binary sequences. The important question to ask youself here is whether the sub-type is a computable one or not [*]. So if A is an algebraic data type, can you write a program that, given x :: A decides whether x is a member of the sub- type? For example, the sub-type of total functions A -> B is not a computable sub-type of the type of all functions A -> B for general A and B. (2) Quotients of algebraic domains. That means each element of your target type has several (maybe infinitely many) representations in an algebraic domain. This is fairly common. The Double data type has two representations for zero, because each Double value has a sign bit. If you want a set functor, take any container like [] or Seq and disregard multiplicities, so [x,y] and [x,y,y] represent the same set {x,y}. The art is then to write functions f that respect these quotients. Meaning if the values x and y both represent the same element in the quotient, then f(x) and f(y) represent the same element again. See section 4.2 in your linked paper on the problem of whether equivalence classes are computable. A stronger notion is a retract, that is a quotient map q :: A -> D together with a function e :: D -> A that embeds the type D back into the algebraic domain A such that q.e = id and q and e are adjoints. It is known that the retracts of algebraic domains are precisely the so- called continuous domains, a wide class that encompasses for example a real numbers object. Now you may also want to combine (1) and (2) and represent your data type as a quotient of a sub-set of an algebraic domain. As I see it your paper describes just that. It is still an open question whether certain continuous domains can be represented via expanding systems of finite domains, as is the case with algebraic domains [**]. My gut feeling is that such a description involves a description of quotients, but on another level: Since any quotient of a finite domain is algebraic, limits of such quotients will not take you beyond algebraic domains. Instead, one must describe what the quotient q :: A -> D does to the finite parts of A. Regards, Olaf [1] https://b-ok.org/book/768876/241ddb [2] Continuous lattices and domains, ISBN 0-521-80338-1 [*] One can prove that while there are uncountably many subsets of natural numbers, there are only countably many computable subsets in the sense that there exists a program that decides membership. [**] Give me any Haskell type and I show you the system of retractions of finite types whose limit is this type.

1 0

Recommended reading on non-algebraic types.
by Ignat Insarov 13 Sep '20

13 Sep '20

Hello Café. This is a request for reading. There is a huge literature on mathematics of program construction, but those are algebraic types therein considered; abstract types are hardly mentioned. At the same time, reality presents us with a range of compact mathematical constructions that are, however, not readily expressible via tagged unions, tuples and fixed points. A few examples: * The most usual `"containers" Data.Set (Set) ` is an abstract type that is not even lawful enough to be a functor. * It has been discovered that graphs can be represented by algebraic types _(see `alga` [1][1])_, but edge labels are, to my knowledge, not available. The types for graphs that have edge labels are all abstract. Coincidentally or not, the usual representations for the examples above are trees, refined with the use of smart constructors — so they are subtypes of algebraic types. There are less computationally accessible subtypes, say the type of prime numbers as a refinement of ℕ. So, my home baked theory is that abstract types represent subtyping in Haskell, so that every abstract type is a subtype of an algebraic type, matching a defining condition and equipped with a collection of constructors — functions whose range respects that condition. This means, for example, that: * Any projection of an algebraic type can be restricted to an abstract subtype for free. * There is a canonical partial one to one function from an algebraic type to its abstract subtype. Of course, we do not get anything like that in Haskell. Rather, we have _«abstract»_ abstract types, divorced from the underlying algebraic representation. As a consequence, we have only a handful abstract types in use, as each must be carefully crafted, verified and bundled with the totality of the interface — in a word, a bubble. By this point in my line of reasoning, I have to question if this fashion is justifiable. By now, the kind reader may concede that the matter is not without attraction. However, I am not aware of any prior art. For example, I wonder if there is a methodology for deciding if a given mathematical construction can be represented as an algebraic data type, and so far I have not seen this question being put forward. Please let me know if you have in mind some writing even faintly related to the line of inquiry presented above. [1]: https://github.com/snowleopard/alga-paper/releases/download/final/algebraic…

1 0

Re: [Haskell-cafe] Constraints as a moveable feast?
by Anthony Clayden 13 Sep '20

13 Sep '20

> on *Tue Sep 1 21:18:40 UTC 2020, Richard Eisenberg wrote:* > I see the core idea as a fairly straightforward generalization of the > "Partial Type Constructors" work -- except that I wouldn't phrase any of > this as "floating out". Thanks Richard, but no: I see this as exploring what was the idea in that brief example in the 1990 Report. (It's very vague, so we're all speculating.) The example there is a type synonym, which the PTC work doesn't consider. And putting the constraint syntactically before the type (synonym/data/new) name suggests to me it's 'outer'. GHC actually can express a bit what I mean by "floating out". I didn't realise that at the time of writing the O.P., so I'll rework the example. I'm correcting it because as you say: > In a few places, you've expanded Point a as Num a => (a, a). But Point a > is *not* the same thing as Num a => (a, a). Indeed, you didn't define it > that way. ... The library supplier writes: {#- LANGUAGE RankNTypes #-} type Num a => Point a = (a, a) -- proposed mkPoint :: a -> a -> Point a -- pretend to hide the constructor mkPoint x y = (x, y) -- no using numeric ops/no Num needed The compiler expands the synonym to mkPoint :: a -> a -> Num a => (a, a). Note no parens around the expansion, unlike my O.P. That expansion is not valid H98, but it is valid in GHC with RankNTypes. The docos say it's a Rank-1 type. GHC infers mkPoint :: Num a => a -> a -> (a, a) And that's why I call it "floating out". Longer example below. The idea is the library writer could later change the implementation to a datatype or a newtype, etc; or even add a further constraint. They all carry the constraint(s) 'outer'; the client code doesn't need to know about the change. > Instead, we should understand Point a to expand to (a, a) only when Num a holds. That might be a valid use case (especially for constrained classes/type families); but it's not the use case I have in mind. > So, the occurrence of Point a causes a Num a constraint to arise. > These Num a constraints then get put into the type. No floating. We all think the 1991 DatatypeContexts design is daft because it raises wanted constraints but doesn't "put" them anywhere, so the client-module programmer has to add them explicitly in signatures. To improve that, where/how should the compiler "put into the type"? The client writes scale :: a -> Point a -> Point a -- expand the synonyms; then float out and squish duplicates -- ===> scale :: a -> Num a => (a, a) -> Num a => (a, a) -- no parens added -- ===> scale :: Num a => a -> (a, a) -> (a, a) The 'no parens' step (different to my O.P.) is valid GHC with RankNTypes; the last step is as GHC infers today, with Num a floated out. (Or if you don't like that phrase: "canonicalises", "simplifies"?) > Note that types like `(Num a => a) -> a` and `Num a => a -> a` > (both very valid today) mean quite different things, Yes; although the first isn't valid H98/wasn't valid in 1990; and I'm struggling to think of a use case for it, noting there's no existential quant inside the parens. (It's not Rank-2, but is it plain Rank-1 or Rank-1-and-a-half?) Anyhoo that was an error on my part. > I think by rephrasing this without floating, we avoid the trouble with > existentials, etc., that you are worried about. I'm not sure on that, but we'll leave it for another day. > Personally, I would tack this onto "Partial Type Constructors" > instead of trying to make this happen independently, > but the two features would go nicely together. PTCs introduce a lot of heavy machinery; whereas I'm thinking of this as just-below-the-surface syntactic sugar that gets expanded before type inference. OTOH this doesn't on its own support `instance Functor Point`, treating the type synonym as an unapplied constructor -- which is what the Hughes 1999 paper is tackling. (I have an idea how that could go using this same syntactic expansion idea.) Note BTW, that I didn't add any constraints to the data constructors -- which is all the 1991 design does (and that not consistently). Constructing a `Point` doesn't need any Num ops/methods. But the type is supplying a wanted Num a 'outside', because any expression operating on a Point likely uses arithmetic. Constraints on data constructors (as with GADTs) I see as orthogonal: there will be use cases for one alone, the other alone, or both combined. AntC

2 2

Implementing parallelism using actors. How to improve the code.
by Luc Duponcheel 10 Sep '20

10 Sep '20

-- Hello, I am Luc Duponcheel. -- I started as a Haskell programmer, -- went to Java for a living, -- naturally evolved to Scala, -- and, being retired now, -- went back to my first love ... -- I am working on a library -- _______ __ __ _______ -- / ___ /\ / /\ / /\ / ___ /\ -- / /__/ / / _____/ / / / /_/__ / /__/ / / -- / _____/ / / ___ / / / ___ /\ /____ / / -- / /\____\/ / /__/ / / / /__/ / / \___/ / / -- /_/ / /______/ / /______/ / /_/ / -- \_\/ \______\/ \______\/ \_\/ -- v1.0 -- Program Description Based Programming Library -- author Luc Duponcheel 2020 - ... -- I started writing code in Scala (presented it at several conferences). -- I encountered issues with the fact that lazyness is not the default evaluation strategy. -- I switched to Haskell. -- In short: the library is about pointfree categorical programming -- (you may wish to have a look at ( https://www.youtube.com/watch?v=23VEcabMk7k (warning low sound volume)) -- below is some code with comments (you can load the code in ghci) -- it works fine but I want to get rid of the extra type class parameters x and w -- I tried to get rid of x and w in two ways -- . using forall -- . using a GADT -- -- both approaches failed -- -- the relevant code changes that I tried are commented out -- they are underneath the code that follows -- the code -- specifies parallelism -- and -- implements it using a dummy version of the hakka library -- (see https://hackage.haskell.org/package/hakka-0.2.0/docs/src/Hakka-Actor.html) -- first I need some language extensions {-# LANGUAGE TypeOperators #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE InstanceSigs #-} {-# LANGUAGE LambdaCase #-} {-# LANGUAGE GADTs #-} -- next I need some imports import Control.Monad.IO.Class import Control.Monad.Trans.Class import Control.Monad.Trans.State.Strict import Control.Monad.Trans.Cont -- next some useful generic code infixr `c` infixr `d` f `c` g = f . g (f `d` g) h = f `c` g h -- -- parallel specification -- -- note the extra type class parameters x and w -- type z && y = (z, y) class Parallel x w to where par :: (z `to` x) -> (y `to` w) -> (z && y) `to` (x && w) -- -- parallel implementation -- -- o msg stands for message -- o mnd stands for monad -- o rst stands for result -- -- -- three actors involved -- -- o reactor -- - reacts by using a continuation cont when both -- . an x result (at left) -- . a w result (at right) -- have been received -- -- o leftActor -- - acts to send an x result (at left) to reactor -- -- o rightActor -- - acts to send a w result (at right) to reactor -- -- reactor sends both leftActor and rightActor a message to let them act -- data ActorRef = ActorRef newtype ActorContext msg = ActorContext msg newtype ActorT msg mnd z = ActorT { runActorT :: StateT (ActorContext msg) mnd z } deriving (Functor, Applicative, Monad, MonadFail, MonadTrans, MonadIO) actor :: String -> (msg -> ActorT msg IO ()) -> ActorT msg IO ActorRef actor name messageHandler = undefined become :: (msg -> ActorT msg IO ()) -> ActorT msg IO () become messageHandler = undefined (!) :: ActorRef -> msg -> ActorT msg IO () actorRef ! message = undefined newtype ReactiveT msg rst mnd z = ReactiveT { runReactiveT :: ContT rst (ActorT msg mnd) z } deriving (Functor, Applicative, Monad, MonadFail, MonadIO) newtype KleisliT mnd z y = KleisliT { runKleisliT :: z -> mnd y } type ReactiveParallelT msg rst mnd = KleisliT (ReactiveT msg rst mnd) data Message x w = LeftReact x | RightReact w | LeftAct | RightAct type ReactiveActorBasedParallelT x w = ReactiveParallelT (Message x w) () IO runReactiveActorBasedParallelT = runContT `d` runReactiveT `d` runKleisliT instance Parallel x w (ReactiveActorBasedParallelT x w) where par z2x y2w = KleisliT (\case (z, y) -> ReactiveT (ContT (\cont -> actor "reactor" (\case LeftReact x -> become (\case RightReact w -> cont (x, w) ) RightReact w -> become (\case LeftReact x -> cont (x, w) ) ) >>= \reactorRef -> actor "leftActor" (\case LeftAct -> runReactiveActorBasedParallelT z2x z (\x -> reactorRef ! LeftReact x) ) >>= \leftActorRef -> actor "rightActor" (\case RightAct -> runReactiveActorBasedParallelT y2w y (\w -> reactorRef ! RightReact w) ) >>= \rightActorRef -> leftActorRef ! LeftAct >> rightActorRef ! RightAct ) ) ) -- class Parallel to where -- data Message = forall x. LeftReact x | forall w. RightReact w | LeftAct | RightAct -- data Message where -- LeftReact :: x -> Message -- RightReact :: w -> Message -- LeftAct :: Message -- RightAct :: Message -- type ReactiveActorBasedParallelT = ReactiveParallelT Message () IO -- instance Parallel (ReactiveActorBasedParallelT IO) where -- __~O -\ <, (*)/ (*) reality goes far beyond imagination

2 2

Re: [Haskell-cafe] Cannot update a field in a record with a polymorphic type.
by Olaf Klinke 10 Sep '20

10 Sep '20

I take it that in the expression (defaultY ∷ ∀ α. Monoid α ⇒ Y α) {y = "c"} the compiler is not smart enough to infer that the concrete value of α is irrelevant for the outcome and therefore rejects the program. The obligation here is to prove that the function λ x. x {y = "c"} :: ∀ α. Y α -> Y String is constant across all possible values of α, which I guess is undecidable for general one-parameter types? Or is there a free theorem saying that whenever a function has this general type signature, then the α cannot possibly be used? This certainly fails if Y has more type parameters that remain constant in the expression: A type class could distinguish the extra type parameters even if at the value level the result is constant across all α. Olaf

5 8

Re: [Haskell-cafe] Constraints as a moveable feast?
by Anthony Clayden 10 Sep '20

10 Sep '20

> On *Tue Sep 1 21:18:40 UTC 2020, ** Richard Eisenberg wrote:* *> *I see the core idea as a fairly straightforward generalization of the "Partial Type Constructors" work Ah. Now I see a bit more of what you're getting at. We want as if the type synonym were an associated type family with a most-general instance class Num a => CPoint a where type Point a instance Num a => CPoint a where type Point a = (a, a) The semantics to be as the PTC paper, such that expanding `Point a` always requires a `CPoint a` instance, which will in turn want a `Num a`. And the expansion to be immediate (as with type synonyms) so that the client can put `Point a` in instance heads, for example. > But I really don't know what it means to expand without adding parens. ... what about > *pointX :: Point a -> a* *> ... *We don't want that type to expand to (Num a => (a, a)) -> a Ok, it was your using fancy type operators that put me off. We can represent the AST (and show the need for parens) by reverting to prefix syntax, within H98: pointX :: (->) (Point a) a -- needs parens around (Point a) And yes my naieve syntactic expansion would give the type you show, wot we do not want. AntC

1 0

Counterintuitive ScopedTypeVariables behaviour
by Tom Ellis 08 Sep '20

08 Sep '20

I have just noticed that with ScopedTypeVariables one can write the following bizarre definition -- Inferred signature: -- add :: Num a => a -> a -> a add (x :: a) (y :: b) = x + y The reason for this behaviour is that > in all patterns other than pattern bindings, a pattern type > signature may mention a type variable that is not in scope; in this > case, the signature brings that type variable into scope. https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_ext… and the justification is that > Bringing type variables into scope is particularly important for > existential data constructors But this leads to a rather puzzling user experience. Was it really not possible to design this extension in a way that would allow bringing new type variables into scope locally but not allow them to unify with other type variables from outer scopes? To be more concrete, what I would like to see is a design where `k` is allowed because the type `a` (bound within a pattern) does not need to unify with anything but `k2` is not allowed because `a` is forbidden to unify with `b`. `k3` would also be forbidden (the type variables called `a` are actually distinct) as would `k4` (the type variable for the inferred signature would be fresh and distinct from `a`). I believe this design might lead to much less puzzling behaviour. Would it be possible (within a new extension, of course) or have I overlooked something? Tom data T = forall a. MkT [a] k :: T -> T k (MkT [t::a]) = MkT t3 where (t3::[a]) = [t,t,t] data T2 a = MkT2 [a] k2 :: T2 b -> T2 b k2 (MkT2 [t::a]) = MkT2 t3 where (t3::[a]) = [t,t,t] k3 :: T2 a -> T2 a k3 (MkT2 [t::a]) = MkT2 t3 where (t3::[a]) = [t,t,t] k4 (MkT2 [t::a]) = MkT2 t3 where (t3::[a]) = [t,t,t]

5 13

Cannot update a field in a record with a polymorphic type.
by Ignat Insarov 06 Sep '20

06 Sep '20

Hello. I have a problem trying to do something very simple. Consider this conversation with GHC: λ data Y α = Y {y ∷ α} λ defaultY = Y {y = mempty} λ :type defaultY defaultY :: Monoid α => Y α λ :type defaultY {y = "c"} ∷ Y String <interactive>:1:1: error: • Ambiguous type variable ‘α0’ arising from a use of ‘defaultY’ prevents the constraint ‘(Monoid α0)’ from being solved. Probable fix: use a type annotation to specify what ‘α0’ should be. These potential instances exist: instance Monoid a => Monoid (IO a) -- Defined in ‘GHC.Base’ instance Monoid Ordering -- Defined in ‘GHC.Base’ instance Semigroup a => Monoid (Maybe a) -- Defined in ‘GHC.Base’ ...plus 7 others (use -fprint-potential-instances to see them all) • In the expression: defaultY In the expression: defaultY {y = "c"} :: Y String Why does this not work?

4 5

call tree of cost centers in a .prof file
by Marco Zocca 06 Sep '20

06 Sep '20

Hi all, I don't understand the tree-shaped visualizations produced by profiteur, profiterole and ghc-prof-flamegraph . Specifically, I initially thought that cost centers that are displayed closer to the leaves would be due to calls higher up in the tree, but that doesn't seem to be the case. Example; I've produced this basic visualization with ghc-prof and Data.Tree.drawTree (which mirrors qualitatively what flamegraph et al. produce) : MAIN 100.0 | +- Main.trained 100.0 | | | +- ER.ML.Classification.logreg 99.2 | | | | | +- ER.ML.Classification.irls 96.4 | | | | | | | +- ER.ML.Classification.hessianC 30.3 | | | | | | | | | +- ER.Math.Matrix.outerD 30.3 | | | | | | | | | | | `- Main.binMixtureData 29.8 | | | | | | | | | | | +- ER.Math.Random.SplitMix.mvNormalSM 28.8 | | | | | | | | | | | | | `- ER.Math.Matrix.matVec 28.2 | | | | | | | | | | | `- ER.ML.Common.centerDataWMEC 1.0 It looks fine down to level 4 (trained calls logreg, which calls irls, which calls hessianC, which calls outerD), and then it stops making sense (binMixtureData is not ever called by outerD). Could someone please shed some light on this? Thank you in advance

2 1

ANN: hledger-1.19
by Simon Michael 02 Sep '20

02 Sep '20

I'm pleased to announce hledger 1.19 ! hledger is a robust, cross-platform, plain text accounting tool, with command-line, terminal and web UIs. It is a modern and largely compatible reimplementation of Ledger CLI with many improvements. You can use it to track time, money, investments, cryptocurrencies, inventory and more. See: http://hledger.org http://plaintextaccounting.org HIGHLIGHTS: New aregister and codes commands, more powerful CSV conditional rules, new sql output format, consistently default to flat mode, better colour control, cashflow report customisable like the others, more number/date/regexp parsing/validation, more speed. See all changes at https://hledger.org/release-notes . Thanks to release contributors Stephen Morgan, Dmitry Astapov, Michael Sanders, Henning Thielemann, Martin Michlmayr, and Colin Woodbury. GETTING STARTED: Many install methods are described at http://hledger.org/download. Here are three ways to build from source: stack update; stack install --resolver=lts hledger-lib-1.19 hledger-1.19 hledger-ui-1.19 hledger-web-1.19 --silent or: cabal v2-update; cabal v2-install hledger-1.19 hledger-web-1.19 hledger-ui-1.19 or: curl -sO https://raw.githubusercontent.com/simonmichael/hledger/master/hledger-insta… less hledger-install.sh bash hledger-install.sh While building, peruse https://hledger.org/start For help, see http://hledger.org#help-feedback and join us on Freenode (#hledger, http://irc.hledger.org) or via Matrix (#freenode_#hledger:matrix.org, http://riot.hledger.org) New and old users, contributors, sponsors, and all feedback are most welcome! Best, -Simon

1 0

[ANN] compact-sequences-0.2.0.0
by David Feuer 02 Sep '20

02 Sep '20

I am pleased to release the second version of the compact-sequences package, now with deques! Changes: * Add deques. * Change operator precedence. * Add a test suite. Thanks to David Himmelstrup for setting up the test and CI framework. * Clean up internals somewhat. * Add a proof of amortized bounds for the stack implementation. Thanks, Li-Yao Xia. There are still plenty of things to work on, and help is always welcome. David Feuer

3 5

Constraints as a moveable feast?
by Anthony Clayden 02 Sep '20

02 Sep '20

There's the makings of a cute feature in a very old Haskell Language report. (With thanks to the 'Partial Type Constructors' 2019 paper for ferreting this out.) type Num a => Point a = (a, a) 1990 v1.0 Haskell report. Yes that's a type synonym with a constraint. I'll give their examples, though they don't really demonstrate the potential: origin :: Point Integer -- we get Num a => wanted then discharged for free origin = (0, 0) -- although the appearance of zero wants Num a anyway scale :: (Num a) => a -> Point a -> Point a -- seems wrong to give explicit Num a scale w (x,y) = (w*x, w*y) -- the above sig would be inferred anyway The feature disappeared without trace in the next year's Language report. I'm thinking we should be able to write scale :: a -> Point a -> Point a -- get Num a for free by: scale :: a -> (Num a => (a, a)) -> (Num a => (a, a)) -- expand the synonym -- this sig currently illegal scale :: Num a => a -> (a, a) -> (a, a) -- float the constraints out to the implicit forall So this isn't specific to type synonyms: in general allow prefixing constraints to any sub-term in a type; type inference floats them to the front of the signature. You can kinda get the effect today (so I don't think this is entirely whacky), by cunning use of dummies and term-level combinators: typePoint :: Num a => (a, a) typePoint = undefined scale w xy = const (undefined `asTypeOf` xy `asTypeOf` typePoint) (w `asTypeOf` fst xy) -- inferred scale :: Num a => a -> (a,a) -> (a,a) (Putting a dummy undefined on RHS to show there's nothing up my sleeves, because the actual expression would unify to the right type anyway.) You can get maybe cleaner code with PatternSignatures. But it's all workarounds in terms/expressions. I want to do the Right Thing and get it accepted as a stand-alone signature. A couple of caveats: * Haskell 1990 didn't have MultiParam Type Classes; * nor existential quant. So if a nested constraint mentions both an existential tyvar with narrow scope and a universally quant'd tyvar, can't float out that constraint, have to reject the sig. The constraint in `type Num a => Point a = ...` appearing to the left of the introduced type syn, is also reminiscent of DatatypeContexts, so we could similarly float out the constraints from those appearing within a sig(?) And this would be a way to put constraints on newtypes similarly(?) (Can't put constraints on those currently, because there's not really a data constructor to bind the class dictionary to. Haskell 1990 didn't have newtypes.) Or is there something deeply anti-System FC here? AntC

2 1

[ANN] Accelerate v1.3
by Trevor McDonell 01 Sep '20

01 Sep '20

Hi all, On behalf of the Accelerate team, I'm happy to announce the release of version 1.3 of Accelerate: http://hackage.haskell.org/package/accelerate-1.3.0.0 This release includes many quality-of-life improvements for defining and using your own data types in embedded code. A summary of these new features is included in this release announcement. Generic Instances of Elt and Arrays are now derivable via Generic for simple (non-recursive Haskell'98) data types: data Point = Point Float Float Float deriving (Generic, Elt) At the scalar level we now also support *sum* data types: data Object = Sphere Point Float | Triangle Point Point Point deriving (Generic, Elt) Pattern synonyms Pattern synonyms for creating and accessing data types can now be defined and used, which in practice makes GHC's type checker far less angry than the old method of lift and unlift (which still exists). Pattern synonyms are used in the same way as you would a regular data constructor. Included are synonyms for tuples up to 16-tuples (T2, T3...) as well as indices (Z_, ::., I1, I2...) and other standard data types (Just_, True_, etc.) Defining your own pattern synonyms for product types can be done via the overloaded Pattern synonym at both the scalar: pattern Point_ :: Exp Float -> Exp Float -> Exp Float -> Exp Point pattern Point_ x y z = Pattern (x, y, z) ...and array levels: data State = State (Vector Point) (Vector Float) deriving (Generic, Arrays) pattern State_ :: Acc (Vector Point) -> Acc (Vector Float) -> Acc State pattern State_ { positions, masses } = Pattern (positions, masses) Note the syntax of the last example, which also generates the two accessor functions positions :: Acc State -> Acc (Vector Point) and masses :: Acc State -> Acc (Vector Float). This syntax is of course also available for use in Exp patterns. Defining pattern synonyms can also be achieved with the following TemplateHaskell splice (which is required for sum data types): mkPattern ''Object Embedded pattern matching This release also introduces support for *embedded pattern matching* via the new match operator, which allows us to reuse Haskell's case syntax in embedded code: intersect :: Exp Ray -> Exp Object -> Exp Bool intersect ray = match \case Sphere_ c r -> ... Triangle_ a b c -> ... Packages This release consists of the following packages: - accelerate-1.3.0.0 - accelerate-llvm-1.3.0.0 - accelerate-llvm-native-1.3.0.0 - accelerate-llvm-ptx-1.3.0.0 - accelerate-fft-1.3.0.0 - accelerate-examples-1.3.0.0 - accelerate-blas-0.3.0.0 - accelerate-bignum-0.3.0.0 - accelerate-io-1.3.0.0 - accelerate-io-array-0.1.0.0 - accelerate-io-bmp-0.1.0.0 - accelerate-io-bytestring-0.1.0.0 - accelerate-io-cereal-0.1.0.0 - accelerate-io-JuicyPixels-0.1.0.0 - accelerate-io-repa-0.1.0.0 - accelerate-io-vector-0.1.0.0 - colour-accelerate-0.4.0.0 - containers-accelerate-0.1.0.0 - hashable-accelerate-0.1.0.0 - gloss-accelerate-2.1.0.0 - gloss-raster-accelerate-2.1.0.0 - lens-accelerate-0.3.0.0 - linear-accelerate-0.7.0.0 - mwc-random-accelerate-0.2.0.0 - cuda-0.10.2.0 - cufft-0.10.0.0 - cublas-0.6.0.0 - cusparse-0.3.0.0 - cusolver-0.3.0.0 - nvvm-0.10.0.0 Contributors Special thanks to those who contributed to this release: - Trevor L. McDonell (@tmcdonell <https://github.com/tmcdonell>) - Joshua Meredith (@JoshMeredith <https://github.com/JoshMeredith>) - Ivo Gabe de Wolff (@ivogabe <https://github.com/ivogabe>) - David van Balen (@dpvanbalen <https://github.com/dpvanbalen>) - Jaro Reinders (@noughtmare <https://github.com/noughtmare>) - Alex Lang (@alang9 <https://github.com/alang9>) - Paul Wilson (@statusfailed <https://github.com/statusfailed>) - @lennonhill <https://github.com/lennonhill> - Travis Whitaker (@TravisWhitaker <https://github.com/TravisWhitaker>) - Roger Bosman (@rogerbosman <https://github.com/rogerbosman>) - Robbert van der Helm (@robbert-vdh <https://github.com/robbert-vdh>) - Sam (@sam-340453 <https://github.com/sam-340453>) - Lars van den Haak (@sakehl <https://github.com/sakehl>) - Rinat Striungis (@Haskell-mouse <https://github.com/Haskell-mouse>) - Viktor Kronvall (@considerate <https://github.com/considerate>) - Tom Smeding (@tomsmeding <https://github.com/tomsmeding>) - Ryan Scott (@RyanGlScott <https://github.com/RyanGlScott>)

2 2

contribute to GHC by adding documentation
by Richard Eisenberg 31 Aug '20

31 Aug '20

Hi all, Occasionally I get emails asking how a newcomer can best contribute to GHC. I have some stock answers (find a feature in Haskell and implement it in Template Haskell; find an unimplemented proposal and implement it), but these sometimes don't work out. Wait no longer! If you'd like to contribute to GHC, there is a great chance in https://gitlab.haskell.org/ghc/ghc/-/issues/18633, which links to a file listing scores of undocumented compiler flags. Your task, if you choose to accept it: document these flags! Along the way, you will get to learn about various dark corners of GHC (and who doesn't love to lurk in dark corners?) and prod other GHC folks to produce answers to esoteric questions. Hours of fun to be had here! And along the way, you would do us all a wonderful service. Thanks, Richard

1 0

RebindableSyntax Strangeness
by Henry Laxen 31 Aug '20

31 Aug '20

Hi Cafe, I have encountered the following puzzling behaviour from a very simple program: Consider -- {-# LANGUAGE RebindableSyntax #-} module A where import Data.Time running this with ghci gives: A> :i UTCTime type UTCTime :: * data UTCTime = UTCTime {utctDay :: Day, utctDayTime :: DiffTime} -- Defined in ‘time-1.9.3:Data.Time.Clock.Internal.UTCTime’ instance [safe] Eq UTCTime -- Defined in ‘time-1.9.3:Data.Time.Clock.Internal.UTCTime’ instance [safe] Ord UTCTime -- Defined in ‘time-1.9.3:Data.Time.Clock.Internal.UTCTime’ instance [safe] Show UTCTime -- Defined in ‘time-1.9.3:Data.Time.LocalTime.Internal.ZonedTime’ instance [safe] FormatTime UTCTime -- Defined in ‘time-1.9.3:Data.Time.Format.Format.Instances’ instance [safe] Read UTCTime -- Defined in ‘time-1.9.3:Data.Time.Format.Parse’ instance [safe] ParseTime UTCTime -- Defined in ‘time-1.9.3:Data.Time.Format.Parse.Instances’ Now uncomment the first line (RebindableSyntax) and rerun it: A> :i UTCTime type UTCTime :: * data UTCTime = UTCTime {utctDay :: Day, utctDayTime :: DiffTime} -- Defined in ‘time-1.9.3:Data.Time.Clock.Internal.UTCTime’ instance [safe] FormatTime UTCTime -- Defined in ‘time-1.9.3:Data.Time.Format.Format.Instances’ instance [safe] ParseTime UTCTime -- Defined in ‘time-1.9.3:Data.Time.Format.Parse.Instances’ And all of the nice instances for UTCTime have disappeared. Why? Best wishes, Henry Laxen

2 1

augmenting GHC package database
by Sylvester Hazel 28 Aug '20

28 Aug '20

Hi Haskellers, Cabal couldn't resolve dependencies for a generated package so I used Stack that used 2 different GHC versions to build library from this package. Stack stored the library as libHSclient-something.a , HSclient-something.o and helper ".hi" files The dependent libraries Stack stored and registered at C:\sr..\lib\ How to add this information to GHC or Cabal database to be able to use this new library? This is on Chocolatey managed Windows platform;-)

4 5

writing wizards in Yesod
by Olaf Klinke 27 Aug '20

27 Aug '20

Dear Café, TL;DR: What is the canonical way to deal with state in Yesod? IORef? StateT? Routes? Subsites? The Yesod book [1,2] gives examples where state is encoded in an IORef inside the foundational type, like so: data AppState = ... data App = App {appState :: IORef AppState} All handlers would then first read the AppState via getsYesod appState >>= (liftIO . readIORef) and branch on the result. I wonder if there are other ways to deal with state that changes through user interaction. After all, we have instance MonadHandler m => MonadHandler (StateT s m) in Yesod.Core. What is this useful for? From [1]: "By just providing you with a readable environment, you’re able to recreate a StateT transformer by relying on mutable references." also: "In order to run these [monad transformer actions], we can use the standard [...] unwrap functions [...] to run the action and get back a normal Handler." I interpret quote 1 as "StateT is to be emulated (via IORef), not used literally" and quote 2 as "real StateT can not be used directly, but must be unwrapped to be used in a handler". Context for my question: I found that Kleisli maps model wizards nicely as a sequence of fragments, e.g. Program User f :: () -> m a g :: a -> m b h :: b -> m c i :: c -> m d j :: d -> m () wizard :: m () wizard = (f >=> g >=> h >=> i >=> j) () The intermediate types a, c are questions and b, d are answers, and all types together form the program states. If the user side of the wizard is to be provided by websites, we need to model these states explicitly somehow. My current approach is to use the union type AppState = Start | Answer1 b | Answer2 d that tells the handler what step to serve next. Olaf [1] https://www.yesodweb.com/book/yesods-monads#yesods-monads_adding_a_new_mona… [2] https://www.yesodweb.com/book/visitor-counter

3 6

Munich Haskell Meeting, 2020-08-27 @ 19:30
by Leah Neukirchen 26 Aug '20

26 Aug '20

Dear all, This week, our monthly Munich Haskell Meeting will take place again on Thursday, August 27 at Hirschgarten at 19h30. For details see here: http://muenchen.haskell.bayern/dates.html Please add yourself here if you want to come so we know who to look out for: https://dudle.inf.tu-dresden.de/haskell-munich-aug-2020/ Unfortunately, I almost forgot about the meeting tomorrow, please excuse the short notice. I'm also at Hirschgarten for other reasons, so I may drop by only for a short time. Everybody is welcome! cu, -- Leah Neukirchen <leah(a)vuxu.org> https://leahneukirchen.org/

2 1

Call for participation for IFL 2020: 32nd Symposium on Implementation and Application of Functional Languages
by Simon Thompson 26 Aug '20

26 Aug '20

[apologies for any multiple copies] ======================================================= IFL 2020 32nd Symposium on Implementation and Application of Functional Languages Call for Participation venue: online 2nd - 4th September 2020 https://www.cs.kent.ac.uk/events/2020/ifl20/ ======================================================== ### Scope The goal of the IFL symposia is to bring together researchers actively engaged in the implementation and application of functional and function-based programming languages. IFL 2020 will be a venue for researchers to present and discuss new ideas and concepts, work in progress, and publication-ripe results related to the implementation and application of functional languages and function-based programming. ### Registration The symposium will be run via Zoom (zoom.us<http://zoom.us>). If you can use Zoom, then you can participate. Please register for free via Eventbrite on the symposium webpage: https://www.cs.kent.ac.uk/events/2020/ifl20/ ### Programme Day 1: Wednesday, 2 September 12:45 Welcome 13:00 Nico Naus and Johan Jeuring: End-user feedback in multi-user workflow systems 13:30 Mart Lubbers, Haye Böhm, Pieter Koopman and Rinus Plasmeijer: Asynchronous Shared Data Sources 14:00 Pieter Koopman, Steffen Michels and Rinus Plasmeijer: Dynamic Editors for Well-Typed Expressions 14:30 Bas Lijnse and Rinus Plasmeijer: Asymmetric Composable Web Editors in iTasks 15:00 Social break 15:30 Sven-Olof Nyström: A subtyping system for Erlang 16:00 Andrew Marmaduke, Christopher Jenkins and Aaron Stump: Generic Zero-Cost Constructor Subtyping 16:30 Joris Burgers, Jurriaan Hage and Alejandro Serrano: Heuristics-based Type Error Diagnosis for Haskell - The case of GADTs and local reasoning 17:00 Social break 17:30 Kavon Farvardin and John Reppy: A New Backend for Standard ML of New Jersey 18:00 Chaitanya Koparkar, Mike Rainey, Michael Vollmer, Milind Kulkarni and Ryan R. Newton: A Compiler Approach Reconciling Parallelism and Dense Representations for Irregular Trees 18:30 Hans-Nikolai Vießmann and Sven-Bodo Scholz: Effective Host-GPU Memory Mangement Through Code Generation 20:00 Virtual Pub Day 2: Thursday, 3 September 10:00 Virtual Breakfast 13:00 Michal Gajda: Less Arbitrary waiting time 13:30 Sólrún Halla Einarsdóttir and Nicholas Smallbone: Template-based Theory Exploration: Discovering Properties of Functional Programs by Testing 14:00 Péter Bereczky, Dániel Horpácsi, Judit Kőszegi, Soma Szeier and Simon Thompson: Validating Formal Semantics by Comparative Testing 14:30 Social break 15:00 Gergo Erdi: An Adventure in Symbolic Execution 15:30 Joshua M. Schappel, Sachin Mahashabde and Marco T. Morazan: Using OO Design Patterns in a Functional Programming Setting 16:00 Filipe Varjão: Functional Programming and Interval Arithmetic with High Accuracy 16:30 Social break 17:00 Laith Sakka, Chaitanya Koparkar, Michael Vollmer, Vidush Singhal, Sam Tobin-Hochstadt, Ryan R. Newton and Milind Kulkarni: General Deforestation Using Fusion, Tupling and Intensive Redundancy Analysis 17:30 Benjamin Mourad and Matteo Cimini: A Declarative Gradualizer with Lang-n-Change 18:00 Maheen Riaz Contractor and Matthew Fluet: Type- and Control-Flow Directed Defunctionalization 19:30 Virtual Pub Day 3: Friday, 4 September 10:00 Virtual Breakfast 13:00 Michal Gajda: Towards a more perfect union type 13:30 Folkert de Vries, Sjaak Smetsers and Sven-Bodo Scholz: Container Unification for Uniqueness Types 14:00 Alejandro Díaz-Caro, Pablo E. Martínez López and Cristian Sottile: Polymorphic System I 14:30 Social break 15:00 Michal Gajda: Schema-driven mutation of datatype with multiple representations 15:30 Alexandre Garcia de Oliveira, Mauro Jaskelioff and Ana Cristina Vieira de Melo: On Structuring Pure Functional Programs with Monoidal Profunctors 16:00 Sara Moreira, Pedro Vasconcelos and Mário Florido: Resource Analysis for Lazy Evaluation with Polynomial Potential 16:30 Social break 17:00 Neil Mitchell, Moritz Kiefer, Pepe Iborra, Luke Lau, Zubin Duggal, Hannes Siebenhandl, Matthew Pickering and Alan Zimmerman: Building an Integrated Development Environment (IDE) on top of a Build System 17:30 Evan Sitt, Xiaotian Su, Beka Grdzelishvili, Zurab Tsinadze, Zongpu Xie, Hossameldin Abdin, Giorgi Botkoveli, Nikola Cenikj, Tringa Sylaj and Viktoria Zsok: Functional Programming Application for Digital Synthesis Implementation 18:00 Jocelyn Serot: HoCL: High level specification of dataflow graphs 19:30 Virtual Pub All times are in British Summer Time (BST), the local time in Canterbury, UK. So please translate these into your own time zone, using a service such as time and date. Simon Thompson | Professor Emeritus of Logic and Computation School of Computing | University of Kent | Canterbury, CT2 7NF, UK s.j.thompson(a)kent.ac.uk<mailto:s.j.thompson@kent.ac.uk> | M +44 7986 085754 | W www.cs.kent.ac.uk/~sjt<http://www.cs.kent.ac.uk/~sjt>

1 0

First and Only Call for Participation for IFL 2020 (Implementation and Application of Functional Languages)
by Jurriaan Hage 26 Aug '20

26 Aug '20

Hello, Please, find below the first and final call for participation for IFL 2020. Please forward these to anyone you think may be interested. Apologies for any duplicates you may receive. best regards, Jurriaan Hage Publicity Chair of IFL ======================================================= IFL 2020 32nd Symposium on Implementation and Application of Functional Languages Call for Participation venue: online 2nd - 4th September 2020 https://www.cs.kent.ac.uk/events/2020/ifl20/ ======================================================== ### Scope The goal of the IFL symposia is to bring together researchers actively engaged in the implementation and application of functional and function-based programming languages. IFL 2020 will be a venue for researchers to present and discuss new ideas and concepts, work in progress, and publication-ripe results related to the implementation and application of functional languages and function-based programming. ### Registration The symposium will be run via Zoom (zoom.us). If you can use Zoom, then you can participate. Please register for free via Eventbrite on the symposium webpage: https://www.cs.kent.ac.uk/events/2020/ifl20/ ### Programme Day 1: Wednesday, 2 September 12:45 Welcome 13:00 Nico Naus and Johan Jeuring: End-user feedback in multi-user workflow systems 13:30 Mart Lubbers, Haye Böhm, Pieter Koopman and Rinus Plasmeijer: Asynchronous Shared Data Sources 14:00 Pieter Koopman, Steffen Michels and Rinus Plasmeijer: Dynamic Editors for Well-Typed Expressions 14:30 Bas Lijnse and Rinus Plasmeijer: Asymmetric Composable Web Editors in iTasks 15:00 Social break 15:30 Sven-Olof Nyström: A subtyping system for Erlang 16:00 Andrew Marmaduke, Christopher Jenkins and Aaron Stump: Generic Zero-Cost Constructor Subtyping 16:30 Joris Burgers, Jurriaan Hage and Alejandro Serrano: Heuristics-based Type Error Diagnosis for Haskell - The case of GADTs and local reasoning 17:00 Social break 17:30 Kavon Farvardin and John Reppy: A New Backend for Standard ML of New Jersey 18:00 Chaitanya Koparkar, Mike Rainey, Michael Vollmer, Milind Kulkarni and Ryan R. Newton: A Compiler Approach Reconciling Parallelism and Dense Representations for Irregular Trees 18:30 Hans-Nikolai Vießmann and Sven-Bodo Scholz: Effective Host-GPU Memory Mangement Through Code Generation 20:00 Virtual Pub Day 2: Thursday, 3 September 10:00 Virtual Breakfast 13:00 Michal Gajda: Less Arbitrary waiting time 13:30 Sólrún Halla Einarsdóttir and Nicholas Smallbone: Template-based Theory Exploration: Discovering Properties of Functional Programs by Testing 14:00 Péter Bereczky, Dániel Horpácsi, Judit Kőszegi, Soma Szeier and Simon Thompson: Validating Formal Semantics by Comparative Testing 14:30 Social break 15:00 Gergo Erdi: An Adventure in Symbolic Execution 15:30 Joshua M. Schappel, Sachin Mahashabde and Marco T. Morazan: Using OO Design Patterns in a Functional Programming Setting 16:00 Filipe Varjão: Functional Programming and Interval Arithmetic with High Accuracy 16:30 Social break 17:00 Laith Sakka, Chaitanya Koparkar, Michael Vollmer, Vidush Singhal, Sam Tobin-Hochstadt, Ryan R. Newton and Milind Kulkarni: General Deforestation Using Fusion, Tupling and Intensive Redundancy Analysis 17:30 Benjamin Mourad and Matteo Cimini: A Declarative Gradualizer with Lang-n-Change 18:00 Maheen Riaz Contractor and Matthew Fluet: Type- and Control-Flow Directed Defunctionalization 19:30 Virtual Pub Day 3: Friday, 4 September 10:00 Virtual Breakfast 13:00 Michal Gajda: Towards a more perfect union type 13:30 Folkert de Vries, Sjaak Smetsers and Sven-Bodo Scholz: Container Unification for Uniqueness Types 14:00 Alejandro Díaz-Caro, Pablo E. Martínez López and Cristian Sottile: Polymorphic System I 14:30 Social break 15:00 Michal Gajda: Schema-driven mutation of datatype with multiple representations 15:30 Alexandre Garcia de Oliveira, Mauro Jaskelioff and Ana Cristina Vieira de Melo: On Structuring Pure Functional Programs with Monoidal Profunctors 16:00 Sara Moreira, Pedro Vasconcelos and Mário Florido: Resource Analysis for Lazy Evaluation with Polynomial Potential 16:30 Social break 17:00 Neil Mitchell, Moritz Kiefer, Pepe Iborra, Luke Lau, Zubin Duggal, Hannes Siebenhandl, Matthew Pickering and Alan Zimmerman: Building an Integrated Development Environment (IDE) on top of a Build System 17:30 Evan Sitt, Xiaotian Su, Beka Grdzelishvili, Zurab Tsinadze, Zongpu Xie, Hossameldin Abdin, Giorgi Botkoveli, Nikola Cenikj, Tringa Sylaj and Viktoria Zsok: Functional Programming Application for Digital Synthesis Implementation 18:00 Jocelyn Serot: HoCL: High level specification of dataflow graphs 19:30 Virtual Pub All times are in British Summer Time (BST), the local time in Canterbury, UK. So please translate these into your own time zone, using a service such as time and date.

1 0

doctest-extract
by Henning Thielemann 22 Aug '20

22 Aug '20

I have started an alternative implementation of 'doctest'. In contrast to the original one, doctest-extract extracts Haskell test-modules from doctest comments. This integrates better with Cabal and its package version resolution and the tests are compiled, not interpreted in GHCi. Disadvantage is that doctest-extract does not support all features of 'doctest', e.g. IO-tests. I uploaded a preview as package candidates to Hackage: $ cabal install $(for pkg in doctest-extract-0.0 doctest-lib-0.0 utility-ht-0.0.16 non-empty-0.3.3; do echo https://hackage.haskell.org/package/$pkg/candidate/$pkg.tar.gz; done) Extract test modules like so: $ doctest-extract -i src/ -o test/ --executable-main=Test/Main.hs --import-tested $$(cat test-module.list) There is still a problem: A failing QuickCheck test does not abort the whole test-suite. 'cabal test' will report success even if one QuickCheck property test fails. I wonder what is the proposed way to make a failing property fail the test-suite? I could use (QC.whenFail exitFailure). Is this the intended way?

4 8

ICFP tutorial on hardware design using BH (Bluespec Haskell)
by Rishiyur Nikhil 20 Aug '20

20 Aug '20

REMINDER: My tutorial "Designing Hardware Systems and Accelerators with Open-Source BH (Bluespec Haskell)" on Aug 23 at #ICFP2020 (online). Please pre-install tools; instructions in tutorial repo README: https://tinyurl.com/y29zxrow . ICFP web page: https://icfp20.sigplan.org . #RISCV #Bluespec #BSV #BH.

1 0