September 2021 - Haskell-Cafe

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

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 19 Sep '21

19 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 19 Sep '21

19 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