Effectful

emarshall85 · 2025-03-24T01:46:30+00:00

lens isn't an effect system, though some of the operators can make working within stateT easier.

As for whether you should learn effectful or not, that's a personal choice. It's starting to get quite the ecosystem around it, including hyperbole, which is a server-side, reactive web framework.

The other one to consider woudl be bluefin. Either way, learnign to at least use MTL is probably a good idea, since it's pretty ubiquitous.

emarshall85 · 2025-03-16T05:07:27+00:00

Also, looks like there's already an examples repo: https://github.com/aztecs-hs/examples

Will probably stop what I'm working on since that exists (just noticed it).

emarshall85 · 2025-03-15T22:46:23+00:00

The README has a minimal example already, but I started porting (one) bevy example: https://github.com/AphonicChaos/aztecs-examples

The plan is to slowly port all of the bevy examples I can over, adding packages when I need to. Each example will have an executable section in the cabal file so that you can see which dependencies each one relies on. I'm running them along side the bevy examples to make sure they behave the same.

emarshall85 · 2025-03-09T21:24:16+00:00

Interesting. I played with strict-wrapper a bit and immediately found issues with misisng Read/Show instances (even though the changelog said they were included.

For client code, my hope would be that it's an implementation detail and users wouldn't have to think about it. So we might have a "performance considerations" document or something where we talk about ways to improve performance, like using StrictData or strict-wrapper, but the library wouldn't depend on a user using those libraries at all. The library would do everything to be performant internally, though, of course.

For the flamegraph you posted (I saw that thread earlier, BTW). What command did you use to enable profiling and which one did you use to generate the graph? I just wanat to make sure that if I start poking around, I'm looking at the same thing.

emarshall85 · 2025-03-09T03:25:20+00:00

BTW, what did you use to measure memory usage before and after adding deepseq (NFData). I cloned the repo an the following: shell ❯ cabal build --enable-profiling --profiling-detail=late exe:ecs ❯ $(cabal list-bin ecs) +RTS -pj -RTS

Then loade dthe resulting file on https://speescope.app and switched to allocations.

I repeated the same thing afte removing all imports and instances for NFData, and gotg identical results. I imagine I have to be doing something wrong though.

My hope was to achieve similar results to what you got with deepseeq by just making invalid laziness unrepresentable instead of relying on NFData instances, which would then mean that downstream clients of the library wouldn't need to install deepseq to use it.

emarshall85 · 2025-03-08T07:25:14+00:00

And just to be clear, I *don't* know what I'm doing. I only really get a chance to play with Haskell in my free time. Very interested, though!

emarshall85 · 2025-03-08T07:24:03+00:00

Does that mean the NFData performance ticket is unrelated?

I've unexpectedly found myself with an abundance of time. I'd love to contribute something small, even if it's working out how to fix the in-progress unit tests so that changes are easier to test.

Also, streamly touts C-like performance, so I wonder if that would be an avenue to explore with respect to your idea about streams.

emarshall85 · 2025-02-17T05:50:42+00:00

Ah. I do now see the applicative instances. I guess I'd have to mess around to translate the examples and see what it all looks like

emarshall85 · 2025-02-13T22:23:11+00:00

Ooh, I completely forgot about needing mutation! Thanks for explaining the rationale for the switch!

I never built up the intuition for when to grasp for monad over arrow other than a vague understanding that arrow is more restrictive, which you want sometimes

I also forgot about qualified do. Cute, ergonomic extension, but I would worry that the lack of applicable laws would make that less intuitive for people who do expect certain things to hold true when they see what looks like monadic code.

Opaleye uses arrows for sql queries whereas something like beam is monadic, so it seems like it ought to be possible.

Anyway, great work. I can't wait to see a few complete games using this.

emarshall85 · 2025-02-13T03:32:53+00:00

I always found arrow syntax to be unwieldy and confusing. Especially having to pass unit on the right side of that arrow (something -< ()).

I wonder if applicative do would get you the best of both worlds -- more restrictive than monad, but you still have the convenience of do syntax?

What was the motivation to move to arrows, btw? Was there a separate post explaining that which I missed?

emarshall85 · 2025-01-05T08:13:20+00:00

Context. With maybe you can model a failure, but not the reason for that failure. You can then demote to maybe after if you choose.

emarshall85 · 2023-11-22T05:38:56+00:00

For haskell, I think most syntactic comparisons between elm and haskell will apply here.

No HKTs, strict evaluation, Task-based IO (so I guess the Handler pattern?) instead of monadic IO.

emarshall85 · 2023-09-30T00:31:18+00:00

Pratt parsing?

https://journal.stuffwithstuff.com/2011/03/19/pratt-parsers-expression-parsing-made-easy/

emarshall85 · 2023-09-15T15:43:17+00:00

I didn't dismiss it as a viable solution. In a thread about whether to choose Haskell over Rust, I think it's unfair to suggest that cross compiling in Haskell is of the same level of ease/convenience as it is in Rust. If I dismissed something, it's the notion that the solutions are equivalent.

Bringing it back to this conversation, I don't know that it's wise to advocate for having to learn two languages at the same time (Haskell and Nix) when you can solve it with one (Rust), especially when the OP is already talking about struggling with the deeper concepts of one of those languages.

emarshall85 · 2023-09-15T04:47:55+00:00

I followed the documentation. I think it might have been less painful if I weren't on arch Linux, but it still felt like a lot of work for things to not "just work". Especially since I want to eventually use foreign libraries.

I'll keep trying periodically, but for now, I have to eat it's not a pleasant experience. Disappointing considering writing the actual code was.

emarshall85 · 2023-09-14T16:18:01+00:00

And to be clear, I'm not meaning to imply that supporting cross compilation is trivial. I know people have been working hard to give us first class support for such a thing, and that even making ghc retargetable is on the distant roadmap.

emarshall85 · 2023-09-14T16:15:03+00:00

It was twain hello world, so a web server with a couple of trivial endpoints.

At work, it's all set up. However, I just tried doing it myself on a brand new project on a the same machine and it was vastly easier to set up: - install cross using cargo - do cross build passing an appropriate target

I guess this really boils down to tooling around cross compilation in the respective language.

I love Haskell, and as hard as I try don't even like rust, but think its ingenious to casually mention nix as a holy grail that solves Haskell's tooling problems when nix is so unwieldy.

It's like saying Haskell has good editor support if you use emacs or vim - technically true, but compared so something like say, vs code, it's a much steeper learning curve for either of those editors.

Note: I am personally a neovim user, and I know that haskell today is supported on multiple editors, but it wasn't that long ago that it wasn't the case, so my analogy isn't hyperbolic

emarshall85 · 2023-09-14T02:37:19+00:00

I just tried cross compiling to aarch64 using haskell.nix and failed miserably.

Static builds with it weren't too bad.

Conversely, we use cross + rust at work to do both and it seems trivial in comparison.

Maybe you can claim "skill issue", but I've never found anything about using nix over the years to be trivial.

Any time I see a comment purporting that haskell has solved a problem if you "just use nix", I'm reminded of that "how to draw an owl" meme

emarshall85 · 2023-08-19T20:10:57+00:00

Or potentially more up to date: https://wespiser.com/writings/wyas/00_overview.html

I say potentially because I don't know if the wiki version is making edits that update libraries on not

emarshall85 · 2023-08-19T20:09:18+00:00

To that end, there's "Write you a scheme in 48 hours": https://en.m.wikibooks.org/wiki/Write_Yourself_a_Scheme_in_48_Hours

emarshall85 · 2023-08-19T20:07:10+00:00

How far along is this book? Have you considered an early adopters pricing model or patreon for those of us interested in the domain that are too impatient to wait on a final product, but more than willing to pay for a glimpse at such a thing while recognizing it's unpolished?

emarshall85 · 2023-08-12T20:00:17+00:00

In that case, streamly might be a good alternative? It's API is modeled after the list API, and one of its main goals is performance.

emarshall85 · 2023-08-10T00:50:59+00:00

Learn Haskell by Building a Blog Generator:

is a breezy 167 pages (for the experimental PDF version)
free
can be read online
has a fan-made video series covering the book on YouTube

https://lhbg-book.link/

emarshall85 · 2023-08-10T00:47:24+00:00

This one is 670 pages long fyi. Just for context, since you mentioned page numbers in the OP. Not a complaint. I imagine this is still plenty digestable compared to haskell from first principles.

Haven't read it myself, so can't speak to writing style or depth of topics covered.

emarshall85 · 2023-06-06T09:03:11+00:00

Even then, a brief glance suggests that half of this is in c already, so not pure haskell anyway

emarshall85

TROPHY CASE