- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] Better writing about Haskell through multi-metaphor learning
by Olaf Klinke 21 Sep '21

21 Sep '21

> As noted a few times in this thread List takes multiple paths. The > "non-determinism" (something that not always explained well, since > taking all paths is still rather deterministic) extends the simple > pipeline model. In principle you could make the different paths race against each other and return the one that finishes (first). That would be proper non- determinism. List, Sequence, Tree and such are set-like monads, which I would put into the non-determinism corner. Years ago I was experimenting with decision-making and sequence alignment in particular. The hypothesis was that if you have a functional program that makes a decision on exact data, then lifting the program through a suitable monad M will give you a decision procedure for M-fuzzy inputs. For example, we managed to implement string matching for the ListT monad transformer, so you can match fuzzy strings against fuzzy strings. Here a full-text index (e.g. suffix tree) is itself a special kind of fuzzy string parametrized by the list monad. Decomposing it into head and tail takes you simultaneously to every position in the indexed text. Set-like monads do not fit the pipeline model well, it seems. By the way, I struggle with the pipeline metaphor. If a monad is a pipeline, what are the connectors? Is (m a) a piece of pipe and (>>) a connector? Or is (a -> m b) a piece of pipe and (>=>) a connector? In my Haskell exposition for mathematicians I chose the monad of formal linear combinations for introduction of monads. In this monad M, (M b) is a vector over basis b, (b1 -> M b2) describes a linear map (matrix) w.r.t. bases b1 and b2, (<=<) is matrix multiplication and (=<<) is matrix-vector multiplication. So if you like matrices, mentally replace (a -> m b) by "linear map" and (m a) by "vector". Olaf

1 0

Re: [Haskell-cafe] Cabal v3 public sub-libraries
by Mikolaj Konarski 21 Sep '21

21 Sep '21

Hi Daniel, > Should I try a candidate upload to hackage, or is the testing about something in hackage-server or cabal itself? I don't remember if candidates now display haddocks, but if they do, that's probably a good way to test the multilib haddocks. Otherwise, I guess, spin a private Hackage and test there. I looked closer and there is also some related work remaining to do in cabal https://github.com/haskell/cabal/issues/7669 and in haddock (polishing the multilib case and extending to backpack) https://github.com/haskell/haddock/issues/1363 but probably not a lot in hackage-server itself https://github.com/haskell/hackage-server/issues/924 https://github.com/haskell/hackage-server/issues/577 It may be useful to get in touch with the interested parties and comment in these issues or open new ones. Kind regards, Mikolaj On Tue, Sep 21, 2021 at 4:56 PM Daniel Winograd-Cort <dwincort(a)gmail.com> wrote: > > Hi Mikolaj, > > Thanks for the response! Do you have any tips on how I can go about testing? Should I try a candidate upload to hackage, or is the testing about something in hackage-server or cabal itself? > > Best, > Daniel > > On Mon, Sep 20, 2021 at 3:10 AM Mikolaj Konarski <mikolaj(a)well-typed.com> wrote: >> >> Hi Daniel, >> >> IIRC, the main, or the only remaining problem with public multi-libs >> is haddocks, and this set of haddock PRs paves the way and offers a >> manual workaround: https://github.com/haskell/haddock/pull/1419 >> >> Contributions and testing very welcome. >> >> Kind regards, >> Mikolaj >> >> On Sun, Sep 19, 2021 at 3:53 PM Daniel Winograd-Cort <dwincort(a)gmail.com> wrote: >> > >> > Hi cafe, >> > >> > I remember hearing about public sub-libraries in cabal v3, providing the ability to declare multiple libraries in the same cabal file that can be accessed (individually) by other packages. Does anyone know if this is supported on hackage, and if not, if there is a plan to allow this behavior on hackage? >> > >> > Thanks, >> > Daniel >> > >> > _______________________________________________ >> > Haskell-Cafe mailing list >> > To (un)subscribe, modify options or view archives go to: >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > Only members subscribed via the mailman list are allowed to post.

1 0

Optimising ReadP
by Andrew Kvapil 21 Sep '21

21 Sep '21

Hi, I'm trying to optimise a short Haskell program (inspired by Rust's performance). From simple profiling, I discovered that 90+% of time and allocations is spent in a `ReadP`-based parser. The parser is fairly small, I assumed GHC would inline/optimise most of it. I tried adding some `SPECIALISE` pragmas but found out those don't work: they require `INLINE`/`INLINEABLE` pragmas or compiling with `-O`. I'm confused by the latter requirement as I thought dependencies of the Stack project are compiled with optimisation enabled. I copied the entirety of the `ReadP` module into my project along with what I used from `Text.Read.Lex` to be able to optimise this code locally. I managed to get some speedups by specialising the integer parsers. Cloning the `ReadP` code also helped with more detailed profiling reports, I now know that the majority of time and allocations are spent in `>>=`. That's it for the long-winded intro, here are my questions: - what's the problem with GHC complaining about missing `INLINE(ABLE)` pragmas and/or `-O` in Stack dependencies? - Are these things just never inlined unless library authors specifically mark them as such? - What profiling tools do people usually use in situations like this? - I cannot specialise `>>=` even when I mark it `INLINEABLE` in the `Monad ReadP` instance, apparently, the pragma should be placed at the declaration site (at least that's what the warning says). So I run into the same issue with `INLINE(ABLE)`/`-O` as above. That seems pretty silly, I feel like I should be able to inline/specialise this particular instance and not worry about the global declaration of `>>=`. Is there a workaround for this? - I also used `BangPatterns` in my optimisations, but it's been hit-and-miss. They (surprisingly) helped in small, local definitions marked `INLINE` (I assumed strictness analysis would pick up on those), but in other places, such as `ReadP`'s `>>=`, strictness annotations slightly worsened performance. How do people look for good patterns to annotate as strict? - How do I find out to what extent is laziness slowing things down, or look for places with unintended thunks? As these are general optimisation questions, I'm not looking for parsing alternatives suggestions. I'd like to write high-level code and have it efficiently compose, this is a toy program anyway and I'm wondering how far can I get with such a simple parsing library. I suspect the majority of allocations coming from the parser are short-lived garbage that I should be able to avoid with optimisations and maybe a little bit of refactoring. One thing that's specific to my implementation is that the parser first produces a `[(Int, Int)]` and then converts that to `IntMap (Set Int)` with a `foldl'`. I would like to ensure the list is never built in the first place, is there a way to do that? As to the code itself, it's only 90 lines, but I'm not sure what the consensus is on attachments in this mailing list. I can provide the whole Stack project along with a test case and a reference solution in Rust upon request. (I'd post it on my GitHub, but there's a slight chance a participant in the competition this is a reference solution to may find it there.) Best regards, Andrew

1 0

Re: [Haskell-cafe] Better writing about Haskell through multi-metaphor learning
by Anthony Clayden 21 Sep '21

21 Sep '21

> Neither [degrees nor radians] is really wrong. Degrees are strange, ... That sounds like the pot calling the kettle black. 'Irrational' means ... errm ... strange. 'Transcendental' was the word Leibniz reached for when he realised he had something stranger than irrationals. > an artifact of the Babylonian system with no real mathematical significance. Hmm? An artefact of being approximately the number of days in a year (which is as true for us as the Babylonians), and a number which has many factors, so can happily measure quarter-turns, eighth turns (bracing to keep your right-angles upright), whole-number of degrees for internal angles of all the faces needed for the Platonic solids ... I would have thought there's a teachable moment there about prime numbers, factorisation, and for bringing fractions into a coherent continuum. It's not like ignorance of this alleged "mathematical significance" of radians prevented building Hanging Gardens or Pyramids, Stonehenge, the fractals of the Walls of Benin, Machu Picchu trapeziums or aqueducts or anything. (A bit like Category Theory, really.)

2 1

Re: [Haskell-cafe] Field types
by Anthony Clayden 20 Sep '21

20 Sep '21

Report section 4.2.1 "A `data` declaration may use the same field label in multiple constructors as long as the typing of the field is the same in all cases after type synonym expansion." > In that hypothetical context, the field name wouldn't be usable as a > function—at least without future Dependent Haskell. TRex manages to support same label different field type in different records. The record's type includes the field labels, as a distinct Kind. `#lab` is the syntax to access a field labelled `lab`. > #lab :: a\lab => Rec (lab :: b | a) -> b `(lab :: b | a)` is of Kind Row, means a row with label `lab` at type `b`; `| a` captures any other fields in the record; `Rec( )` is a magic type constructor that makes Rows into Kind `*`. Context `a\lab` means `a` must not include label `lab`. Hugs.Trex> let myTuplePair = (( lab = 5 :: Int, lab2 = True), (lab = 'c', lab3 = Just 7)) > in (#lab $ fst myTuplePair, #lab $ snd myTuplePair) > (5,'c') On Mon, Sep 20, 2021, 1:19 PM Tom Ellis <tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe>> wrote: >* On Mon, Sep 20, 2021 at 01:13:43PM -0400, David Feuer wrote: *>* > Does one field name for one datatype always refer to a field with the *>* same *>* > type? Or is there some wacky extension that would allow things like *>* > *>* > data Foo *>* > = Bar { zoom :: Int } *>* > | Baz { zoom :: Char } *>* > *>* > I'm hoping I don't have to worry about the latter possibility.... *>>* Me too! Under such circumstances what would the type of *>* field-as-function be?*

1 0

Field types
by David Feuer 20 Sep '21

20 Sep '21

Does one field name for one datatype always refer to a field with the same type? Or is there some wacky extension that would allow things like data Foo = Bar { zoom :: Int } | Baz { zoom :: Char } I'm hoping I don't have to worry about the latter possibility....

3 5

Cabal v3 public sub-libraries
by Daniel Winograd-Cort 20 Sep '21

20 Sep '21

Hi cafe, I remember hearing about public sub-libraries in cabal v3, providing the ability to declare multiple libraries in the same cabal file that can be accessed (individually) by other packages. Does anyone know if this is supported on hackage, and if not, if there is a plan to allow this behavior on hackage? Thanks, Daniel

2 1

Re: [Haskell-cafe] Haskell-Cafe Digest, Vol 217, Issue 16
by Michael Turner 20 Sep '21

20 Sep '21

"The seeds of your confusion are very evident from your message". The seeds of your unsubstantiated assumptions about me are very evident from yours. "You can't just 'translate' an algorithm from OOP to Haskell" Wow, I'm either "trying to translate Haskell to C++" (someone else, above) or trying to translate C++ to Haskell. I'm actually doing neither. I started by trying to understand this: https://www.stwing.upenn.edu/~wlovas/hudak/aug.pdf (And no, just because Haskell is great for writing little special-purpose programming languages does not automatically mean it's up to snuff for handling natural language.) I'd originally hoped to fully understand the rather short program in that paper (full code, in two versions, elsewhere on Paul Jones aca dite) by getting it to run again, then commenting the code as I began to understand it. And then, on to more important issues for a fuller Haskell implementation, issues described here https://www.aclweb.org/anthology/C94-2137.pdf and here http://www.lacus.org/volumes/23/22.sypniewski.pdf Both of which are references I dug up and supplied here https://en.wikipedia.org/wiki/Applicative_universal_grammar as I took the Wikipedia article from stub status to something less stubby -- it actually started in this state: https://en.wikipedia.org/w/index.php?title=Applicative_universal_grammar&di… The ASCII-art diagrams you see there are output from code that I've gotten working again. I learned about lazy evaluation in college, when I got interested in how Lisp might implement it. I'm very familiar with the arguments for purity, especially from learning Erlang some years ago (during which I wrote my share of accumulator-based tail-recursive functions.) I prefer static typing but hated the way C++ templates extended the concept, mostly because the syntax error messages were so bad for so long. My career includes a time in the late 80s when the kind of computing power we have in our phones now with multicore processors filled a box of hardware too heavy to lift. This was at a startup where the founder was substantially inspired by this stream-oriented single-assignment language: https://en.wikipedia.org/wiki/SISAL I started programming at 15. It's been a very rare year, even after leaving the software profession, when I didn't write at least some code, learning new things in the process. Which means I've been looking at programming languages and how to implement things at the most appropriate level of abstraction possible for just a few months shy of fifty years. The arguments here are following a familiar pattern, one I see in discussions of everything from programming to government policy. (1) I disagree with someone (2) This person instantly assumes I must be ignorant of what they know (3) They start Mansplaining It All To Me. This is particularly irksome when the person is actually considerably more ignorant of the subject than I am. I'm still ignorant of most of Haskell, to be sure. However, I'm not ignorant when it comes to writing. (Published articles on request.) A great deal of what's written about Haskell, usually with very good intentions, has proved useless to me. Have I had a stroke that leaves me apparently unharmed, but actually no longer able to absorb a different programming language? Was I always just too dumb to learn Haskell? Somehow, I think it's more related to the writing. To some extent the community seems to recognize there's a problem -- e.g., the Monad Tutorial Explosion. I finally got (most of?) what monads really mean for practical programming when none other than Simon Peyton-Jones said F# called a very similar construct "workflow," a word he likes. Wow, plain English instead of a mathematical abstraction that, in the math introductions, looks weirdly clunky to me, if anything, but, in any case, very hard to relate to writing better code. Lambda calculus? I have vague memories of Eugene Lawler https://en.wikipedia.org/wiki/Eugene_Lawler covering it when I took computing theory from him. And again, when I was grading computing theory homework for this required course for graduate students (for their prelim exams) for Richard Lipton https://en.wikipedia.org/wiki/Richard_Lipton in the fall term of 1980 at U.C. Berkeley. It's not that I'm too stupid to learn lambda calculus. It's that I seriously doubt that refreshing my memory on the details is going to add significantly more to my grasp of functional programming in Haskell. I disagree with some people here. They jump to the conclusion that I'm some ignorant moron. They also keep trying to sell Haskell as something dramatically, fundamentally -- nay transcendentally! -- different from anything I've ever known. Are you doing that? Stop. Just stop. Haskell's big problem right now is adoption. And I'm telling you why adoption has been hard for me. You lecture back, telling me things I already know, making sweeping assumptions about me. When you do that, you're not part of the solution to Haskell's biggest problem right now. You're part of the problem. Regards, Michael Turner Executive Director Project Persephone 1-25-33 Takadanobaba Shinjuku-ku Tokyo 169-0075 Mobile: +81 (90) 5203-8682 turner(a)projectpersephone.org Understand - http://www.projectpersephone.org/ Join - http://www.facebook.com/groups/ProjectPersephone/ Donate - http://www.patreon.com/ProjectPersephone Volunteer - https://github.com/ProjectPersephone "Love does not consist in gazing at each other, but in looking outward together in the same direction." -- Antoine de Saint-Exupéry On Fri, Sep 17, 2021 at 4:19 AM <haskell-cafe-request(a)haskell.org> wrote: > > Send Haskell-Cafe mailing list submissions to > haskell-cafe(a)haskell.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > or, via email, send a message with subject or body 'help' to > haskell-cafe-request(a)haskell.org > > You can reach the person managing the list at > haskell-cafe-owner(a)haskell.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Haskell-Cafe digest..." > > > Today's Topics: > > 1. Re: Haskell's "historical futurism" needs better writing, not > better tools (Richard Eisenberg) > 2. Re: Haskell's "historical futurism" needs better writing, not > better tools (Jeffrey Brown) > 3. Re: Haskell's "historical futurism" needs better writing, not > better tools (Gregory Guthrie) > 4. Re: Bundle patterns with type aliases (Carter Schonwald) > 5. Re: Bundle patterns with type aliases (David Feuer) > 6. Re: Bundle patterns with type aliases (David Feuer) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 16 Sep 2021 14:05:19 +0000 > From: Richard Eisenberg <lists(a)richarde.dev> > To: Anthony Clayden <anthony.d.clayden(a)gmail.com> > Cc: haskell-cafe(a)haskell.org > Subject: Re: [Haskell-cafe] Haskell's "historical futurism" needs > better writing, not better tools > Message-ID: > <010f017beeed148e-35512a1d-0412-45c5-b1ac-ca532fa70f72-000000(a)us-east-2.amazonses.com> > > Content-Type: text/plain; charset="utf-8" > > I just want to pipe up and say I'm not comfortable with this response. When I feel this way about writing on a forum, I normally contact the author in private, but I think posting publicly here has its merits. I'm hoping that the long correspondence AntC and I have had -- often with opposing viewpoints but with mutual respect -- with withstand this email. > > Michael posted here expressing frustration with his experience learning and using Haskell. In my opinion, he has spent too much time reading older papers, written by experts for experts -- which Michael is not. I do not fault Michael for this: these resources are sometimes what appear when searching, and we as a community have done a poor job marshaling our educational resources. (Michael, I just thought of a resource you might find useful: http://dev.stephendiehl.com/hask/ is an oft-linked resource attempting to do that marshaling. I am not vouching for it here, per se, but I know others have found it useful.) > > However, Michael very specifically said that "just learn lambda-calculus" was not helpful for him, and so I think it's unhelpful for someone to respond with "just learn lambda-calculus". There are a number of other statements in the email below which could be seen as belittling -- also not helpful. > > Instead, I wish that we, as a community, could take posts like Michael's at face value: this is the experience of someone who wants to learn Haskell. While some of the conclusions stated in that post are misunderstandings, it is not the sole fault of the learner for these misunderstandings: instead, we must try to understand what about our community and posted materials induced these misunderstandings, and then seek to improve. Many people in Michael's situation may not have posted at all -- and so this kind of information can be very hard to get. > > Michael, I have no silver bullet to offer to you to try to help you here. I do tend to agree with AntC that you have developed some misconceptions that are hindering your continued learning. The terminology actively hurts here. (To be fair, the first Haskell standard pre-dates both Java and C++, and so one could argue who got the terms wrong.) For my part, I am trying to help with this situation both by trying to improve error messages, and though my support of the Haskell Foundation's Haskell School initiative (https://github.com/haskellfoundation/HaskellSchool) These will take time to grow, but my hope is that a future person like you will have an easier route in. > > In the meantime, I implore us to take all expressed experiences as exactly that: the experience of the person writing. And if they say they don't want X, please let's not feed them X. :) > > Richard > > > On Sep 16, 2021, at 12:53 AM, Anthony Clayden <anthony.d.clayden(a)gmail.com> wrote: > > > > Hi Michael, oh dear, oh dear, oh dear. > > > > The seeds of your confusion are very evident from your message. How to back you out of whatever deep rabbit-hole you've managed to get your head into? > > > > > ... Your average reader (already a programmer) would be better served by a comparative approach: Here's how to say something in a couple of other programming languages, here's how to say something roughly equivalent in Haskell -- BUT, here's how it's subtly different in Haskell. > > > > No. Just no. Haskell is not "subtly different" to (say) Java in the way that C++ or C# are different. (I'll leave others to judge how subtly different they are.) > > > > Haskell is dramatically and fundamentally different. You can't just 'translate' an algorithm from OOP to Haskell. Many newbies try, and there's many tales of woe on StackOverflow. Just No. > > > > I really don't know how you could have got any experience with Haskell and say "subtly". > > > > I suggest you unlearn everything you think you know about Haskell, and strike out in an entirely different direction. The best approach would be to spend a few days playing with lambda calculus. (That's what I did before tackling Haskell.) > > > > > (I've actually been curtly informed on the beginners' list -- yes, the beginner' list! -- that my problems of comprehension can be solved simply: "Learn lambda calculus.") > > > > Lambda calculus is an excellent place for beginners to start. What could be easier to learn? It's certainly easier than grokking a Turing machine; and much easier than Haskell: less than a handful of primitives yet can compute anything computable. > > > > > And since the concepts are seldom described in concrete enough and time-honored programming language terms (by comparison to other programming languages) > > > > I'm guessing that the concepts you're talking of simply don't correspond to anything in time-honoured (procedural) programming. Anybody writing about Haskell (including anybody writing the User Guide) assumes a base level of understanding of Haskell. You've clearly veered off the track and haven't yet reached base. Remember the User Guide builds on top of the Language Report. > > > > (On the point of 'time-honoured': lambda calculus is almost exactly the same age as Turing machines. The first well-known programming language using lambda-calculus ideas (LISP 1966) is almost exactly the same age as the first OOP language (Simula 1967). Which is the more time-honoured?) > > > > You do have a point that the terminology in Haskell is often mysterious > > > > > [SPJ said] F# had settled on the term "workflow" instead of "monad", and he felt this was wise. > > > > Yes many have yearned for a more warm-and-cuddly term than "monad". But the terminology barrier starts before that. > > > > Haskell typeclasses are not 'classes' in any sense recognisable from OOP. There are no objects, no hidden state, no destructive assignment. We might go back to February 1988 when a strawman for what became typeclasses used OVERLOAD/INSTANCE. > > > > AntC > > > > > > > > > > _______________________________________________ > > 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. > >

13 20

Re: [Haskell-cafe] Pattern synonyms and explicit forall.
by Anthony Clayden 19 Sep '21

19 Sep '21

Thank you Kai-Oliver. > pattern Any2 :: forall . forall a. a -> Some We're friends here. I think I can share that my reaction was a rather loud WTF??!!?? And there's not a mention in the docos that this is even a thing. I feel like dragging whoever's responsible to the headmaster's office. Ok that seems to work -- in the sense that pattern-matching on it yields an `x` that's unusable on RHS just as much as the `Any` decl with implicit `forall`, or with no type signature at all. What would be useful is to be able to introduce a constraint into the sig, so I can do something like > foo (Any2 x) y = x == y After playing with it, all I'm getting is weird rejections. > pattern Any2 :: forall . forall a. () => (Eq a) => a -> Some > * Pattern synonym `Any2' has one argument > but its type signature has 1 fewer arrows I need to put the constraints inside the scope of the `forall a.`. A single `(Show a) => a -> Some` complains no instance provided.

5 4

Shrink function names
by Caeeh 19 Sep '21

19 Sep '21

4 8