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.


T

-- 
Too many people have open minds but closed eyes.

On Wednesday, 20 October 2021 at 21:05:44 UTC, Ali Çehreli wrote:
> Me neither because I was following convention in C++: "Pass inherited types by reference because there is slicing." That rule renders C++ classes (and structs) of inheritance hierarchies "reference types". I like D's (and Java's and C#'s) approach here.

That is the classical Simula model. Simula did however use ":-" for reference assigment and ":=" for value assignment, so it was always clear to the user that objects followed reference semantics.

On Thursday, 21 October 2021 at 20:26:47 UTC, Sebastiaan Koppe wrote:
> Unique/Isolated; A way to declare or require that an object (both struct and class) cannot have more than one reference.
>
> For instance, it is perfectly fine to move an AA across thread boundaries if there is only one reference to it. But in the general you can't because you can't proof there is.
>
> This touches on @live a bit, but @live is put on functions whereas I want it on objects (class+structs).

It's the difference between linear types and uniqueness types.  'Linear' is part of the api contract of the callee: it promises not to change the number of references to an object.  While 'unique' is part of the api contract of the caller: it promises an object to which there is only one object.