Have also wondered how Haskell would be. From my limited understanding it’s one of the few languages whose compiler enforces functional purity. I’ve always liked that idea in theory but never tried the language

▲

ruszki 4 hours ago | parent | next [-]

You can write in it like in imperative languages. I did it when I first encountered it long time ago, and I didn’t know how to write, or why I should write code in a functional way. It’s like how you can write in an object oriented way in simple C. It’s possible, and it’s a good thought experiment, but it’s not recommended. So, it’s definitely not “enforced” in a strict sense.

▲

squeegmeister 3 hours ago | parent [-]

Isn’t code in Haskell pure by default and you have to use special keywords to have code with side effects?

	▲	lock1 2 hours ago \| parent \| next [-]
		There's no special keyword, just a "generic" type `IO<T>` defined in standard library which has a similar "tainting" property like `async` function coloring. Any side effect has to be performed inside `IO<T>` type, which means impure functions need to be marked as `IO<T>` return. And any function that tries to "execute" `IO<T>` side effect has to mark itself as returning `IO<T>` as well.
	▲	gf000 2 hours ago \| parent \| prev [-]
		It's pure even with side effects. You basically compose a description of the side effects and pass this value representing those to the main handler which is special in that it can execute the side effects. For the rest of the codebase this is simply an ordinary value you can pass on/store etc.

▲

0x3f 4 hours ago | parent | prev [-]

I think the intersection of FP and current AI is quite interesting. Purity provides a really tightly scoped context, so it almost seems like you could have one 'architect' model design the call graph/type skeleton at a high level (function signatures, tests, perf requirements, etc.) then have implementers fill them out in parallel.

	▲	iddan 4 hours ago \| parent [-]
		Also LLMs don’t mind repeating params for each child call. Pretty neat