November 24

On Tuesday, 23 November 2021 at 22:40:20 UTC, Ola Fosheim Grøstad wrote:

>

I would strongly favour simple schemes. So I'd rather see actor-local GC + ARC (without cycle detection).

That's only simple because it's just a vague idea in your head. See for example, https://www.ponylang.io/media/papers/orca_gc_and_type_system_co-design_for_actor_languages.pdf for a real implementation...

November 24

On Wednesday, 24 November 2021 at 10:29:54 UTC, zjh wrote:

>

On Wednesday, 24 November 2021 at 10:23:22 UTC, Gleb wrote:

>

In general, the absence of bindings to Qt and the
laboriousness of creating bindings to ordinary libraries is already a huge stopper.

QtE5.

Yes. And nope.
It's very incomplete. Unfortunately.
It's impossible to use basic popular widgets, like QCustomPlot, for example.

November 24

On Wednesday, 24 November 2021 at 10:40:39 UTC, IGotD- wrote:

>

On Wednesday, 24 November 2021 at 10:23:22 UTC, Gleb wrote:

>

There are no full-fledged signals --- slots with the ability to exchange
data between threads (in the style of Qt) => whole familiar sections
immediately drop out.

D has a native message system between threads. Qt signals is a special case as it also can be used in the same thread and then it is just a function call. Also there are syntax sugar for declaring Qt signals in C++.

I don't know any language that natively implements signals as Qt does.

Yes.But see:
There is not any standard (or well-known) library with some functionality like Qt provide (non-GUI part). So methods that good lies to sig-slot paradigm can not be simply expressed in D. Sadly...

November 24

On Wednesday, 24 November 2021 at 10:40:39 UTC, IGotD- wrote:

>

On Wednesday, 24 November 2021 at 10:23:22 UTC, Gleb wrote:

>

There are no full-fledged signals --- slots with the ability to exchange
data between threads (in the style of Qt) => whole familiar sections
immediately drop out.

D has a native message system between threads. Qt signals is a special case as it also can be used in the same thread and then it is just a function call. Also there are syntax sugar for declaring Qt signals in C++.

I don't know any language that natively implements signals as Qt does.

And yes, it is absolutely certain that Phobos should include a message loop, highly desirable in the form of slot -- signals.

November 24

On Wednesday, 24 November 2021 at 11:19:09 UTC, Araq wrote:

>

On Tuesday, 23 November 2021 at 22:40:20 UTC, Ola Fosheim Grøstad wrote:

>

I would strongly favour simple schemes. So I'd rather see actor-local GC + ARC (without cycle detection).

That's only simple because it's just a vague idea in your head. See for example, https://www.ponylang.io/media/papers/orca_gc_and_type_system_co-design_for_actor_languages.pdf for a real implementation...

You are very presumptuous. Pony is a high level language.

November 24

On Wednesday, 17 November 2021 at 07:25:46 UTC, Robert Schadek wrote:

>

Also you can not have string interpolation without dynamic memory.

With dynamic memory I presume you mean GC-allocated memory. dynamic memory allocation is broader term and covers cases such

@safe pure unittest
{
    scope a = [1, 2];
}

which doesn't use the GC, thanks to a being scope.

However, note that both

@safe pure @nogc unittest
{
    scope a = [1, 2];
}

and

@safe pure @nogc unittest
{
    string x, y;
    scope a = x ~ y;
}

currently fail but I don't think they should because their end-result a has life-time limited to the unittest block. And therefore having deterministic destruction and without the need for the GC and should therefore be allowed in betterC.

November 24

On Wednesday, 24 November 2021 at 11:36:21 UTC, Gleb wrote:

>

functionality like Qt provide (non-GUI part). So methods that good lies to sig-slot paradigm can not be simply expressed in D. Sadly...

Not sure what you mean, but I don't think "slot-signals" are in high demand. I've certainly never felt a need to use:

https://dlang.org/phobos/std_signals.html

But if you want to improve on it, you probably could. So it is really up to you, if you are interested.

November 24
On Tue, Nov 23, 2021 at 07:22:11PM +0000, Araq via Digitalmars-d wrote: [...]
> As long as D doesn't distinguish GC'ed pointers from non-GC'ed pointers and allows for unprincipled unions I fail to see how it's "good news".

Hmm you're right, unprincipled unions throw a monkey wrench into the works. :-/  I don't see GC'ed vs. non-GC'ed pointers as a problem; the collector could tell them apart from their values (whether they fall into the range of GC-managed heap), just like is done with today's D's GC.


> Multi-threading is also a problem, in Nim we can track global variables and pass "isolated" subgraphs between threads so that the RC ops do not have to be atomic.
[...]

Having thread-local heaps would solve this, except for immutable which is implicitly shared.  Well, that, and the mess with `shared` and passing stuff between threads... Hmm.

I wonder if this could be addressed by repurposing `shared` to qualify data that could have references from multiple threads. This would make it a LOT more useful than it is now, and would let us do ORC-like memory management with tracing of non-shared data without locks. Shared stuff would have to be handled differently, of course.


T

-- 
English is useful because it is a mess. Since English is a mess, it maps well onto the problem space, which is also a mess, which we call reality. Similarly, Perl was designed to be a mess, though in the nicest of all possible ways. -- Larry Wall
November 24
On Wednesday, 24 November 2021 at 14:13:35 UTC, Per Nordlöw wrote:
> However, note that both
> *snip*
> currently fail but I don't think they should because their end-result `a` has life-time limited to the unittest block. And therefore having deterministic destruction and without the need for the GC and should therefore be allowed in betterC.

The latter examaple requires potentially unbounded space, so it cannot be stack-allocated.
November 25
On Wednesday, 24 November 2021 at 17:56:57 UTC, Elronnd wrote:
> On Wednesday, 24 November 2021 at 14:13:35 UTC, Per Nordlöw wrote:
>> However, note that both
>> *snip*
>> currently fail but I don't think they should because their end-result `a` has life-time limited to the unittest block. And therefore having deterministic destruction and without the need for athe GC and should therefore be allowed in betterC.
>
> The latter examaple requires potentially unbounded space, so it cannot be stack-allocated.

Ignoring that the example probably could be stack allocated (if you stick a branch in there) in practice, the key thing with this scope transformation isn't stack allocation but rather moving the allocation anywhere other than the GC.
2 3 4 5 6 7 8 9 10 11 12 13