• Per =?UTF-8?B?Tm9yZGzDtnc=?= (3/3) Mar 27 Would be awesome to have Koka's side-effect system in D.
• Timon Gehr (3/7) Mar 29 I also think that this is a good approach for effects. However, it
• Dukc (34/37) Mar 29 Don't we have a pretty good appromixation of `pure`, well,

Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:

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.

Timon Gehr <timon.gehr gmx.ch> writes:

On 3/27/24 08:47, 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.

I also think that this is a good approach for effects. However, it 
requires parametric polymorphism in the type system.

Dukc <ajieskola gmail.com> writes:

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.