- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] On finding the right exposition...
by Olaf Klinke 19 Sep '21

19 Sep '21

Perhaps one thing that speaks in favour of Anthony Clayden's suggestion to learn lambda calculus before/along Haskell is this: Haskell shares the evaluation model with the lambda calculus. One of Michael Turner's points of criticism was, as I understand it, insufficient documentation about the inner workings of Haskell [1]. Haskell needs constructs like the ST monad because of the evaluation model. Once the learner knows, perhaps by experimenting with it on paper or on [2,3], that a lambda term can be reduced in several ways, and confluence guarantees that all ways result in the same normal form, then some things might be much clearer: * Which freedoms the compiler can exercise in evaluating your program. * Why one needs the State monad for ordering sequences of effects (the programmable semicolon) [4]. * How the various tricks and pitfalls around lazy and strict functions work, e.g. Viktor's new Foldable documentation. I looked at the first chapter of my K&R. It presents small example C programs and explains what they do. Taking small Haskell programs and explaining how these lambda terms are reduced to normal form would be a comparable (and desirable, in Michael's view) approach? The Haskell language report does not say anything in this respect, as far as I can see. Only translation of syntactic constructs to core Haskell is given. Olaf [1] Of course the documentation is out there somewhere, but not written in a style which pleases learners like Michael. [2] https://lambdacalc.io/ [3] https://capra.cs.cornell.edu/lambdalab/ [4] I tried to convince myself that the state monad indeed sequences effects. In a pure lambda world I think this should mean that a certain lambda term has only one way of being reduced. Is the following valid reasoning? type State s a = s -> (a,s) When Church-encoding the tuple (a,s) one finds that (m :: State s a) >>= (k :: a -> State s b) = \s -> m s k so the only applicable rule is beta-reducing m when applying to some s.

5 4

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

19 Sep '21

> With an implicit forall, the code does type check. So to recap. Explicit/implicit forall doesn't seem to matter here (both compile, both work): > pattern Justy :: a -> Maybe a > pattern Justy x = Just x > > pattern Justy2 :: forall a. a -> Maybe a > pattern Justy2 x = Just x (The docos for Pattern Synonyms don't give any examples with explicit `forall`; neither do they discuss whether it makes a difference. I'm inclined to say don't bother with outermost `forall`.) But it does matter here: > data Some where > Some :: a -> Some > > pattern Any :: a -> Some > pattern Any x = Some x > > pattern Any2 :: forall a. a -> Some > pattern Any2 x = Some x > > pattern Any3 :: (forall a. a) -> Some > pattern Any3 x = Some x `Any` is accepted; `Any2` and `Any3` are rejected with a type mismatch/rigid tyvar message per your o.p. (I'm not surprised `Any3` is rejected.) The message complains about the binding line, not the signature. If you don't give a signature for `Any`, we get (with `-fprint-explicit-foralls`) `Any :: forall {a}. a -> Some`, which is the same as for `Justy, Justy2 :: forall {a}. a -> Maybe a` mutatis mutandis. As to 'working', I presume your actual code doesn't merely have an existential for `Some`(?) but rather a constraint. Otherwise pattern-matching with `(Any x)` or with `(Some x)` you can't do anything with the `x` on RHS. Your o.p. asked > Is there a way around it, or is this a missing feature? What feature would you like that you think is "missing"? Do you think a pattern's explicit `forall` for an existential data constructor should do something different vs for a regular datatype? This could just be a stray loose end that nobody anticipated with Pattern Synonyms.

3 2

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

18 Sep '21

> And there's not a mention in the docos that this is even a thing. To moderate myself ... There's one example pattern sig with explicit `forall`s, and it's wrt existentials/GADTs. https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/pattern_synonyms.ht…, bullet wrt lexically-scoped tyvars. It doesn't say you can have a dangling `forall` quantifying nothing -- indeed that you need such a thing in this case. It looks like if you want to constrain the existential, you have to declare that in the datatype, then repeat it in the sig for the pattern.

1 0

Writing about Haskell, and the Lambda Sidebar
by Michael Turner 18 Sep '21

18 Sep '21

The debate over how much theory to give newbies seems endless, and there are good arguments on both sides. Maybe the synthesis is to just offer expository prose AND the mathematical approach, on the same page, side by side. Notational compression has its points. When I was in college and getting a little impatient with an expository text, whether it was something algorithmic or in the physical sciences, I'd often write the tightest thing I could, using not much more than set-theoretic notation. I even made a little game of it: could I almost completely eliminate English words? This gave my eye a much smaller space to range over. (Later, I heard this recommended by my favorite CS professor, Bernard Mont-Reynaud, a former student of Knuth's.) Although it's bad study practice to rewrite the text, this seemed an allowable exception. Whatever the philosophical problems of naive set theory, they didn't matter because computers are pretty naive anyway. And you could abstract away machine details; these were, in a way, still annoyingly present even back in the day when it was common to publish algorithm papers with Algol in them, which often still seemed too verbose to me. A few times, I thought I could mark up my textbook with, "I have discovered a truly concise way to express what this page says, and it CAN fit in the margin!" The debate over math-first-or-not is really an old problem: syllabus sequencing. But syllabus sequencing isn't quite learning sequencing. To be sure, you really do need to fully learn some concepts as the foundation for later ones. But psychologists have found that a feeling of "not quite getting it" isn't necessarily bad. It can even be good. Strangely, concepts can finally gel long after you've convinced yourself that they just overflowed from your overfilled brain. It's been suggested that a mild state of anxiety actually helps absorption of concepts at a subconscious level, after which they start to float back up and swim at your command when you need to apply them. So instead of arguing where the lambda calculus chapter should go (or anything else mathematical for that matter) how about putting the math in sidebars? When I was in college, I probably would have ended up in the Haskell text sidebar out of impatience. These days, with math study literally decades behind me, I might instead look over on that side with a little anxiety, and often press on impatiently in the main text after thinking, "I didn't get that." But that wouldn't mean I wasn't absorbing anything. I might even be learning faster, in a longer-term view. Because learning gels at different levels at different times, under different pressures, it might even be more efficient theory-acquisition for me than a solidly mathematical chapter, no matter where in the text it appeared. 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

1 0

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

18 Sep '21

The end of your error message: > | > 63 | pattern Any a <- Some a > | ^ Appears to have program text (a mono-directional pattern binding) that doesn't correspond to the program text you quote. Whereas > pattern Any :: forall a. a -> Some > pattern Any a = Some Is a implicitly bi-directional pattern binding that will never work. (The free var `a` on LHS does not appear in RHS.) I'm suspecting the explicit forall is not much to do with it.

2 1

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

18 Sep '21

"I don't remember learning being as difficult as the claims on this thread. (Memory can deceive, I guess.)" Yes, it can. What really matters for that question is quantification. How hard was it for other people a decade ago? How hard is it now? What kinds of people were learning a decade ago? What kinds of people are learning now? Without measures, you're just offering anecdotal evidence. You say that Haskell is having problems because it wasn't true to the faith of "Avoid success at all costs". I always thought that was supposed to be a wryly paradoxical statement of strategy, not an "objective"; it was an impishly witty design-methodology heuristic, not a hymn. Perhaps I'm misreading the community spirit at Haskell Foundation, but it seems the tune shifted a while back. You feel that the wrong kinds of people are learning Haskell now, that it's "adopting" too many problem children. Thank you for your generous offer to help me dig myself out of the hole you said I dug for myself, though I can't understand why. After all, you've made it clear that you think I'm a problem child. How else to explain why you distorted what I've said elsewhere, in your summary of my positions, when you could have just linked to my actual words, in archives, and let them speak for themselves? "This juvenile delinquent has got Haskell all wrong -- stop him before he vandalizes again!" But I suppose it's just in your humanitarian nature to help even us juvenile delinquents. Still, are you sure you don't have things upside down? I'm afraid I can't offer much to you, from the way I feel the direction of gravity. >From where I am, I think the only thing I can send downward to you is a shovel full of dirt. Is GHC part of the problem? I'm pretty sure of that. Are lots of people getting Haskell wrong? That's symptomatic, at least. Has Haskell gotten too big. I wouldn't be surprised. Should more mathematical approaches be emphasized? I'm not against it, as long as there's emphasis where it's due -- for some Haskellers coming up, it may be better to bring in the math later, when they are already feeling certain patterns in coding but don't quite know how they can be concisely and rigorously expressed, and applied. But over and above all that, you can't learn Haskell by sitting with a reference manual, and trying things out in GHCI. Nor can you learn it very easily by studying relatively mature code. And if "avoiding success" means a book is giving examples that don't work anymore, that's more frustration for readers who are already feeling the steepness of the learning curve. People who want to learn need better things to read. What's "better"? It'll vary according to the reader. I'm a reader who doesn't need another sermon about, say, the virtues of static types -- I converted to that religion long ago. I'm a reader who keeps the machine level in mind, because I've been on projects where a new release of a product that used to be fast enough is suddenly extremely slow on startup initialization -- e.g., someone rewrote an SQL query in the ORM to be "more elegant" but unfortunately also as if disk-head seeks, platter rotations, and block reads were as virtually instantaneous as, say, a line fetch from L3 cache. The problem isn't overpopulation, it isn't like all those Irish that Reverend Malthus thought should starve to death because, well, they'll just breed out of control otherwise. It's the problem of professionalization, which software has always had. Entry is cheap and easy. Hardly a month goes by that we don't hear of some (supposed) miracle of modern software science from some senior in high school who started a software company. Turnover is high. This means a lot of internal treadmills to retain knowledge of how the code works. Lots of people burn out in ten years -- a ten years that, in other engineering professions, is the point at which you're considered fully seasoned, ready to hit your stride. Why the continuing immaturity? Software hasn't killed a lot of people (yet, he says, scanning the sky nervously for drones.) As long as most software was mostly in corporate information systems, the casualties tended to be only corporate-political. If you were such a casualty, it was a bit like being a player in an MMPORG. You could get "reincarnated" in another division, or another corporation, no matter how ignominious your failure. Not much karmic justice either. Even if you perpetrated fraud, which most financial firms prefer to cover up than prosecute, sending you on, because it would be bad PR to send your case to trial and have customers discover that the firm is not as good about internal security threats as it claims. To some extent, it's the very softness of software that has kept the field so immature. Mistakes are made, but unlike a shifty bridge or a shaky plane, they can be corrected cheaply and (for now) safely -- or at least, any new bugs that your patch introduced are subtler, less frequently manifested, easier to blame on someone else. Or maybe you jumped to another company by the time your code became a problem. Never have to grow up, not me! But one sign of maturity in an engineering profession is that it stops being a priesthood/guild and starts being a public responsibility. And that starts with clear communication, within and beyond the profession. Better tools are nice, of course. But if they are effectively impenetrable to those outside the guild, you're not really solving the problem. A firmer grounding in theory is also very important. But if it's hermetic incantations and thumping of mathematical bibles, that's also not good, clear communication, within and beyond the profession. Haskell has survived what is, for programming languages, a truly staggering infant mortality rate. But what stage of life is it in, now? Who are the models of maturity, for use of Haskell professionally? How can they be elevated to influence, both within and beyond Haskell programmer subculture? Bishops and guild masters were ultimately answerable to feudal lords, and modern institutions that fund software development are significantly feudal, both internally and in their interactions with other institutions. Professionalism confers an advantage: You can speak with the authority of backing from your own institution, its own ethics and values, its own standards -- as long as that profession has proven that it's motivated from a sense of public responsibility. But your profession has to speak clearly, as clearly as possible, on all levels, to maintain itself as an institution, to remain influential -- i.e., from a stance of being IN these feudal mini-worlds but not OF them. This is because, in a way, apart from the brains of its members, clear communication is the only real asset a professional institution has. And that's where better writing comes in. 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 Sat, Sep 18, 2021 at 12:40 PM <haskell-cafe-request(a)haskell.org> wrote: > > Send Haskell-Cafe mailing list submissions to > haskell-cafe(a)haskell.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > or, via email, send a message with subject or body 'help' to > haskell-cafe-request(a)haskell.org > > You can reach the person managing the list at > haskell-cafe-owner(a)haskell.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Haskell-Cafe digest..." > > > Today's Topics: > > 1. Re: Numerics (was: Re: Trouble with asinh) (Jerzy Karczmarczuk) > 2. On finding the right exposition... (Viktor Dukhovni) > 3. Re: On finding the right exposition... (Tom Ellis) > 4. Re: On finding the right exposition... (Monads) > (Joachim Durchholz) > 5. Re: On finding the right exposition... (Viktor Dukhovni) > 6. Re: On finding the right exposition... (Monads) (Brandon Allbery) > 7. Re: On finding the right exposition... (Monads) (Viktor Dukhovni) > 8. Re: On finding the right exposition... (David Feuer) > 9. Re: On finding the right exposition... (Tom Ellis) > 10. Re: Numerics (was: Re: Trouble with asinh) (Barak A. Pearlmutter) > 11. Re: On finding the right exposition... (Chris Smith) > 12. Re: On finding the right exposition... (Albert Y. C. Lai) > 13. Re: Haskell reference documentation, laws first or laws last? > (Keith) > 14. Re: Haskell's "historical futurism" needs better writing, not > better tools (Douglas McIlroy) > 15. Better writing about Haskell through multi-metaphor learning > (Michael Turner) > 16. Re: Haskell-Cafe Digest, Vol 217, Issue 16 (Anthony Clayden) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 17 Sep 2021 20:31:24 +0200 > From: Jerzy Karczmarczuk <jerzy.karczmarczuk(a)unicaen.fr> > To: haskell-cafe(a)haskell.org > Subject: Re: [Haskell-cafe] Numerics (was: Re: Trouble with asinh) > Message-ID: <32be9982-6be3-c136-c0b4-7622f3d88404(a)unicaen.fr> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > Le 17/09/2021 à 19:16, Carter Schonwald a écrit : > > > Hey Barak, is Common Lisp the only extant language to take those > > issues seriously or are there other examples or better ones? > > // tan / atan troubles cited by Barak. > > Common Lisp?? > > But even the ugly Python reacts better to such examples: > > *>>> from numpy import * > >>> rr, ii = 1.0e-20+0j, 1.0e-20j > * > > *>>> tan(rr),arctan(rr) > ((1e-20+0j), (1e-20+0j)) > >>> tan(ii),arctan(ii) > (1e-20j, 1e-20j)* > > *==* > > This works also with cmath (with arctan as atan). > ** > > Jerzy Karczmarczuk > > > > > -- > L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. > https://www.avast.com/antivirus > >

1 0

Pattern synonyms and explicit forall.
by coot＠coot.me 18 Sep '21

18 Sep '21

Consider the following existential type: ``` data Some where Some :: a -> Some ``` The following (bidirectional) pattern synonym is accepted: ``` pattern Any :: a -> Some pattern Any a = Some a ``` However using an explicit `forall` results in a type error: ``` pattern Any :: forall a. a -> Some pattern Any a = Some ``` ``` Patterns.hs:63:23: error: • Couldn't match expected type ‘a’ with actual type ‘a1’ ‘a1’ is a rigid type variable bound by a pattern with constructor: Some :: forall a. a -> Some, in a pattern synonym declaration at Patterns.hs:63:18-23 ‘a’ is a rigid type variable bound by the signature for pattern synonym ‘Any’ at Patterns.hs:62:23 • In the declaration for pattern synonym ‘Any’ • Relevant bindings include a :: a1 (bound at Patterns.hs:63:23) | 63 | pattern Any a <- Some a | ^ ``` This is indpendent whether `ExplicitForAll` or `ScopedTypedVariables` extensions are enabled or not. Is there a way around it, or is this a missing feature? Best regards, Marcin Szamotulski Sent with ProtonMail Secure Email.

1 0

Re: [Haskell-cafe] Haskell-Cafe Digest, Vol 217, Issue 16
by Anthony Clayden 18 Sep '21

18 Sep '21

>>* Haskell's big problem right now is adoption. * Heh heh, this sentence is multi-ways ambiguous. As in the 'problem' is that there's too many adopters/the wrong sort of people trying to adopt Haskell. The 'problem' is that Haskell is not keeping to its objective to "avoid success at all costs". > 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. Thank you for saying that out loud. I've been feeling for some time that GHC is getting harder to use. You're telling me that because I don't get Category Theory you want to throw me out of using Haskell. People who are allergic to Lambda-calculus are already excluded. So the ostensible difficulty on these threads: that the documentation is unhelpful, is not the problem at all. In fact it's deliberate that the docos are exclusionary. As part of this grand plan, Viktor is deliberately making the Libraries docos impenetrable. (By which I mean: the style is clear, but the material is unlearnable. Apparently I need to know what is an endomorphism before I can write a Foldable instance) And that explains a paradox: I learnt Haskell over a decade ago. There was far less intro material; and certainly no store of StackOverflow questions/answers. It should have been more difficult to learn than today. But I don't remember learning being as difficult as the claims on this thread. (Memory can deceive, I guess.) Back then Haskell was a much smaller, simpler language. There was less that could go wrong at the type level; and the error messages didn't keep recommending to switch on bamboozling features that (as it turned out) made the difficulty harder. Don't go claiming that if I switch off those features today it's as if I was still using H2010. Simply not true. I know that's not true, because I can still go back and use Hugs, or use GHC v7.10 (vintage ~2015), and have a much more pleasant/less bamboozling experience. Then "Haskell's big problem right now" is (depending on your point of view) either GHC or too many of the wrong adopters. And with Dependent Types coming along GHC is going to get a lot worse. (Maybe GHC will eventually get through the fog, throw out a load of cruft and become on average as usable as v7.10. I'm not prepared to go through the pain for 5 years to find out. I'll stick with v7.10.)

4 3

Re: [Haskell-cafe] Haskell's "historical futurism" needs better writing, not better tools
by Douglas McIlroy 17 Sep '21

17 Sep '21

> 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. There's a category error (in the sense of logic, not algebra) here. Learning a language is not comparable to understanding a program. The concept of lambda calculus is far more subtle than that of Turing machine. But if you know both, a program is likely to be much easier to understand when presented in lambda calculus than when presented as a Turing machine. Doug

1 0

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

17 Sep '21

On Thu, Sep 16, 2021 at 11:57 PM Michael Turner < michael.eugene.turner(a)gmail.com> wrote: > Wow, someone on this thread said of me, from what I wrote on the > beginner's list, "He's trying to translate Haskell to C/C++." > Brandon Allbery: "Actually no, they were talking about someone on StackOverflow." I'm afraid Anthony Clayden actually WAS talking about me: https://mail.haskell.org/pipermail/haskell-cafe/2021-September/134468.html (Or am I missing some Haskeller in-joke about StackOverflow?) 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 9:08 PM <haskell-cafe-request(a)haskell.org> wrote: > > Send Haskell-Cafe mailing list submissions to > haskell-cafe(a)haskell.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > or, via email, send a message with subject or body 'help' to > haskell-cafe-request(a)haskell.org > > You can reach the person managing the list at > haskell-cafe-owner(a)haskell.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Haskell-Cafe digest..." > > > Today's Topics: > > 1. Re: Haskell's "historical futurism" needs better writing, not > better tools (Tom Ellis) > 2. Re: Haskell-Cafe Digest, Vol 217, Issue 17 (Brandon Allbery) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 17 Sep 2021 11:15:05 +0100 > From: Tom Ellis <tom-lists-haskell-cafe-2017(a)jaguarpaw.co.uk> > To: haskell-cafe(a)haskell.org > Subject: Re: [Haskell-cafe] Haskell's "historical futurism" needs > better writing, not better tools > Message-ID: <20210917101505.GA3781@cloudinit-builder> > Content-Type: text/plain; charset=us-ascii > > On Fri, Sep 17, 2021 at 06:54:50PM +0900, Michael Turner wrote: > > On Fri, Sep 17, 2021 at 4:58 PM Tom Ellis > > <tom-lists-haskell-cafe-2017(a)jaguarpaw.co.uk> wrote: > > > Michael, I have an offer for you (in fact two): > > > > > > 1. I will collaborate with you to produce the guide to Haskell's > > > evaluation that *you* would want to read. > > > > > > 2. I will collaborate with you to write the NLP tool that you want to > > > write in Haskell. > > > > I think if I write anything long, it would first have to be my > > "Haskell in Plain English: A Guide for Lexical Semanticists." > > Fair enough. > > > > I can't do these without collaborating with someone like you. I > > > simply don't know what someone else wants to read. > > > > So much of good writing is just figuring out an audience. As I wrote > > to Viktor above, the section he presented to me in case I had trouble > > with it could be absolutely ideal for someone with more grounding. > > They could admire the sentence I struggled with, for how it > > encapsulates their understanding while refreshing their memory. > > Yes indeed. The audience that I write for is myself since that's the > audience I know. I am interested in writing for a more general > audience but I don't have motivation at the moment to do so without a > member of that general audience on the team. > > > I'm not sure that gearing a piece toward what /I/ would like to read > > is a much bigger audience > > I suspect the group of people who are interested in yet frustrated by > Haskell is *far* bigger than the group of people who are already > familiar with Haskell! > > > If I had to suggest an approach you could try on your own, it would > > be this: > > Thank you for the suggestion. I will bear it in mind if I decide to > tackle this in the future. > > Tom > > > ------------------------------ > > Message: 2 > Date: Fri, 17 Sep 2021 08:02:13 -0400 > From: Brandon Allbery <allbery.b(a)gmail.com> > To: Michael Turner <michael.eugene.turner(a)gmail.com> > Cc: haskell-cafe <haskell-cafe(a)haskell.org> > Subject: Re: [Haskell-cafe] Haskell-Cafe Digest, Vol 217, Issue 17 > Message-ID: > <CAKFCL4WyXKKfZ32kdkBJPYDs8k-TJ=4NVNS0L-g5oDy0BjYhbw(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > On Thu, Sep 16, 2021 at 11:57 PM Michael Turner < > michael.eugene.turner(a)gmail.com> wrote: > > > Wow, someone on this thread said of me, from what I wrote on the > > beginner's list, "He's trying to translate Haskell to C/C++." > > > > Actually no, they were talking about someone on StackOverflow. > > -- > brandon s allbery kf8nh > allbery.b(a)gmail.com >

1 0