September 2021 - Haskell-Cafe

Haskell's "historical futurism" needs better writing, not better tools
by Michael Turner 04 Oct '21

04 Oct '21

I haven't been able to view Andrew Boardman's video so far, but I gather from the summary that he feels the solution to the most pressing problem -- growth through fostering newbies -- is simply . . . better tools. I beg to differ, as a newbie who is now struggling with the revival of some Haskell code only with a feeling of claustrophobia. Where is this incredible feeling of freedom I was promised? At the top of the learning curve. And it feels like a Sisyphean slope -- the boulder stops, when I lay off learning, and then slowly starts to roll down under the gravitational force of memory decay. The real problem is that the writing sucks. Not all of it -- and some contributors to the community are stellar writers, even if, in the snarkish commentary they write about Haskell and the community, I don't quite get all the jokes. But speaking as a contributor to the Haskell.org wiki -- to which I contribute at times out of hope that clarifying points I understand will also lead to more clarity for myself -- I have to say it: the writing sucks. Why does it suck? Well, there are several syndromes. One is to think that Haskell is so incredibly good and pure and elementally profound that one must start conceptually from scratch. (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.") I've had a book recommended to me whose author had such pretensions to writing in a way that was easily foundational that he actually claimed his book could teach you Haskell even if you have no programming experience at all. Now, in practical marketing terms, that's just silly: such an approach addresses a minuscule fraction of the book's potential audience. If you've heard of Haskell as a programming language, you're probably software-multilingual already. But in practical pedagogical terms, it's also a little ridiculous. 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. Here's how Haskell makes something easier (at least perhaps in being more concise, if the Haskell is more concise) but also conferring useful leverage where Haskell might otherwise seem unnecessarily verbose. The problem of better writing is ultimately social, I believe. I have a friend who's a tenured professor at Columbia University, who has used Haskell in courses, who praises Haskell for how it makes students think a little more clearly about how to structure software. However, his final verdict is this: Functional programming is a cult. Now, he's a unabashedly abrasive type. (Just ask him, he'll tell you.) And that verdict IS a little over the top. But I have to say, my impression of the community is that there are Founder demi-gods praised even though they leave something to be desired in how articulate and clear they are for newbies, even when claiming to be addressing newbies, while the language itself seems to be somewhat an object of worship. How can the writing be better? Well, here's a clue: Simon Peyton-Jones, somewhere in a talk where he was his usual vibrant self (but where the audience was clearly stunned and intimidated into silence even though he'd invited people to interrupt with questions) said that F# had settled on the term "workflow" instead of "monad", and he felt this was wise. Workflow? Workflow!? My still-feeble understanding of monads took a leap forward, because suddenly I had a motivation for them: abstraction of the idea of a workflow. Could it be that something as simple as Maybe was a kind of "degenerate case" of a "workflow abstraction"? I felt massively encouraged that I might finally figure out how great monads were. Which is not to say that I have. Writers: you need to stop speaking your own obscure little dialect of "programmer English". If you're not aware that you are, become more self-aware. If you ARE aware of it, become aware of how snobbish or pointlessly mysterious you sound. And if you do become aware of how you sound, but don't care, ask yourself: if the goal now is to spread Haskell and help it flourish, isn't your attitude more of a hindrance than a help? Tools? That's not the front I'd pick. Because I hit a glitch in getting VScode to work under Windows 10 (yes, cue the snobbery), I backed off to github bash and vim. And you know what? It's fine. Sorry if my knuckles seem to be dragging on the floor, but I'm from the Stone Age of Unix v7 command line and Bill Joy's original vi. I'd like nicer tools. But they aren't likely to help me with Haskell. What's not fine: half the time, I can't figure out the error messages from GHC, and a dismaying portion of the time, I can't figure out the language documentation. And since the concepts are seldom described in concrete enough and time-honored programming language terms (by comparison to other programming languages) they often don't really stick. It's like my Sysiphean boulder has been pre-greased -- if I stop pushing (hard enough with all the abstraction grease on it), it starts to slide even before it rolls, whenever I leave off coding in Haskell for any length of time. Sorry for not writing better email here -- my sentences get rather long and tortuous when I rant. But not sorry for ranting. You say the solution to a tool adoption problem (getting more people to use Haskell) is yet more tools written in Haskell, for your favorite language, Haskell? No. The failure here is a failure to communicate. 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

7 26

Cabal or stack in 2021 ?
by Alexis Praga 01 Oct '21

01 Oct '21

Hi, As an intermediate beginner, I've been back into Haskell for the last months for a small project, using stack as the building tool. Why stack ? A few years back, I learned that it was the "best" way to build projects to avoid "cabal hell", which I understood at the time as "managing dependencies with cabal is hard". As such, I've use stack since and have been quite happy with it. The only drawback is that building a project can be quite long. This is usually not a problem, except for writing Haskell scripts using shelly (for example), where the stack layout is a bit impractical for fast-paced development. A solution is to use `runghc` or a script interpreter [1]. However, I've seen some projects where cabal is used to build directly instead of cabal, so it looks like the situation improved. My question is this: in 2021, is there a reason to switch back to cabal ? Thanks, [1] https://www.fpcomplete.com/haskell/tutorial/stack-script/ -- Alexis Praga

8 11

Re: [Haskell-cafe] Haskell's "historical futurism" needs better writing, not better tools
by Anthony Clayden 01 Oct '21

01 Oct '21

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

5 5

canonicalization of interval libraries
by Olaf Klinke 29 Sep '21

29 Sep '21

Emily Pillmore wrote: > Hello Haskell! > > I'm pleased to announce that the Core Libraries Committee Elections for September 2021 have concluded, and we have selected 2 new CLC members: > > - [Andrew Lelechenko]( https://github.com/Bodigrim ) > > - [Melanie Brown]( https://github.com/bi-functor ) > I could not help but notice that both new members have either written or contributed to an interval library. There are a handful out there (disclaimer: I have written one of them) but as far as I know there is no de-facto standard. Why is that? Is it because the applications of intervals are too diverse and hence no single type fits all? Or is it because it is such a niche application that no single library could gather enough traction? I'm curious whether others see the need to have a de-facto standard interval library that is both general and performant, as we are used to from our "core libraries". Judging from the number of downloads on hackage, people are mostly interested in intervals of floating point numbers and intervals of time. Olaf P.S. Yes, I am aware of the relevant xkcd comic on standards.

1 0

[ANN] CLC Elections Outcome - September 2021
by Emily Pillmore 29 Sep '21

29 Sep '21

Hello Haskell! I'm pleased to announce that the Core Libraries Committee Elections for September 2021 have concluded, and we have selected 2 new CLC members: - [Andrew Lelechenko]( https://github.com/Bodigrim ) - [Melanie Brown]( https://github.com/bi-functor ) The candidate pool was especially broad for this election and it was very difficult to choose, but we'd like to thank everyone for applying nonetheless. It is genuinely heartwarming to see so many people eager to help support the Haskell ecosystem in an official capacity! We encourage any and all candidates to continue helping to support the core libraries as we renovate the CLC. As mentioned in the latest CLC update (see: https://discourse.haskell.org/t/state-of-the-core-libraries-committee-updat… ), we are set to begin writing a new process and ways of working for the CLC now that the elections have concluded. We aim to have these finished within the month. Happy Hacking! Emily Pillmore - on behalf of the CLC

2 1

Very binding semicolon
by Anthony Clayden 28 Sep '21

28 Sep '21

>From the department of improbable syntax/I don't get how this works, but it does: > f :: [a] -> [a] > ;; f xs = xs ++ reverse xs Nicely (to my eye) groups/indents the binding under the signature. Especially handy with ScopedTypeVariables, to show how the scoped vars 'belong' > f :: forall a. [a] -> [a] > ;; f xs = xs ++ ys > where > ys :: [a] > ys = reverse xs The doubled `;;` stands out like a ditto. It could be a single semicolon (which means there's an empty decl/binding between the semis -- I don't see that's allowed by the syntax). Unfortunately, for multi-line bindings you need to repeat the `;;` > f :: [a] -> [a] > ;; f [] = [] > ;; f xs = xs ++ reverse xs

2 2

[TFP'22] first call for papers: Trends in Functional Programming 2022, 10-11 February (with Lambda Days 2022 & TFPIE 2022)
by Peter Achten 27 Sep '21

27 Sep '21

====== TFP 2022 ====== 23rd Symposium on Trends in Functional Programming 10-11 February, 2022 Krakow, Poland https://trendsfp.github.io/index.html == Important Dates == Submission deadline for pre-symposium review Wednesday 1st December, 2021 Submission deadline for draft papers Wednesday 12th January, 2022 Notification for pre-symposium submissions Friday 21st January, 2022 Notification for draft submissions Friday 21st January, 2022 Symposium dates Thursday 10th - Friday 11th February, 2022 Submission deadline for post-symposium reviewing Wednesday 16th March, 2022 Notification for post-symposium submissions Friday 13rd May, 2022 The Symposium on Trends in Functional Programming (TFP) is an international forum for researchers with interests in all aspects of functional programming, taking a broad view of current and future trends in the area. It aspires to be a lively environment for presenting the latest research results, and other contributions. Please be aware that TFP uses two distinct rounds of submissions. TFP 2022 will be co-located with two other functional programming events. TFP 2022 will be accompanied by the International Workshop on Trends in Functional Programming in Education (TFPIE), which will take place on February 11. Simultaneously with TFP, Lambda Days '22 is a two day conference where academia meets industry, where research and practical application collide. == Scope == The symposium recognizes that new trends may arise through various routes. As part of the Symposium's focus on trends we therefore identify the following five article categories. High-quality articles are solicited in any of these categories: * Research Articles: Leading-edge, previously unpublished research work * Position Articles: On what new trends should or should not be * Project Articles: Descriptions of recently started new projects * Evaluation Articles: What lessons can be drawn from a finished project * Overview Articles: Summarizing work with respect to a trendy subject Articles must be original and not simultaneously submitted for publication to any other forum. They may consider any aspect of functional programming: theoretical, implementation-oriented, or experience-oriented. Applications of functional programming techniques to other languages are also within the scope of the symposium. Topics suitable for the symposium include, but are not limited to: * Functional programming and multicore/manycore computing * Functional programming in the cloud * High performance functional computing * Extra-functional (behavioural) properties of functional programs * Dependently typed functional programming * Validation and verification of functional programs * Debugging and profiling for functional languages * Functional programming in different application areas: security, mobility, telecommunications applications, embedded systems, global computing, grids, etc. * Interoperability with imperative programming languages * Novel memory management techniques * Program analysis and transformation techniques * Empirical performance studies * Abstract/virtual machines and compilers for functional languages * (Embedded) domain specific languages * New implementation strategies * Any new emerging trend in the functional programming area If you are in doubt on whether your article is within the scope of TFP, please contact the TFP 2022 program chairs, Wouter Swierstra and Nicolas Wu. == Best Paper Awards == To reward excellent contributions, TFP awards a prize for the best paper accepted for the formal proceedings. TFP traditionally pays special attention to research students, acknowledging that students are almost by definition part of new subject trends. A student paper is one for which the authors state that the paper is mainly the work of students, the students are listed as first authors, and a student would present the paper. A prize for the best student paper is awarded each year. In both cases, it is the PC of TFP that awards the prize. In case the best paper happens to be a student paper, that paper will then receive both prizes. == Instructions to Author == Papers must be submitted at: https://easychair.org/conferences/?conf=tfp22 Authors of papers have the choice of having their contributions formally reviewed either before or after the Symposium. == Pre-symposium formal review == Papers to be formally reviewed before the symposium should be submitted before an early deadline and receive their reviews and notification of acceptance for both presentation and publication before the symposium. A paper that has been rejected in this process may still be accepted for presentation at the symposium, but will not be considered for the post-symposium formal review. == Post-symposium formal review == Draft papers will receive minimal reviews and notification of acceptance for presentation at the symposium. Authors of draft papers will be invited to submit revised papers based on the feedback received at the symposium. A post-symposium refereeing process will then select a subset of these articles for formal publication. == Paper categories == Draft papers and papers submitted for formal review are submitted as extended abstracts (4 to 10 pages in length) or full papers (20 pages). The submission must clearly indicate which category it belongs to: research, position, project, evaluation, or overview paper. It should also indicate which authors are research students, and whether the main author(s) are students. A draft paper for which all authors are students will receive additional feedback by one of the PC members shortly after the symposium has taken place. == Format == Papers must be written in English, and written using the LNCS style. For more information about formatting please consult the Springer LNCS web site. == Program Committee == Program Co-chairs Nicolas Wu - Imperial College London Wouter Swierstra - Utrecht University The remainder of the PC will be announced on the conference website.

1 0

mine sockets lib vs yesod
by Branimir Maksimovic 27 Sep '21

27 Sep '21

Let’s compare: 1000 parallel connections 100k requests yesod : 7658 recs/sec Errors 85808 Timeouted 0 Mine:: 12699 recs/sec Errors 0 Timeouted 0 10k connections, 100k requests: yesod: 5205 recs/sec Errors 81152 Timeouted 3842 Mine: 8160 recs/sec Errors 0 Timeouted 46 Sources: Yesod: / HomeR GET |] instance Yesod HelloWorld getHomeR :: Handler () getHomeR = do number <- liftIO (randomIO :: IO Float) let txt = pack $ "hello world " ++ show number sendResponse (txt:: Text) main :: IO () main = warp 3838 HelloWorld Mine: import Sockets import Foreign.C.String import Data.IORef import Control.Concurrent main = do ref <- newIORef 1 s <- socket defaultCallbacks { constructor = \ci -> set_cb ci defaultCallbacks { done_connected = binded ref, done_reading = process } } pl <- epoll 1000 pl1 <- epoll 1000 pl2 <- epoll 1000 pl3 <- epoll 1000 listen s "8080" pl_accept pl s pl_accept pl1 s pl_accept pl2 s pl_accept pl3 s let run pl = do forkIO $ run_loop pl (-1) run pl run pl1 run pl2 run_loop pl3 (-1) binded ref pl s = do i <- readIORef ref putStrLn $ "connection nr:"++show i writeIORef ref (i+1) pl_read pl s return 0 process pl s buf len = do str <- peekCStringLen (buf,fromIntegral len) ip <- client s str1 <- peekCString ip putStrLn $ "from "++str1++" \ngot "++str write pl s "Hello World!!!\r\n" return 0 if using -threaded performance is *worse*. Greetings, Branimir.

3 4

Munich Haskell Meeting, 2021-09-27 @ 19:30
by Leah Neukirchen 25 Sep '21

25 Sep '21

Dear all, next week, our monthly Munich Haskell Meeting will take place again on Monday, September 27 at Augustiner-Gaststätte Rumpler(!!) at 19h30. For details see here: http://muenchen.haskell.bayern/dates.html If you plan to join, please add yourself to this dudle until Monday 12:00 so we can reserve enough seats! It is OK to add yourself to the dudle anonymously or pseudonymously. Please note that not more than 10 people can attend---first come, first serve. https://dudle.inf.tu-dresden.de/haskell-munich-sep-2021/ Everybody is welcome! cu, -- Leah Neukirchen <leah(a)vuxu.org> https://leahneukirchen.org/

1 0

[BUG] Criterion is tied to x86 architecture
by Branimir Maksimovic 24 Sep '21

24 Sep '21

Problem as I work on Apple M1 processor, can’t compile Criterion as it use x86 specific features. Greetings, Branimir.

2 2