Hacker News Reader

D has a lot of these kinds of "effects", though they're called "attributes" [1] like "nothrow", "pure", "safe", "mustuse", "nogc"... there's also the "noreturn" type for functions that will never return [2] (infinite loop or throws).

[1] https://dlang.org/spec/attribute.html#return

[2] https://dlang.org/spec/type.html#noreturn

There are two aspects to effects as a language feature- first there is the runtime behavior, and then there is the type system. Ruling out categories of effects is the job of the type system, and you don't have to commit to (or avoid) any particular runtime approach to use it that way.

This is related to the vagueness of your two categories. While exceptions, yields, and awaits don't really make sense without a handler, all that matters to the type system is which operations an expression might perform in addition to producing a result of their primary type. Handlers only interact with the type system in the sense that they remove an effect from their handle-ee expression.

So even in a language that committed to coroutines as its approach handling effects at runtime, the type system could still track and rule out effects like divergence or system calls. (For what it's worth, nondeterminism, state, etc. can all also be defined in terms of handlers. And at the same time, though, unsafety is not an effect because it is not entirely captured by "can this expression perform operation X.")

This is one of the motivations of algebraic effects: you can have fine grained control over which effects are allowed.

Yeah, the whole blog post reads like "if you worked too much with a hammer, everything starts looking like a nail". In other words, it puts the cart before the horse.

Effects is a MUCH more general and powerful technique than coroutines. An effect system can help greatly with implementing a coroutine system (instead of dealing with the unfortunate type-level hack Rust uses), but trying to implement an effect system on top of a coroutine system will give you a very limited emulation in the best case and another incoherent mess in the worst.

It would've been really great if Rust had a proper effect system, but it's very hard to introduce it into an existing language similarly to how you can not easily introduce borrow checker to C/C++. The messy "keyword generics" proposals only serve as a good demonstration for this. So we probably have to wait for Rust 2 or a different successor language.

I would love something like this where to write a function with side effects I'd have to annotate it as such.

Then the compiler could recursively understand whether any given function is pure.

The solidity language for smart contracts works like this.

I write code like this every day in Haskell.

Any recommended further reading on how this effects are handled in Haskell?

You could look at the effectful library: https://hackage.haskell.org/package/effectful-core-2.2.1.0/d...

> Leftpad is an entirely pure, non-diverging function.

`leftpad(string, int) -> string` needs to allocate so not fully pure that way. You could pass in the resulting string but then it would have to mutate, which is not really pure either.

It would be pure in languages without manual memory management

Unless it can't allocate, and then the whole program terminates. There are unfortunately limitations everywhere.

Is it really worth worrying about? This strikes me as pedantic. Once a program can no longer allocate memory, it's very likely toast anyway.

Edit: @naasking, all good points. Still, isn't the general strategy to ensure memory isn't exhausted, rather than handling such a situation "gracefully", whatever that means? :)

It depends what your program is for. Some programs need guarantees because of bounded resources, so you may want resource allocation to be a visible effect (like embedded systems), or because you're running potentially untrusted code (like JS or WASM in a browser), or because you want sane failure handling (like running modules in a web server).

Graceful is a misnomer, but there are better versions. If you are day, a database server, and you run out of memory and die horribly, availability for all clients is compromised. If you begin rejecting queries or connections until memory js available at least some availability is maintained.

I don't follow, it seems like you're still be hosed in this scenario. What's the difference of stopping accepting connections and rejecting queries vs crashing out? Meaningful work cannot make progress when a busy dynamic system is OOM -- which a database is a prime example of.

Best to avoid the condition, or design the client side to handle the possibility the resource could be unavailable.

Of course as well as limiting the total amount of memory a running program is allowed to allocate, we can also limit how many CPU instructions it can execute and numerous other (OS dependent) resource uses. Accounting for this all operations are fallible, which no practical language copes with.

It's very normal in a Unix to be allowed to limit total runtime for example.

If the whole program terminates, the purity of the function is still intact, the computer just can't compute it :D

It’s certainly pure in the Haskell sense: the inputs are two immutable values, and the output is another immutable value. It’s even pure in some Rusty senses: it could take String or &str as input and returns a String — in a model where String is a value, it’s pure.

A lot of modern programming logically involves telling a computer to what to compute and not particularly caring how it gets computed. Yet we mostly lack a language in which one can specify computations and then then run the result portably and safely.

Hack programming language (Facebook's php++). They are called coeffects and can range from "this is pure with no side effect" to "this can modify local members" to "this has I/O".

> Leftpad is an entirely pure, non-diverging function. And I should be able to ask my language to enforce that, ideally with trivial code. Maybe even by default.

I think you can do this in Idris with "total" functions.

don’t forget unbounded loops diverge - while(true){} and fn f() {f()} - also impure are blocking “pure” computations like fib(50)

In proof languages where you want a proof that a function will succeed without running it, knowing that it doesn't diverge is important.

But if you're going to do the calculation, there's no difference between an infinite loop and a loop that finishes, but will take longer than you're willing to wait. Either way, it looks like the program hung.

So in practical programming languages, I'm not sure that the "diverge" effect is useful? You still need to kill it if it hangs. If it will take a long time, returning some kind of progress indicator would be nice. Maybe writing it as an iterator would help with that?

It may depend on what you mean by 'practical', perhaps, but in a Haskell-like language divergence (as opposed to induction) more or less takes the form "let x = x in x" with varying degrees of ceremony. If you can provide to the compiler that you don't have any such thing in your fragment of code it can omit black-hole updates and checks during garbage collection for a small (possibly negligible or nil, if divergence still exists in the language anyway) performance boost.

As you suggest, explicitly adding a provably-reducing value like a maximum iteration limit lets you show progress, give up at a "reasonable" time, and avoid divergence. This is how unlifted programming languages permit general recursion - that, and allowing inductive types to merely prove they're productive within a finite time bound (eg, a stream of values only needs to show it produces the next value eventually, not that it produces all values eventually).