If you could make any changes to D, what would they look like?

H. S. Teoh hsteoh at quickfur.ath.cx
Wed Oct 20 23:55:12 UTC 2021

On Wed, Oct 20, 2021 at 07:41:52PM +0000, Kagamin via Digitalmars-d wrote:
> Like many people here I tried to design my own language, but I noticed
> that I can't get (logically) puristic concepts into an adequate form.
> I grew suspicious it's because the problem domain itself is impure, so
> puristic concepts can't be adequate, and an adequate language should
> elegantly incorporate impurity instead of evading it at all wasteful
> costs. I also take this approach in program design, somehow a line is
> easy to see that the component shouldn't be more pure than this.

This is why I like D's approach to (functional) purity: it's defined in
terms of its effect on the outside world, rather than internal purity
(in the sense of a real functional language like Haskell).  As Andrei
once put it, you can have all the imperative, impure, dirty laundry you
want inside your function body, but as long as the outside world can't
see it, you're effectively a pure function to them.

Also, one of D's stated goals is to be a systems programming language,
in the sense of being able to implement the GC within the language
itself instead of resorting to some other language required to perform
the unsafe operations required to implement a GC. I.e., it's still D
under the hood, not some other language.  For this, there must be escape
hatches from things like @safe or immutable, since the GC must be able
to manipulate untyped memory without running afoul of immutability
(e.g., it must be able to cast mutable memory from its heap into an
immutable object during allocation, and vice versa during collection).
To user code, the memory is truly immutable, but the GC is actually
performing low-level casts to create it under the hood.

IOW, things like purity, immutability, etc., apply to the outward-facing
APIs, but the implementation need not be thus constrained as long as it
continues to fulfill the promises of attributes of the API.


Too many people have open minds but closed eyes.

More information about the Digitalmars-d mailing list