Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Death to type classes

jappie.me

Post reply on HN
Print view View original

21–30 of 78 posts

Re: Death to type classes

#23

Post by dagurp »

DaiPlusPlus wrote: post #18
nine_k wrote: post #4

Earlier quoted context omitted.

Indeed so, but that would require a few months worth of work from the reader, unfortunately. (I have a t-shirt with a lambda in a circle, reminiscent of the anarchist emblem, and words "no class, no state". It's definitely possible to explain to a passer-by who never studied FP what it refers to, but not in such a way that the joke remained funny. Possibly the same deal is with the bumper sticker saying "my other car…

> a lambda in a circle How often do people think you're a Half-Life fan instead?

or Aphex Twin

Re: Death to type classes

#25

Post by uncircle »

12_throw_away wrote: post #9

[flagged]

This is in reference to a meme (https://knowyourmeme.com/memes/stop-doing-math) and made relevant by the first paragraph of the post.

> Have you ever seen a Number grazing in the fields? Or a Functor chirping in the trees? No? That’s because they’re LIES. LIES told by the bourgeoisie to keep common folk down.

Re: Death to type classes

#26

Post by mrkeen » 

  In this case that’s the >>= from Maybe.Monad. As long as you satisfy the signature, it’s happy . do has nothing to do with Monads! Who lied to you?
Could have been a stronger point by using a non-monadic >>=.

I've been doing a lot of parsing lately and I find I don't need to reach all the way for monad (applicative is usually enough). But I guess that's what ApplicativeDo[1] is for.

  We’ve got to be explicit now which Functor or Monad we’re importing, and you can’t have do notation for different Monads in the same module.
This is a bit rough for usability (not to mention also undermines the point above).

But overall I like the approach of trying something radically new.

[1] https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/appl...

Re: Death to type classes

#29

Post by platz »

In the 2010-2020 era, readers of Hacker News used to know how to read Haskell and had strong opinions (pro and con) of it.

That era is now over.

Re: Death to type classes

#30

Post by kccqzy »

mrkeen wrote: post #26

In this case that’s the >>= from Maybe.Monad. As long as you satisfy the signature, it’s happy . do has nothing to do with Monads! Who lied to you? Could have been a stronger point by using a non-monadic >>=. I've been doing a lot of parsing lately and I find I don't need to reach all the way for monad (applicative is usually enough). But I guess that's what ApplicativeDo[1] is for. We’ve got to be explicit now which…

ApplicativeDo can be thought of as a compile-time transformation that turns sequential code into possibly parallel* code just by analyzing the way variables are used. Once I've had that realization I really appreciated it more.

*: By "possibly parallel" I mean the blocks of code are known to be independent from each other. They could be actually executed in parallel if the Applicative instance does so.

Post reply on HN