News for hackers. Stuff that matters.
Re:Rust vs. Haskell by cosmic_quanta on Tuesday February 14, 2023 @09:27AM (#34789751)
You need to use the IO monad to get anything working, true. Monad transformers? Not at all.

I'd say knowing how to use monad transformers is the barrier between intermediate and expert Haskell programmers.

Re:Rust vs. Haskell by sshine on Tuesday February 14, 2023 @09:33AM (#34789834)
You don’t even really need to understand monad transformers in general to use just the ‘ReaderT IO’ pattern, and if you want to go crazier, free monads are both easier to understand, and more flexible.
Re:Rust vs. Haskell by jeremyjh on Tuesday February 14, 2023 @09:30AM (#34789804)
I'd say using transformers are more the barrier between beginner and intermediate. Its not impossible to do serious work without them but I'm not sure its worth doing.
Re:Rust vs. Haskell by ghostwriter on Tuesday February 14, 2023 @09:35AM (#34789866)
> Its not impossible to do serious work without them but I'm not sure its worth doing.

How do you think the folks on Java and C# find their work worth doing on their end in that case?

Re:Rust vs. Haskell by jeremyjh on Tuesday February 14, 2023 @09:43AM (#34789986)
Because they aren't using Haskell? Haskell more or less creates all the problems that transformers solve.
Re:Rust vs. Haskell by ghostwriter on Tuesday February 14, 2023 @09:54AM (#34790157)
Such as what exactly? One can literally define the entire application state as a collection of iorefs and pass it around explicitly to actions defined universally as IO to emulate the default state of art in $mainstreamLang. The users of $mainstreamLang find it worthy and fulfilling and probably don't know a thing about transformers. Then why holding the work done in Haskell to a different standard of worthiness?
Re:Rust vs. Haskell by jeremyjh on Tuesday February 14, 2023 @10:01AM (#34790251)
I'm not making any points about users of mainstream languages. They have no use for transformers. Using a lot of global IORefs is possible but relies on a trick using unsafePerformIO; its definitely not in the spirit of Haskell to work this way though it is sometimes needed.
Re:Rust vs. Haskell by ghostwriter on Tuesday February 14, 2023 @10:09AM (#34790350)
I get this point and I agree with it, but I also object to your comment on having to use transformers as otherwise it's not worthy. My objection has to do with seemingly different standards and expectations applied to levels of users of mainstream languages. In my opinion they should be the same, even if Haskell allows for safer and better results with transformers: they are not universally required and expected to be used by all haskell developers. If `unsafePerformIO` does the trick for them at the moment, so be it: they won't be worse off than Java devs.
Re:Rust vs. Haskell by jeremyjh on Tuesday February 14, 2023 @10:30AM (#34790688)
If you aren't going to learn to write Haskell in the spirit of Haskell why learn it at all? Learning a language also involves learning the communities norms and accepted practices.
Re:Rust vs. Haskell by noloblo on Tuesday February 14, 2023 @10:26AM (#34790630)
What problems does haskell create How do Monad transformers solve it @jeremyjh
Re:Rust vs. Haskell by jeremyjh on Tuesday February 14, 2023 @10:38AM (#34790844)
The main problems are immutability and inability perform I/O outside the IO monad. To address immutability you have Monads like Reader, Writer, State which can give you a similar experience that you would have with mutable data and/or global variables. For example with the state monad you can have code like:

  runState do
    value <- get
    put counter+1

The problem comes when you also want to do IO with that state; if your code is in the IO monad it has no access to the State monad and can't call those methods. There are ways to work around that but monad transformers give you a StateT which can be applied to any base monad, including IO, giving you the capability of both.
Re:Rust vs. Haskell by jmaker on Tuesday February 14, 2023 @02:16PM (#34794463)
Wel IO is State, cf. https://hackage.haskell.org/package/transformers-0.6.1.0/doc...

You set up your pipeline in terms of monads and then when you want to execute it you run it in IO. You can generalize IO to MonadIO or define an alias to some transformer pinned at IO. It adds a Computational overhead. Transformers are a solution to monad composition which isn’t naturally possible.

Re:Rust vs. Haskell by jeremyjh on Tuesday February 14, 2023 @11:18PM (#34800045)
Yes and they are essential to working in serious, modern Haskell. You could never be an intermediate without know how to use them.
Re:Rust vs. Haskell by noloblo on Monday February 20, 2023 @09:25AM (#34868346)
Would it be possible to give an example of monad composition that shows both state and Io on one computation unit?
Re:Rust vs. Haskell by noloblo on Monday February 20, 2023 @09:26AM (#34868358)
Is there an example of StateT applied to IO? That's not too complex for python#++ devs?
Re:Rust vs. Haskell by jmaker on Tuesday February 14, 2023 @02:17PM (#34794476)
None. Transformers are a solution to the composability of monads.
Re:Rust vs. Haskell by mayoff on Tuesday February 14, 2023 @09:49AM (#34790084)
Java code is always in the IO and Except monads.
Re:Rust vs. Haskell by weavie on Tuesday February 14, 2023 @09:35AM (#34789872)
I would say using them is beginner->intermediate. Writing them is intermediate->advanced.
Re:Rust vs. Haskell by cosmic_quanta on Tuesday February 14, 2023 @09:41AM (#34789962)
That's a good distinction
Re:Rust vs. Haskell by jeremyjh on Tuesday February 14, 2023 @09:47AM (#34790058)
I'd agree in general and almost made this same point but it depends on what you are doing. If you write a transformer that is essentially just a specific kind of Reader (like ResourceT), then you can just follow existing examples and not really have to understand how to write all the instances yourself.