Side-Effect System in D

[Dukc]

On Wednesday, 27 March 2024 at 07:47:02 UTC, Per Nordlöw wrote:
> Would be awesome to have Koka's side-effect system in D.
>
> See 
> https://koka-lang.github.io/koka/doc/book.html#sec-semantics-of-effects.

Don't we have a pretty good appromixation of `pure`, well, 
`pure`? St can also be easily represented by giving the state 
object as an extra `ref` parameter.

As for `total`, I don't think it's practical. That would mean no 
divisions, no assertions, no normal array indexing.

Besides, often you do have values that are representable by types 
of the parameters but that indicate a bug in the caller side if 
they're ever passed. You'd want a total function only if what 
you're doing actually makes sense for all the possible (`@safe`) 
values. If that isn't the case, asserting on invalid values is 
the right thing to do as Walter always says, not coming up with 
some cover-up return value to make the function total.

For example, if you have a function computing an average over an 
integer array, it'd be a bad idea to make that total since you 
would have to return a made-up value for an empty array instead 
of asserting.

While there are certainly some cases where you could reasonably 
make a function total, like bitwise boolean logic, on the whole 
it's just not practical to attempt programming in a crash-safe 
manner in D. I don't have enough experience in Haskell to judge 
if it's practical there, but it at least gets closer. For the 
idea to be worthwhile, you need to be able to limit the possible 
values of variables with types in the majority of the cases. This 
means non-nullable and nullable types for everything, ints with 
value range information, float that can't be NaN, non-empty types 
for ranges, and so on. And it needs to be extremely easy to 
translate those types to each other.

D does not have that kind of type system and it doesn't look like 
a good direction of development for it. For example, because all 
D types need an `.init` value, it means a general-purpose 
non-empty range type would be very difficult to define in a 
practical manner. The language simply works very differently from 
what total programming style would ask for.