<div dir="ltr"><div dir="ltr">> Haskell's big problem right now is adoption. </div><div><br></div><div>I'm not quite sure this is a problem. Haskell and its libraries are designed around math concepts, as opposed to CS concepts (semigroup vs IConcatenable). Learning it all but requires learning some algebra as well, thus a lower adoption rate is expected. <br></div><div><br></div><div>Personally, I consider this math requirement a great educational benefit: raising the level of abstraction from "container" to "monoid" helps to make better design decisions. It may be an obstacle for someone who wants quickly put together a new product, but this is the wrong tool selected for a job. A book like "Category theory for programmers" (that exists) and "Algebra for programmers" (that I don't know about) may help with learning and provide practical examples, but explaining math without using math words sounds like a futile attempt.</div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 17, 2021 at 12:58 AM Michael Turner <<a href="mailto:michael.eugene.turner@gmail.com">michael.eugene.turner@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">"The seeds of your confusion are very evident from your message".<br>
<br>
The seeds of your unsubstantiated assumptions about me are very<br>
evident from yours.<br>
<br>
"You can't just 'translate' an algorithm from OOP to Haskell"<br>
<br>
Wow, I'm either "trying to translate Haskell to C++" (someone else,<br>
above) or trying to translate C++ to Haskell.<br>
<br>
I'm actually doing neither. I started by trying to understand this:<br>
<br>
<a href="https://www.stwing.upenn.edu/~wlovas/hudak/aug.pdf" rel="noreferrer" target="_blank">https://www.stwing.upenn.edu/~wlovas/hudak/aug.pdf</a><br>
<br>
(And no, just because Haskell is great for writing little<br>
special-purpose programming languages does not automatically mean it's<br>
up to snuff for handling natural language.)<br>
<br>
I'd originally hoped to fully understand the rather short program in<br>
that paper (full code, in two versions, elsewhere on Paul Jones aca<br>
dite) by getting it to run again, then commenting the code as I began<br>
to understand it. And then, on to more important issues for a fuller<br>
Haskell implementation, issues described here<br>
<br>
<a href="https://www.aclweb.org/anthology/C94-2137.pdf" rel="noreferrer" target="_blank">https://www.aclweb.org/anthology/C94-2137.pdf</a><br>
<br>
and here<br>
<br>
<a href="http://www.lacus.org/volumes/23/22.sypniewski.pdf" rel="noreferrer" target="_blank">http://www.lacus.org/volumes/23/22.sypniewski.pdf</a><br>
<br>
Both of which are references I dug up and supplied here<br>
<br>
<a href="https://en.wikipedia.org/wiki/Applicative_universal_grammar" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Applicative_universal_grammar</a><br>
<br>
as I took the Wikipedia article from stub status to something less<br>
stubby -- it actually started in this state:<br>
<br>
<a href="https://en.wikipedia.org/w/index.php?title=Applicative_universal_grammar&diff=prev&oldid=1020447173" rel="noreferrer" target="_blank">https://en.wikipedia.org/w/index.php?title=Applicative_universal_grammar&diff=prev&oldid=1020447173</a><br>
<br>
The ASCII-art diagrams you see there are output from code that I've<br>
gotten working again.<br>
<br>
I learned about lazy evaluation in college, when I got interested in<br>
how Lisp might implement it. I'm very familiar with the arguments for<br>
purity, especially from learning Erlang some years ago (during which I<br>
wrote my share of accumulator-based tail-recursive functions.) I<br>
prefer static typing but hated the way C++ templates extended the<br>
concept, mostly because the syntax error messages were so bad for so<br>
long. My career includes a time in the late 80s when the kind of<br>
computing power we have in our phones now with multicore processors<br>
filled a box of hardware too heavy to lift. This was at a startup<br>
where the founder was substantially inspired by this stream-oriented<br>
single-assignment language:<br>
<br>
<a href="https://en.wikipedia.org/wiki/SISAL" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/SISAL</a><br>
<br>
I started programming at 15. It's been a very rare year, even after<br>
leaving the software profession, when I didn't write at least some<br>
code, learning new things in the process. Which means I've been<br>
looking at programming languages and how to implement things at the<br>
most appropriate level of abstraction possible for just a few months<br>
shy of fifty years.<br>
<br>
The arguments here are following a familiar pattern, one I see in<br>
discussions of everything from programming to government policy.<br>
<br>
(1) I disagree with someone<br>
(2) This person instantly assumes I must be ignorant of what they know<br>
(3) They start Mansplaining It All To Me.<br>
<br>
This is particularly irksome when the person is actually considerably<br>
more ignorant of the subject than I am.<br>
<br>
I'm still ignorant of most of Haskell, to be sure. However, I'm not<br>
ignorant when it comes to writing. (Published articles on request.) A<br>
great deal of what's written about Haskell, usually with very good<br>
intentions, has proved useless to me. Have I had a stroke that leaves<br>
me apparently unharmed, but actually no longer able to absorb a<br>
different programming language? Was I always just too dumb to learn<br>
Haskell? Somehow, I think it's more related to the writing.<br>
<br>
To some extent the community seems to recognize there's a problem --<br>
e.g., the Monad Tutorial Explosion. I finally got (most of?) what<br>
monads really mean for practical programming when none other than<br>
Simon Peyton-Jones said F# called a very similar construct "workflow,"<br>
a word he likes. Wow, plain English instead of a mathematical<br>
abstraction that, in the math introductions, looks weirdly clunky to<br>
me, if anything, but, in any case, very hard to relate to writing<br>
better code.<br>
<br>
Lambda calculus? I have vague memories of Eugene Lawler<br>
<br>
<a href="https://en.wikipedia.org/wiki/Eugene_Lawler" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Eugene_Lawler</a><br>
<br>
covering it when I took computing theory from him. And again, when I<br>
was grading computing theory homework for this required course for<br>
graduate students (for their prelim exams) for Richard Lipton<br>
<br>
<a href="https://en.wikipedia.org/wiki/Richard_Lipton" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Richard_Lipton</a><br>
<br>
in the fall term of 1980 at U.C. Berkeley.<br>
<br>
It's not that I'm too stupid to learn lambda calculus. It's that I<br>
seriously doubt that refreshing my memory on the details is going to<br>
add significantly more to my grasp of functional programming in<br>
Haskell.<br>
<br>
I disagree with some people here. They jump to the conclusion that I'm<br>
some ignorant moron. They also keep trying to sell Haskell as<br>
something dramatically, fundamentally -- nay transcendentally! --<br>
different from anything I've ever known.<br>
<br>
Are you doing that? Stop. Just stop. Haskell's big problem right now<br>
is adoption. And I'm telling you why adoption has been hard for me.<br>
You lecture back, telling me things I already know, making sweeping<br>
assumptions about me. When you do that, you're not part of the<br>
solution to Haskell's biggest problem right now. You're part of the<br>
problem.<br>
<br>
Regards,<br>
Michael Turner<br>
Executive Director<br>
Project Persephone<br>
1-25-33 Takadanobaba<br>
Shinjuku-ku Tokyo 169-0075<br>
Mobile: +81 (90) 5203-8682<br>
<a href="mailto:turner@projectpersephone.org" target="_blank">turner@projectpersephone.org</a><br>
<br>
Understand - <a href="http://www.projectpersephone.org/" rel="noreferrer" target="_blank">http://www.projectpersephone.org/</a><br>
Join - <a href="http://www.facebook.com/groups/ProjectPersephone/" rel="noreferrer" target="_blank">http://www.facebook.com/groups/ProjectPersephone/</a><br>
Donate - <a href="http://www.patreon.com/ProjectPersephone" rel="noreferrer" target="_blank">http://www.patreon.com/ProjectPersephone</a><br>
Volunteer - <a href="https://github.com/ProjectPersephone" rel="noreferrer" target="_blank">https://github.com/ProjectPersephone</a><br>
<br>
"Love does not consist in gazing at each other, but in looking outward<br>
together in the same direction." -- Antoine de Saint-Exupéry<br>
<br>
On Fri, Sep 17, 2021 at 4:19 AM <<a href="mailto:haskell-cafe-request@haskell.org" target="_blank">haskell-cafe-request@haskell.org</a>> wrote:<br>
><br>
> Send Haskell-Cafe mailing list submissions to<br>
> <a href="mailto:haskell-cafe@haskell.org" target="_blank">haskell-cafe@haskell.org</a><br>
><br>
> To subscribe or unsubscribe via the World Wide Web, visit<br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
> or, via email, send a message with subject or body 'help' to<br>
> <a href="mailto:haskell-cafe-request@haskell.org" target="_blank">haskell-cafe-request@haskell.org</a><br>
><br>
> You can reach the person managing the list at<br>
> <a href="mailto:haskell-cafe-owner@haskell.org" target="_blank">haskell-cafe-owner@haskell.org</a><br>
><br>
> When replying, please edit your Subject line so it is more specific<br>
> than "Re: Contents of Haskell-Cafe digest..."<br>
><br>
><br>
> Today's Topics:<br>
><br>
> 1. Re: Haskell's "historical futurism" needs better writing, not<br>
> better tools (Richard Eisenberg)<br>
> 2. Re: Haskell's "historical futurism" needs better writing, not<br>
> better tools (Jeffrey Brown)<br>
> 3. Re: Haskell's "historical futurism" needs better writing, not<br>
> better tools (Gregory Guthrie)<br>
> 4. Re: Bundle patterns with type aliases (Carter Schonwald)<br>
> 5. Re: Bundle patterns with type aliases (David Feuer)<br>
> 6. Re: Bundle patterns with type aliases (David Feuer)<br>
><br>
><br>
> ----------------------------------------------------------------------<br>
><br>
> Message: 1<br>
> Date: Thu, 16 Sep 2021 14:05:19 +0000<br>
> From: Richard Eisenberg <<a href="mailto:lists@richarde.dev" target="_blank">lists@richarde.dev</a>><br>
> To: Anthony Clayden <<a href="mailto:anthony.d.clayden@gmail.com" target="_blank">anthony.d.clayden@gmail.com</a>><br>
> Cc: <a href="mailto:haskell-cafe@haskell.org" target="_blank">haskell-cafe@haskell.org</a><br>
> Subject: Re: [Haskell-cafe] Haskell's "historical futurism" needs<br>
> better writing, not better tools<br>
> Message-ID:<br>
> <<a href="mailto:010f017beeed148e-35512a1d-0412-45c5-b1ac-ca532fa70f72-000000@us-east-2.amazonses.com" target="_blank">010f017beeed148e-35512a1d-0412-45c5-b1ac-ca532fa70f72-000000@us-east-2.amazonses.com</a>><br>
><br>
> Content-Type: text/plain; charset="utf-8"<br>
><br>
> 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.<br>
><br>
> 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: <a href="http://dev.stephendiehl.com/hask/" rel="noreferrer" target="_blank">http://dev.stephendiehl.com/hask/</a> 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.)<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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 (<a href="https://github.com/haskellfoundation/HaskellSchool" rel="noreferrer" target="_blank">https://github.com/haskellfoundation/HaskellSchool</a>). These will take time to grow, but my hope is that a future person like you will have an easier route in.<br>
><br>
> 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. :)<br>
><br>
> Richard<br>
><br>
> > On Sep 16, 2021, at 12:53 AM, Anthony Clayden <<a href="mailto:anthony.d.clayden@gmail.com" target="_blank">anthony.d.clayden@gmail.com</a>> wrote:<br>
> ><br>
> > Hi Michael, oh dear, oh dear, oh dear.<br>
> ><br>
> > 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?<br>
> ><br>
> > > ... 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.<br>
> ><br>
> > 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.)<br>
> ><br>
> > 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.<br>
> ><br>
> > I really don't know how you could have got any experience with Haskell and say "subtly".<br>
> ><br>
> > 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.)<br>
> ><br>
> > > (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.")<br>
> ><br>
> > 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.<br>
> ><br>
> > > And since the concepts are seldom described in concrete enough and time-honored programming language terms (by comparison to other programming languages)<br>
> ><br>
> > 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.<br>
> ><br>
> > (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?)<br>
> ><br>
> > You do have a point that the terminology in Haskell is often mysterious<br>
> ><br>
> > > [SPJ said] F# had settled on the term "workflow" instead of "monad", and he felt this was wise.<br>
> ><br>
> > Yes many have yearned for a more warm-and-cuddly term than "monad". But the terminology barrier starts before that.<br>
> ><br>
> > 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.<br>
> ><br>
> > AntC<br>
> ><br>
> ><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > Haskell-Cafe mailing list<br>
> > To (un)subscribe, modify options or view archives go to:<br>
> > <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
> > Only members subscribed via the mailman list are allowed to post.<br>
><br>
> -------------- next part --------------<br>
> An HTML attachment was scrubbed...<br>
> URL: <<a href="http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210916/08935eb4/attachment-0001.html" rel="noreferrer" target="_blank">http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210916/08935eb4/attachment-0001.html</a>><br>
><br>
> ------------------------------<br>
><br>
> Message: 2<br>
> Date: Thu, 16 Sep 2021 09:34:09 -0500<br>
> From: Jeffrey Brown <<a href="mailto:jeffbrown.the@gmail.com" target="_blank">jeffbrown.the@gmail.com</a>><br>
> To: Richard Eisenberg <<a href="mailto:lists@richarde.dev" target="_blank">lists@richarde.dev</a>><br>
> Cc: haskell-cafe <<a href="mailto:haskell-cafe@haskell.org" target="_blank">haskell-cafe@haskell.org</a>>, Anthony Clayden<br>
> <<a href="mailto:anthony.d.clayden@gmail.com" target="_blank">anthony.d.clayden@gmail.com</a>><br>
> Subject: Re: [Haskell-cafe] Haskell's "historical futurism" needs<br>
> better writing, not better tools<br>
> Message-ID:<br>
> <CAEc4Ma0aNJuP8AMPvTRqyzQ=<a href="mailto:0dJT_M_WQc9Kqb8JyvdPf9ncPw@mail.gmail.com" target="_blank">0dJT_M_WQc9Kqb8JyvdPf9ncPw@mail.gmail.com</a>><br>
> Content-Type: text/plain; charset="utf-8"<br>
><br>
> I strongly believe the best study strategy is to be unfaithful to any<br>
> source or subtopic. When I want to learn something, I study whatever aspect<br>
> of it holds my interest, for only slightly longer than it continues to do<br>
> so. If I continue to want to learn a topic, but lose interest in a<br>
> particular source or subtopic, it's important to stop that particular<br>
> avenue. Otherwise I'll lose motivation for the topic as a whole.<br>
><br>
> The result is that, while I never learn (say) a language completely, I<br>
> generally learn enough to do whatever I was trying to do. (Sometimes I<br>
> learn enough to decide it's too hard -- and for cases in which that's bound<br>
> to happen, the quicker the better.)<br>
><br>
> Almost nobody learns any language completely anyway, and most of those<br>
> who do could have used their time better. Sacrifice is a superpower.<br>
><br>
> On Thu, Sep 16, 2021 at 9:09 AM Richard Eisenberg <<a href="mailto:lists@richarde.dev" target="_blank">lists@richarde.dev</a>><br>
> wrote:<br>
><br>
> > I just want to pipe up and say I'm not comfortable with this response.<br>
> > When I feel this way about writing on a forum, I normally contact the<br>
> > author in private, but I think posting publicly here has its merits. I'm<br>
> > hoping that the long correspondence AntC and I have had -- often with<br>
> > opposing viewpoints but with mutual respect -- with withstand this email.<br>
> ><br>
> > Michael posted here expressing frustration with his experience learning<br>
> > and using Haskell. In my opinion, he has spent too much time reading older<br>
> > papers, written by experts for experts -- which Michael is not. I do not<br>
> > fault Michael for this: these resources are sometimes what appear when<br>
> > searching, and we as a community have done a poor job marshaling our<br>
> > educational resources. (Michael, I just thought of a resource you might<br>
> > find useful: <a href="http://dev.stephendiehl.com/hask/" rel="noreferrer" target="_blank">http://dev.stephendiehl.com/hask/</a> is an oft-linked resource<br>
> > attempting to do that marshaling. I am not vouching for it here, per se,<br>
> > but I know others have found it useful.)<br>
> ><br>
> > However, Michael very specifically said that "just learn lambda-calculus"<br>
> > was not helpful for him, and so I think it's unhelpful for someone to<br>
> > respond with "just learn lambda-calculus". There are a number of other<br>
> > statements in the email below which could be seen as belittling -- also not<br>
> > helpful.<br>
> ><br>
> > Instead, I wish that we, as a community, could take posts like Michael's<br>
> > at face value: this is the experience of someone who wants to learn<br>
> > Haskell. While some of the conclusions stated in that post are<br>
> > misunderstandings, it is not the sole fault of the learner for these<br>
> > misunderstandings: instead, we must try to understand what about our<br>
> > community and posted materials induced these misunderstandings, and then<br>
> > seek to improve. Many people in Michael's situation may not have posted at<br>
> > all -- and so this kind of information can be very hard to get.<br>
> ><br>
> > Michael, I have no silver bullet to offer to you to try to help you here.<br>
> > I do tend to agree with AntC that you have developed some misconceptions<br>
> > that are hindering your continued learning. The terminology actively hurts<br>
> > here. (To be fair, the first Haskell standard pre-dates both Java and C++,<br>
> > and so one could argue who got the terms wrong.) For my part, I am trying<br>
> > to help with this situation both by trying to improve error messages, and<br>
> > though my support of the Haskell Foundation's Haskell School initiative (<br>
> > <a href="https://github.com/haskellfoundation/HaskellSchool" rel="noreferrer" target="_blank">https://github.com/haskellfoundation/HaskellSchool</a>). These will take time<br>
> > to grow, but my hope is that a future person like you will have an easier<br>
> > route in.<br>
> ><br>
> > In the meantime, I implore us to take all expressed experiences as exactly<br>
> > that: the experience of the person writing. And if they say they don't want<br>
> > X, please let's not feed them X. :)<br>
> ><br>
> > Richard<br>
> ><br>
> > On Sep 16, 2021, at 12:53 AM, Anthony Clayden <<a href="mailto:anthony.d.clayden@gmail.com" target="_blank">anthony.d.clayden@gmail.com</a>><br>
> > wrote:<br>
> ><br>
> > Hi Michael, oh dear, oh dear, oh dear.<br>
> ><br>
> > The seeds of your confusion are very evident from your message. How to<br>
> > back you out of whatever deep rabbit-hole you've managed to get your head<br>
> > into?<br>
> ><br>
> > > ... Your average reader (already a programmer) would be better served<br>
> > by a comparative approach: Here's how to say something in a couple of<br>
> > other programming languages, here's how to say something roughly<br>
> > equivalent in Haskell -- BUT, here's how it's subtly different in Haskell.<br>
> ><br>
> > No. Just no. Haskell is not "subtly different" to (say) Java in the way<br>
> > that C++ or C# are different. (I'll leave others to judge how subtly<br>
> > different they are.)<br>
> ><br>
> > Haskell is dramatically and fundamentally different. You can't just<br>
> > 'translate' an algorithm from OOP to Haskell. Many newbies try, and there's<br>
> > many tales of woe on StackOverflow. Just No.<br>
> ><br>
> > I really don't know how you could have got any experience with Haskell and<br>
> > say "subtly".<br>
> ><br>
> > I suggest you unlearn everything you think you know about Haskell, and<br>
> > strike out in an entirely different direction. The best approach would be<br>
> > to spend a few days playing with lambda calculus. (That's what I did before<br>
> > tackling Haskell.)<br>
> ><br>
> > > (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.")<br>
> ><br>
> ><br>
> > Lambda calculus is an excellent place for beginners to start. What could<br>
> > be easier to learn? It's certainly easier than grokking a Turing machine;<br>
> > and much easier than Haskell: less than a handful of primitives yet can<br>
> > compute anything computable.<br>
> ><br>
> > > And since the concepts are seldom described in concrete enough and<br>
> > time-honored programming language terms (by comparison to other<br>
> > programming languages)<br>
> ><br>
> > I'm guessing that the concepts you're talking of simply don't correspond<br>
> > to anything in time-honoured (procedural) programming. Anybody writing<br>
> > about Haskell (including anybody writing the User Guide) assumes a base<br>
> > level of understanding of Haskell. You've clearly veered off the track and<br>
> > haven't yet reached base. Remember the User Guide builds on top of the<br>
> > Language Report.<br>
> ><br>
> > (On the point of 'time-honoured': lambda calculus is almost exactly the<br>
> > same age as Turing machines. The first well-known programming language<br>
> > using lambda-calculus ideas (LISP 1966) is almost exactly the same age as<br>
> > the first OOP language (Simula 1967). Which is the more time-honoured?)<br>
> ><br>
> > You do have a point that the terminology in Haskell is often mysterious<br>
> ><br>
> > > [SPJ said] F# had settled on the term "workflow" instead of "monad", and<br>
> > he felt this was wise.<br>
> ><br>
> > Yes many have yearned for a more warm-and-cuddly term than "monad". But<br>
> > the terminology barrier starts before that.<br>
> ><br>
> > Haskell typeclasses are not 'classes' in any sense recognisable from OOP.<br>
> > There are no objects, no hidden state, no destructive assignment. We might<br>
> > go back to February 1988 when a strawman for what became typeclasses used<br>
> > OVERLOAD/INSTANCE.<br>
> ><br>
> > AntC<br>
> ><br>
> ><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > Haskell-Cafe mailing list<br>
> > To (un)subscribe, modify options or view archives go to:<br>
> > <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
> > Only members subscribed via the mailman list are allowed to post.<br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > Haskell-Cafe mailing list<br>
> > To (un)subscribe, modify options or view archives go to:<br>
> > <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
> > Only members subscribed via the mailman list are allowed to post.<br>
><br>
><br>
><br>
> --<br>
> Jeff Brown | Jeffrey Benjamin Brown<br>
> LinkedIn <<a href="https://www.linkedin.com/in/jeffreybenjaminbrown" rel="noreferrer" target="_blank">https://www.linkedin.com/in/jeffreybenjaminbrown</a>> | Github<br>
> <<a href="https://github.com/jeffreybenjaminbrown" rel="noreferrer" target="_blank">https://github.com/jeffreybenjaminbrown</a>> | Twitter<br>
> <<a href="https://twitter.com/carelogic" rel="noreferrer" target="_blank">https://twitter.com/carelogic</a>> | Facebook<br>
> <<a href="https://www.facebook.com/mejeff.younotjeff" rel="noreferrer" target="_blank">https://www.facebook.com/mejeff.younotjeff</a>> | very old Website<br>
> <<a href="https://msu.edu/~brown202/" rel="noreferrer" target="_blank">https://msu.edu/~brown202/</a>><br>
> -------------- next part --------------<br>
> An HTML attachment was scrubbed...<br>
> URL: <<a href="http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210916/e6a8f29b/attachment-0001.html" rel="noreferrer" target="_blank">http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210916/e6a8f29b/attachment-0001.html</a>><br>
><br>
> ------------------------------<br>
><br>
> Message: 3<br>
> Date: Thu, 16 Sep 2021 15:28:16 +0000<br>
> From: Gregory Guthrie <<a href="mailto:guthrie@miu.edu" target="_blank">guthrie@miu.edu</a>><br>
> To: Richard Eisenberg <<a href="mailto:lists@richarde.dev" target="_blank">lists@richarde.dev</a>>, Anthony Clayden<br>
> <<a href="mailto:anthony.d.clayden@gmail.com" target="_blank">anthony.d.clayden@gmail.com</a>><br>
> Cc: "<a href="mailto:haskell-cafe@haskell.org" target="_blank">haskell-cafe@haskell.org</a>" <<a href="mailto:haskell-cafe@haskell.org" target="_blank">haskell-cafe@haskell.org</a>><br>
> Subject: Re: [Haskell-cafe] Haskell's "historical futurism" needs<br>
> better writing, not better tools<br>
> Message-ID:<br>
> <<a href="mailto:DM6PR03MB4331EDE1A046D25E7209B90FA1DC9@DM6PR03MB4331.namprd03.prod.outlook.com" target="_blank">DM6PR03MB4331EDE1A046D25E7209B90FA1DC9@DM6PR03MB4331.namprd03.prod.outlook.com</a>><br>
><br>
> Content-Type: text/plain; charset="utf-8"<br>
><br>
> Educational research and learning theory shows that learning anything new is more effective and longer retained when it is connected to and builds on prior knowledge.<br>
><br>
> People may understand anything new if presented as a completely new set of ideas or principles, but that knowledge is not persistent or long remembered.<br>
><br>
> I personally find Haskell a good example of this. When teaching it one can show incrementally how it is the same in many ways as procedural programming languages. Then how it improves on them with first-class functions, currying, immutability, type abstractions, etc. These are all important ideas that they will also see in other IP languages, just much cleaner and more integrated in Haskell(!).<br>
><br>
> Basic Haskell programs with these features can then be used as a bisis for both appreciating the language features and design and FP in general, and as a stepping stone to more advanced usages.<br>
><br>
> Then introducing Functors, Monads, .... Are again an easy and well motivated step for improving on their existing IP experience, and show both nice abstractions and ideas, and a nice implementation and results.<br>
><br>
> All of this connects to and builds on what they already know.<br>
><br>
> Moving into all of the fancier type system features and pragmas, one enters into a realm where Haskell programs are no longer simple enough to easily read as they incorporate several levels of new abstractions and syntax.<br>
><br>
> But at least students have a good basis for further exploration, and an appreciation of FP and Haskell. :-)<br>
><br>
><br>
><br>
> From: Haskell-Cafe <<a href="mailto:haskell-cafe-bounces@haskell.org" target="_blank">haskell-cafe-bounces@haskell.org</a>> On Behalf Of Richard Eisenberg<br>
> Sent: Thursday, September 16, 2021 10:05 AM<br>
> To: Anthony Clayden <<a href="mailto:anthony.d.clayden@gmail.com" target="_blank">anthony.d.clayden@gmail.com</a>><br>
> Cc: <a href="mailto:haskell-cafe@haskell.org" target="_blank">haskell-cafe@haskell.org</a><br>
> Subject: Re: [Haskell-cafe] Haskell's "historical futurism" needs better writing, not better tools<br>
><br>
> 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.<br>
><br>
> 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: <a href="http://dev.stephendiehl.com/hask/" rel="noreferrer" target="_blank">http://dev.stephendiehl.com/hask/</a> 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.)<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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 (<a href="https://github.com/haskellfoundation/HaskellSchool" rel="noreferrer" target="_blank">https://github.com/haskellfoundation/HaskellSchool</a>). These will take time to grow, but my hope is that a future person like you will have an easier route in.<br>
><br>
> 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. :)<br>
><br>
> Richard<br>
><br>
><br>
> On Sep 16, 2021, at 12:53 AM, Anthony Clayden <<a href="mailto:anthony.d.clayden@gmail.com" target="_blank">anthony.d.clayden@gmail.com</a><mailto:<a href="mailto:anthony.d.clayden@gmail.com" target="_blank">anthony.d.clayden@gmail.com</a>>> wrote:<br>
><br>
> Hi Michael, oh dear, oh dear, oh dear.<br>
><br>
> 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?<br>
><br>
> > ... 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.<br>
><br>
><br>
> 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.)<br>
><br>
><br>
> 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.<br>
><br>
><br>
> I really don't know how you could have got any experience with Haskell and say "subtly".<br>
><br>
><br>
> 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.)<br>
><br>
><br>
><br>
> > (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.")<br>
><br>
><br>
> 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.<br>
><br>
><br>
> > And since the concepts are seldom described in concrete enough and time-honored programming language terms (by comparison to other programming languages)<br>
><br>
><br>
> 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.<br>
><br>
><br>
> (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?)<br>
><br>
><br>
> You do have a point that the terminology in Haskell is often mysterious<br>
><br>
><br>
> > [SPJ said] F# had settled on the term "workflow" instead of "monad", and he felt this was wise.<br>
><br>
><br>
> Yes many have yearned for a more warm-and-cuddly term than "monad". But the terminology barrier starts before that.<br>
><br>
><br>
> 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.<br>
><br>
><br>
> AntC<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> Haskell-Cafe mailing list<br>
> To (un)subscribe, modify options or view archives go to:<br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
> Only members subscribed via the mailman list are allowed to post.<br>
><br>
> -------------- next part --------------<br>
> An HTML attachment was scrubbed...<br>
> URL: <<a href="http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210916/cf601806/attachment-0001.html" rel="noreferrer" target="_blank">http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210916/cf601806/attachment-0001.html</a>><br>
><br>
> ------------------------------<br>
><br>
> Message: 4<br>
> Date: Thu, 16 Sep 2021 14:21:58 -0400<br>
> From: Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>><br>
> To: David Feuer <<a href="mailto:david.feuer@gmail.com" target="_blank">david.feuer@gmail.com</a>>, GHC Users List<br>
> <<a href="mailto:glasgow-haskell-users@haskell.org" target="_blank">glasgow-haskell-users@haskell.org</a>>, ghc-devs <<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a>><br>
> Cc: "<a href="mailto:haskell-cafe@haskell.org" target="_blank">haskell-cafe@haskell.org</a>" <<a href="mailto:haskell-cafe@haskell.org" target="_blank">haskell-cafe@haskell.org</a>><br>
> Subject: Re: [Haskell-cafe] Bundle patterns with type aliases<br>
> Message-ID:<br>
> <CAHYVw0w33GC7mmaCY8k=74y0P8s4nbn_An6bZcj=<a href="mailto:SGbqiCznhw@mail.gmail.com" target="_blank">SGbqiCznhw@mail.gmail.com</a>><br>
> Content-Type: text/plain; charset="utf-8"<br>
><br>
> These are great ideas! Could you please create a ghc tracker ticket with a<br>
> tiny examples or two?<br>
><br>
> There may be specific technical reasons we might not be able to do so for<br>
> type synonyms in ghc, but I don’t see any obvious barriers in the case of<br>
> David’s excellent idea, I’ve def seen lots of great code out there where<br>
> you’d really want either associated pattern synonyms or to bundle pattern<br>
> synonyms with the exported public interface for a type class.<br>
><br>
> I’m sure there’s some devil in the details but these sound lovely. Step -1<br>
> is making up 1-2 toy examples and explaining what and why you want it on a<br>
> ghc ticket!<br>
><br>
> On Wed, Sep 8, 2021 at 1:25 PM David Feuer <<a href="mailto:david.feuer@gmail.com" target="_blank">david.feuer@gmail.com</a>> wrote:<br>
><br>
> > I would like that, along with the ability to bundle patterns with classes.<br>
> ><br>
> > On Wed, Sep 8, 2021, 1:13 PM Keith <<a href="mailto:keith.wygant@gmail.com" target="_blank">keith.wygant@gmail.com</a>> wrote:<br>
> ><br>
> >> Is there currently a way to 'bundle' a pattern with a type alias? And if<br>
> >> not, could that capability be added to the PatternSynonyms GHC extension?<br>
> >> (Is this the right place to ask, or should I be asking a GHC list?)<br>
> >><br>
> >> --Keith<br>
> >> Sent from my phone with K-9 Mail.<br>
> >> _______________________________________________<br>
> >> Haskell-Cafe mailing list<br>
> >> To (un)subscribe, modify options or view archives go to:<br>
> >> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
> >> Only members subscribed via the mailman list are allowed to post.<br>
> ><br>
> > _______________________________________________<br>
> > Haskell-Cafe mailing list<br>
> > To (un)subscribe, modify options or view archives go to:<br>
> > <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
> > Only members subscribed via the mailman list are allowed to post.<br>
> -------------- next part --------------<br>
> An HTML attachment was scrubbed...<br>
> URL: <<a href="http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210916/ef761378/attachment-0001.html" rel="noreferrer" target="_blank">http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210916/ef761378/attachment-0001.html</a>><br>
><br>
> ------------------------------<br>
><br>
> Message: 5<br>
> Date: Thu, 16 Sep 2021 15:08:45 -0400<br>
> From: David Feuer <<a href="mailto:david.feuer@gmail.com" target="_blank">david.feuer@gmail.com</a>><br>
> To: Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>><br>
> Cc: "<a href="mailto:haskell-cafe@haskell.org" target="_blank">haskell-cafe@haskell.org</a>" <<a href="mailto:haskell-cafe@haskell.org" target="_blank">haskell-cafe@haskell.org</a>>, GHC Users<br>
> List <<a href="mailto:glasgow-haskell-users@haskell.org" target="_blank">glasgow-haskell-users@haskell.org</a>>, ghc-devs<br>
> <<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a>><br>
> Subject: Re: [Haskell-cafe] Bundle patterns with type aliases<br>
> Message-ID:<br>
> <CAMgWh9vSfQwQHkE3tg7d5NJ4CtAVLP2p=<a href="mailto:hsah3a5St3q0t7zeQ@mail.gmail.com" target="_blank">hsah3a5St3q0t7zeQ@mail.gmail.com</a>><br>
> Content-Type: text/plain; charset="utf-8"<br>
><br>
> Here's an example:<br>
><br>
> pattern State :: (s -> (a, s)) -> State s a<br>
> pattern State f <- (coerce . runStateT -> f) where<br>
> State = state<br>
><br>
> This would be very nice to bundle with the State type synonym.<br>
><br>
> On Thu, Sep 16, 2021, 2:22 PM Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>><br>
> wrote:<br>
><br>
> > These are great ideas! Could you please create a ghc tracker ticket with a<br>
> > tiny examples or two?<br>
> ><br>
> > There may be specific technical reasons we might not be able to do so for<br>
> > type synonyms in ghc, but I don’t see any obvious barriers in the case of<br>
> > David’s excellent idea, I’ve def seen lots of great code out there where<br>
> > you’d really want either associated pattern synonyms or to bundle pattern<br>
> > synonyms with the exported public interface for a type class.<br>
> ><br>
> > I’m sure there’s some devil in the details but these sound lovely. Step<br>
> > -1 is making up 1-2 toy examples and explaining what and why you want it on<br>
> > a ghc ticket!<br>
> ><br>
> > On Wed, Sep 8, 2021 at 1:25 PM David Feuer <<a href="mailto:david.feuer@gmail.com" target="_blank">david.feuer@gmail.com</a>> wrote:<br>
> ><br>
> >> I would like that, along with the ability to bundle patterns with classes.<br>
> >><br>
> >> On Wed, Sep 8, 2021, 1:13 PM Keith <<a href="mailto:keith.wygant@gmail.com" target="_blank">keith.wygant@gmail.com</a>> wrote:<br>
> >><br>
> >>> Is there currently a way to 'bundle' a pattern with a type alias? And if<br>
> >>> not, could that capability be added to the PatternSynonyms GHC extension?<br>
> >>> (Is this the right place to ask, or should I be asking a GHC list?)<br>
> >>><br>
> >>> --Keith<br>
> >>> Sent from my phone with K-9 Mail.<br>
> >>> _______________________________________________<br>
> >>> Haskell-Cafe mailing list<br>
> >>> To (un)subscribe, modify options or view archives go to:<br>
> >>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
> >>> Only members subscribed via the mailman list are allowed to post.<br>
> >><br>
> >> _______________________________________________<br>
> >> Haskell-Cafe mailing list<br>
> >> To (un)subscribe, modify options or view archives go to:<br>
> >> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
> >> Only members subscribed via the mailman list are allowed to post.<br>
> ><br>
> ><br>
> -------------- next part --------------<br>
> An HTML attachment was scrubbed...<br>
> URL: <<a href="http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210916/82745d58/attachment-0001.html" rel="noreferrer" target="_blank">http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210916/82745d58/attachment-0001.html</a>><br>
><br>
> ------------------------------<br>
><br>
> Message: 6<br>
> Date: Thu, 16 Sep 2021 15:12:57 -0400<br>
> From: David Feuer <<a href="mailto:david.feuer@gmail.com" target="_blank">david.feuer@gmail.com</a>><br>
> To: Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>><br>
> Cc: "<a href="mailto:haskell-cafe@haskell.org" target="_blank">haskell-cafe@haskell.org</a>" <<a href="mailto:haskell-cafe@haskell.org" target="_blank">haskell-cafe@haskell.org</a>>, GHC Users<br>
> List <<a href="mailto:glasgow-haskell-users@haskell.org" target="_blank">glasgow-haskell-users@haskell.org</a>>, ghc-devs<br>
> <<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a>><br>
> Subject: Re: [Haskell-cafe] Bundle patterns with type aliases<br>
> Message-ID:<br>
> <CAMgWh9scvLkAeZpGV+FrLWReR55=<a href="mailto:gOBVLYBHOrwVDwbpY_G6rg@mail.gmail.com" target="_blank">gOBVLYBHOrwVDwbpY_G6rg@mail.gmail.com</a>><br>
> Content-Type: text/plain; charset="utf-8"<br>
><br>
> Here's a class example:<br>
><br>
> class (MFoldable t, Monoid t) => Sequence t where<br>
> singleton :: Elem t -> t<br>
> ....<br>
><br>
> One might wish to write pattern synonyms for viewing the ends of a<br>
> sequence, like the ones in Data.Sequence, and bundle them with this class.<br>
><br>
> On Thu, Sep 16, 2021, 2:22 PM Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>><br>
> wrote:<br>
><br>
> > These are great ideas! Could you please create a ghc tracker ticket with a<br>
> > tiny examples or two?<br>
> ><br>
> > There may be specific technical reasons we might not be able to do so for<br>
> > type synonyms in ghc, but I don’t see any obvious barriers in the case of<br>
> > David’s excellent idea, I’ve def seen lots of great code out there where<br>
> > you’d really want either associated pattern synonyms or to bundle pattern<br>
> > synonyms with the exported public interface for a type class.<br>
> ><br>
> > I’m sure there’s some devil in the details but these sound lovely. Step<br>
> > -1 is making up 1-2 toy examples and explaining what and why you want it on<br>
> > a ghc ticket!<br>
> ><br>
> > On Wed, Sep 8, 2021 at 1:25 PM David Feuer <<a href="mailto:david.feuer@gmail.com" target="_blank">david.feuer@gmail.com</a>> wrote:<br>
> ><br>
> >> I would like that, along with the ability to bundle patterns with classes.<br>
> >><br>
> >> On Wed, Sep 8, 2021, 1:13 PM Keith <<a href="mailto:keith.wygant@gmail.com" target="_blank">keith.wygant@gmail.com</a>> wrote:<br>
> >><br>
> >>> Is there currently a way to 'bundle' a pattern with a type alias? And if<br>
> >>> not, could that capability be added to the PatternSynonyms GHC extension?<br>
> >>> (Is this the right place to ask, or should I be asking a GHC list?)<br>
> >>><br>
> >>> --Keith<br>
> >>> Sent from my phone with K-9 Mail.<br>
> >>> _______________________________________________<br>
> >>> Haskell-Cafe mailing list<br>
> >>> To (un)subscribe, modify options or view archives go to:<br>
> >>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
> >>> Only members subscribed via the mailman list are allowed to post.<br>
> >><br>
> >> _______________________________________________<br>
> >> Haskell-Cafe mailing list<br>
> >> To (un)subscribe, modify options or view archives go to:<br>
> >> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
> >> Only members subscribed via the mailman list are allowed to post.<br>
> ><br>
> ><br>
> -------------- next part --------------<br>
> An HTML attachment was scrubbed...<br>
> URL: <<a href="http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210916/1569e2b4/attachment.html" rel="noreferrer" target="_blank">http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210916/1569e2b4/attachment.html</a>><br>
><br>
> ------------------------------<br>
><br>
> Subject: Digest Footer<br>
><br>
> _______________________________________________<br>
> Haskell-Cafe mailing list<br>
> <a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
><br>
><br>
> ------------------------------<br>
><br>
> End of Haskell-Cafe Digest, Vol 217, Issue 16<br>
> *********************************************<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
Only members subscribed via the mailman list are allowed to post.</blockquote></div></div>