even for someone moderately interested in FP, this one goes above my head and the only take-away I can get from it is "maybe use ocaml instead of haskell"
it's experimenting with a feature that was added to Haskell but just never caught on. it's theoretically very powerful but it's far enough from idiomatic Haskell that it sees basically zero usage in the wild as the cost for using it is that very few people can understand what you've done.
And I wouldn't be surprised if there were more retired left handed surgeons in their 50s living in rural Switzerland than people who understand what he's talking about.
Which highlighted the fact that typeclasses can basically be thought of as an additional vtable argument passed to every function that has typeclass constraints. (And, indeed, thinking about them this way often allows one to avoid typeclasses entirely and achieve the same kind of polymorphism in simpler and more flexible ways.)
Backpacks can achieve something similar, except by declaring an abstract "signature" for your dependency, rather than a function argument. (Backpacks can also be used to do a lot more than this, of course, but that's outside the scope of the OP article.)
I'm a pretty average programmer/ex-programmer/hn-commenter in this context. I have never programmed in Haskell though in college I programmed with the language "fp" that is naturally functional.
I can tell this is article is about a common, wide debate in CS; should languages have "strict" structures like type class or loose structures like "objects". This related-to but not the same as the debate on whether to have pure functional languages or ad-hoc imperative languages.
I know in programming practice, everything ad-hoc has won but programming language "theory", everything strict has won.
Now in this context, I understand the post as advocating a certain kind of loose data typing with the strict-world of Haskell. Which I'd imagine won't make any ideologue happy. But seems like an OK contribution to the debate.
To add my own takes on everything, as hners must do, I think the strict structures of functional programming have quite a bit of merit for various purposes. BUT - they aren't intuitive/the-easy-way-to-everything-once-you-know/etc. AND they aren't a way to solve the software crisis.
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.
How to reuse `readFile` `writeFile` program with this module trick?
Assuming `IO.readFile` and `IO.writeFile` is replaced by HTTP requests.
I can define `writeFile` and `readFile` in a type class and then implement the effect for HTTP variant, hiding the HTTP client beneath.
Is it just wiring it up in mixins, cabal file?
I think general conclusion is that there's no need for dependency injection, environment objects, or similar tricks if module system is rich enough.
For a long time I questioned why Python needs anything but `async def` or `def` (async should be achievable through module or `yield` usage) and `import` statements, to achieve maximal reuse, given dynamic nature of language and modules. We could ignore all object-oriented features, decorators, replace them with modules. Would be flatter and readable compared to bloated feature set.
The blog post is an exploration of an alternative way to structure code in Haskell.
Why is the bar such that Haskell blog posts have to either demonstrate something clearly better then the status quo or that they need to explain the fundamentals of the language?
20 comments
[ 5.1 ms ] story [ 48.5 ms ] threadAnd I wouldn't be surprised if there were more retired left handed surgeons in their 50s living in rural Switzerland than people who understand what he's talking about.
The author then uses Backpacks to achieve ad-hoc polymorphism without typeclasses.
There is a well-known article from a long time ago which was conceptually similar: https://www.haskellforall.com/2012/05/scrap-your-type-classe...
Which highlighted the fact that typeclasses can basically be thought of as an additional vtable argument passed to every function that has typeclass constraints. (And, indeed, thinking about them this way often allows one to avoid typeclasses entirely and achieve the same kind of polymorphism in simpler and more flexible ways.)
Backpacks can achieve something similar, except by declaring an abstract "signature" for your dependency, rather than a function argument. (Backpacks can also be used to do a lot more than this, of course, but that's outside the scope of the OP article.)
I can tell this is article is about a common, wide debate in CS; should languages have "strict" structures like type class or loose structures like "objects". This related-to but not the same as the debate on whether to have pure functional languages or ad-hoc imperative languages.
I know in programming practice, everything ad-hoc has won but programming language "theory", everything strict has won.
Now in this context, I understand the post as advocating a certain kind of loose data typing with the strict-world of Haskell. Which I'd imagine won't make any ideologue happy. But seems like an OK contribution to the debate.
To add my own takes on everything, as hners must do, I think the strict structures of functional programming have quite a bit of merit for various purposes. BUT - they aren't intuitive/the-easy-way-to-everything-once-you-know/etc. AND they aren't a way to solve the software crisis.
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.
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...
That era is now over.
Assuming `IO.readFile` and `IO.writeFile` is replaced by HTTP requests. I can define `writeFile` and `readFile` in a type class and then implement the effect for HTTP variant, hiding the HTTP client beneath.
Is it just wiring it up in mixins, cabal file?
I think general conclusion is that there's no need for dependency injection, environment objects, or similar tricks if module system is rich enough.
For a long time I questioned why Python needs anything but `async def` or `def` (async should be achievable through module or `yield` usage) and `import` statements, to achieve maximal reuse, given dynamic nature of language and modules. We could ignore all object-oriented features, decorators, replace them with modules. Would be flatter and readable compared to bloated feature set.
The blog post is an exploration of an alternative way to structure code in Haskell.
Why is the bar such that Haskell blog posts have to either demonstrate something clearly better then the status quo or that they need to explain the fundamentals of the language?