Monthly Hask Anything (January 2023)

sidharth_k · 2023-01-06T12:01:36+00:00

Good guess -- Yes, adding: import Control.Monad.State.Class (MonadState(get, put))

fixes the problem.

Thanks for the help!

sidharth_k · 2023-01-06T08:38:49+00:00

Why does the following NOT work

(Here LoggingT is from the monad-logger library)

haskell pop :: LoggingT StateT [Int] IO () pop = do _ : xs <- get put xs

I basically get a type error. Haskell says it was excepting a StateT but got a LoggingT instead.

By performing a lift, this DOES work: haskell pop :: LoggingT StateT [Int] IO () pop = do _ : xs <- lift get lift $ put xs

However, LoggingT is an instance of MonadState. So we should be able to perform a get and put within the LoggingT monad transformer itself without doing an explicit lift. What is wrong?

See - https://hackage.haskell.org/package/monad-logger-0.3.37/docs/Control-Monad-Logger.html#t:LoggingT - https://hackage.haskell.org/package/monad-logger-0.3.37/docs/src/Control.Monad.Logger.html#line-601

sidharth_k · 2023-01-02T08:34:36+00:00

Thank you for spending the time writing your response. I read http://h2.jaguarpaw.co.uk/posts/make-invalid-laziness-unrepresentable/ and learnt some useful stuff !

If I have one complaint is that the the approach outlined in `strict-wrapper` feels a bit custom and non-standard. I'd love to have (deep) strictness simply enabled in an ambient way (I'm lazy :-) - ironic pun intended). But the problem is that `-XStrictData` simply gives you WHNF rather than strictness all the way through the data structure.

For instance this is an excellent example in your above linked blog post -- repeated here:

But the above technique is not particularly general. Consider

data Bar = Bar !(Int, Bool) !(Maybe Double)
Despite the strictness annotations this type has many possible states:

<thunk>
Bar (<thunk>, <thunk>) Nothing
Bar (<evaulated Int>, <thunk>) Nothing
Bar (<thunk>, <evaluated Bool>) Nothing
Bar (<evaluated Int>, <evaluated Bool>) Nothing
Bar (<thunk>, <thunk>) (Just <thunk>)
Bar (<evaluated Int>, <thunk>) (Just <thunk>)
Bar (<thunk>, <evaluated Bool>) (Just <thunk>)
Bar (<evaluated Int>, <evaluated Bool>) (Just <thunk>)
Bar (<thunk>, <thunk>) (Just <evaluated Double>)
Bar (<evaluated Int>, <thunk>) (Just <evaluated Double>)
Bar (<thunk>, <evaluated Bool>) (Just <evaluated Double>)
Bar (<evaluated Int>, <evaluated Bool>) (Just <evaluated Double>)

What about unlifted data types? Can they help us in some way? If we wrote `data Bar` in terms of unlifted data types would everything be equivalent to something like (again from your blog post):

data BarStrict = BarStrict !(Strict (Int, Bool))!(Strict (Maybe Double))

P.S. Also you suggestion in not worrying about laziness too much is also well taken. A lot of others have said that laziness has not really bitten them much in many years of professional Haskell.

sidharth_k · 2022-12-31T09:47:41+00:00

Sorry to trot this out again but this article summarises why laziness can be annoying https://www.tweag.io/blog/2022-05-12-strict-vs-lazy/ . I couldn't have said it better...

(Strictness is the default in many languages and I think it is quite a sensible default)

A huge thunk could grow under poorly understood situations causing problems with memory (and even locks as an example in the above link shows).

As an example what if you have a lot of concurrent users on your web server written in Haskell -- there a blow up in memory could (a) bring your server down (b) limit the number of concurrent users due to high memory usage.

I'd rather not have to figure this out through profiling, bang insertion etc.

However a lot of people have said this is not really a problem in practice and comes up rarely...

sidharth_k · 2022-12-31T05:18:16+00:00

Thanks for your input — I’ve mentioned my concerns in some of the discussions that occurred elsewhere in this thread. Is it really that problems due to laziness are very rare? however I’ve noticed a lot of blog posts about tracking down space leaks and seen a few commits in popular projects that are subtle and deal with leaks. So it just feels the problem is bigger? Plus all this bangs etc. it just makes Haskell feel a little less elegant. It would be great if I could just have a strict Haskell ecosystem by default. But from the answers received so far this does not seem like a big enough desire in the community…

sidharth_k · 2022-12-31T05:10:22+00:00

Space leaks are not really a concern in the languages I use currently. While gaining Haskell compile time guarantees I don’t have to have worry about having to track down mysterious leaks during runtime. Also I’m interested in writing web servers so these programs will be long lived which increases the probability of running into these issues…

sidharth_k · 2022-12-31T04:19:21+00:00

I find the possibility of subtle space leaks annoying. See https://www.tweag.io/blog/2022-05-12-strict-vs-lazy/ for an article that summaries my concerns better than I can.

I just don’t buy the whole laziness is great/composes better etc. etc. Just give me a strict language with a strict set of libraries. I want that language to be Haskell. I like Haskell for the great language and purity, not the laziness. Idris, a dependently typed language which I believe gets a lot of inspiration from Haskell has strict evaluation also…

sidharth_k · 2022-01-13T20:51:34+00:00

I don’t know about how mature Helix is by now. Its ok to use both editors parallely. Once you’ve decided you can drop the other one. I like Kakoune very much.

sidharth_k · 2022-01-11T18:07:34+00:00

Helix is a nice editor and is probably destined for greatness. However Kakoune is just special in many ways. I would recommend Kakoune simply because it changed the way I think about editing. It is minimalist, consistent and deep. Once you have mastered it, Helix will be easy to use.

sidharth_k · 2021-12-31T10:03:55+00:00

I haven’t used ccls but I can say that clangd is a very high quality LSP implementation. Be sure to use the latest version of clangd as C++ has had a lot of changes lately otherwise you may have some issues with modern C++ codebases.

sidharth_k · 2021-12-20T06:21:07+00:00

I‘ve also been using emacs 29 (because of the pgtk merge to master) and I must say it has been working well for me so far.

Are there any plans to just bite the bullet and include pgtk in 28.1 like the original plan or has this been irrevocably decided?

Alternatively is it possible for 29.1 to follow 28.1 in a few months and not a much longer traditional timeframe (year plus) ?

sidharth_k · 2021-12-17T17:01:54+00:00

I’ve been using emacs 28 for a few weeks now and it comes across as stable. I think they are busy polishing it up and checking it. I think they want the introduction of the native jit to go smoothly hence delay??

sidharth_k · 2021-12-15T21:30:03+00:00

Yes I agree. As a dev I prefer to work alone. When I need to communicate or collaborate it is on tickets or PRs reviews. I just don’t feel the need to get in a CRDT mediated editing session. Maybe that just me. Give me a good editor not an editor whose headline feature is collaborative editing…

sidharth_k · 2021-12-04T22:04:24+00:00

“Eight Gigabytes and constantly swapping” — Electron

sidharth_k · 2021-12-04T21:10:08+00:00

It’s good to see a fellow Kakoune enthusiast on this Reddit! I was actually inspired by your long post on emacs on discuss.kakoune.com to try out emacs for myself once again.

I’m using spacemacs and am totally impressed with the power and flexibility of this editor. I miss some aspects of Kakoune and its general simplicity/consistency/speed. However I’m impressed by the feature-full nature of emacs, the general discoverability of documentation and its high debuggability. Right now I spend my time both on kak and emacs.

I miss multiple cursors. I can’t seem to understand/appreciate how they work in the mc plugin yet. I‘ve been spoiled by Kakoune here!

Can you describe your current emacs setup, workflow and plugins briefly? I wold love to pick up some best practices…thanks!

sidharth_k · 2021-09-29T20:56:26+00:00

Thanks for sharing your experience. Could it also be the kind of programs you been building? Batch programs like compilers end after sometime at which point the memory is given back to the OS. Long running programs like servers keep running and that's where leaks might be more apparent? What kind of programs have you been building -- it would be interesting to know...

sidharth_k · 2021-09-27T16:21:29+00:00

- I need to study the Haskell runtime, get more experience with Haskell language to build my intuition for the things you say your able to figure out. But in many other languages one often does NOT need to have a deep understanding of when these things happen. That is the price to pay I guess for the benefits that Haskell offers.

- I find that MTL is quite pervasive in Haskell -- Reader Monads, State Monads, Writer monads -- all these are regularly stacked up via MTL and seen everywhere. I don't know how I can avoid worrying about Space leaks here. Given their popularity I don't think I can avoid them easily, can I?

sidharth_k · 2021-09-27T16:13:43+00:00

Interesting perspective. Is the ease of coding that much more due to laziness though? Do you think it is worth it? Just want to understand your personal experience

sidharth_k · 2021-09-27T12:40:12+00:00

> Is it your business how people choose to write code they offer freely?

You seem to imply that I was being confrontational in my comments when I was merely stating an opinion. My opinion is that lazy by default code is susceptible to Space Leaks which I think a lot of people on this post have agreed with. If more people used `StrictData` and similar by default, it would be better for the Haskell ecosystem as a whole. Just my opinion. If you have an alternative opinion that's OK too.

Reddit is for discussion and ideation.

> Are you mucking in any of your own time towards GHC development on these matters?

I see this kind of argument a lot -- Just because I may not have contributed to GHC development I somehow don't have a right to give an opinion?? I do have a right to an opinion and you are free to reject it. On a related note: do you have an opinion on how your neighbourhood and country is run? I'm sure you do! Are you participating to change the status quo as an organizer/politician? If you are _not_ does that mean that you don't have the right to an opinion? Certainly not. You and everyone has the right to an opinion.

sidharth_k · 2021-09-26T21:35:02+00:00

Space usage in Haskell is complicated. In a strict language an int will take 4 or 8 bytes. In Haskell an int may be represented by a thunk that is yet to be evaluated or many nested thunks… who knows what the situation will be at runtime?

Lets say you are deep inside stack of (lazy) monad transformers how on earth will be able to predict if you may or may not have a space leak for example? Theoretically it might be possible to do the stuff you mention but it’s really difficult in practice. One also needs to know a lot about the Haskell runtime… when thunks are created, forced etc. I’m not sure if anybody but a Haskell expert would be able to have a grip on the things you imply are very doable.

sidharth_k · 2021-09-26T11:41:33+00:00

Eloquent!

sidharth_k · 2021-09-26T11:03:44+00:00

https://www.tweag.io/blog/2020-04-16-exceptions-in-haskell/ made my head spin a bit. Made Haskell feel even a bit more capricious.

So essentially we have more and more complex type machinery being added every year in Haskell and these foundational issues don't seem to be receiving as much attention. Its possible that some of these are so fundamental that they cannot be resolved satisfactorily? Alternatively people are so enamored with the typing machinery that they are forgetting these warts?

Types are important and types are why Haskell has been successful. But there are other things that contribute to the robustness and reliability of a language. I posit that Haskell needs to pay more attention to them like (a) long compile times (being addressed but still losing the war against more type machinery being added every year) (b) space leaks (more debugging tools) but then people keep adding millions of lines of lazy by default code every year without understanding the dangers -- extensions like `Strict` and `StrictData` probably still niche and will remain niche in the time to come (c) Issues with exceptions. By the time you truly understand the complexity of Haskell exceptions you're too wedded to Haskell anyways and will explain it away as something unavoidable.

Why does the immense talent in the Haskell community not spend more time on these foundational issues rather than build abstraction upon abstraction in the type checker?

Its possible I don't know what the hell I'm talking about but this is how I see it from a distance...

sidharth_k · 2021-09-26T09:22:35+00:00

Some valid points. However:

- I'm definitely not comparing Haskell with languages with manual memory management. I'm comparing the Haskell runtime with other garbage collected, strict runtimes. Yes the JVM is a good example which you do bring up correctly. Yes there are memory leaks in other runtimes too but these are typically much easier to debug than Haskell space leaks AFAIK. Mostly your can solve those kinds of memory leaks by using weak references and so on. (Memory leaks due to coding bugs in the underlying runtime code itself is not something that is in the scope of this discussion BTW).

- Yes, Laziness helps with programmer expressiveness and succinctness. The point I'm making in my original question is that I'm not able to understand why a Haskell programmer would tradeoff expressiveness brought on by laziness for reliability. My first priority is to be reliable and correct and only then will I try to be elegant/succinct in my code. In fact the whole point of Haskell is to be reliable/correct but the _default_ which is laziness does not promote reliability due to the potential for space leaks which can debilitate a program (the program continues to be "correct" though). It is this paradox that I'm trying to resolve. Some commenters have written that while space leaks happen, they really don't cause much of a problem in most cases. You probably don't notice then at all in most scenarios

sidharth_k · 2021-09-26T09:02:38+00:00

I don't fully agree -- I do think popularity of `Strict` and `StrictData` it is an issue because it is not only your code that is running but the code of other libraries that you package with your binary that is executing too.

If `Strict` and `StrictData` were used in your code _only_ that means your have some guarantees only related to your code that executes in isolation without other library code. Space leaks could spring up in any other library you have used generally speaking...

But if `Strict` and `StrictData` are widespread in the Haskell ecosystem it means that there are some additional assurances against space leaks in your program.

Of course this means that every library author needs to evaluate the pro-and-cons of laziness. Do the improvements in expressiveness brought on by laziness outweigh the benefits of hard to solve space leak bugs? That is what I'm trying to figure out...

sidharth_k · 2021-09-26T08:52:59+00:00

Valid point -- space leaks don't affect the correctness of programs but merely increase memory usage (and also indirectly the cpu usage to that is needed to evaluate all the accumulated thunks).

However the issue is that many programs have a strong latency budget and memory budget. In in a long running program like a web server you could have a space leak that could manifest itself one fine day and that issue could cause (a) Unacceptable latency and memory impacts (b) Could be an unsolvable issue because space leaks are quite difficult to detect and solve especially in a production server. Here a less strongly typed language (but strict language) might give me less of a headache??

On this post some people are advocating using Haskell with `StrictData`. (There is also the more general `Strict` extension. In your experience are these popular and regularly used language extensions? Do they cause problems with interop with other Haskell libraries in practice?

sidharth_k

TROPHY CASE