On Monday, 8 March 2021 at 17:10:38 UTC, Timon Gehr wrote:
> On 08.03.21 16:39, deadalnix wrote:
>> On Monday, 8 March 2021 at 11:01:17 UTC, Timon Gehr wrote:
>>> On 02.03.21 22:05, deadalnix wrote:
>>>> I think it is hard too argue that D doesn't have enough feature at this time.
>>>
>>> OTOH, there is no pattern matching, in particular you can't pattern match tuples. Therefore, it is also very hard to argue that D is feature-complete. (Has it skipped leg day?)
>> 
>> While pattern matching would be nice, I place soundness above it.
>
> For me it's not even a close contender. There's no soundness now and soundness is much harder to achieve than (or even without) obvious fundamental features. In comparison, soundness almost seems like a lost battle at this point.
>
>> Plus, if you look at the SDC codebase for instance, you'll see that you can go pretty far as a library.
>
>
> auto firstThingSecondThing=query!((ref foo)=>tuple(foo.a, foo.b))(data);
> auto firstThing=firstThingSecondThing[0], secondThing=firstThingSecondThing[1];
>
> Huge pain.
>
>
> auto (firstThing,secondThing)=query!((ref foo)=>(foo.a, foo.b))(data);
>
> Much better.
>
> Whatever string mixin hack you can come up with is not good enough.

I agree. I also think the weird tuple situation we have now has to look bad from afar, e.g. we have Phobos tuples which aren't great, dmd tuples which are weird, AliasSeq, T... etc. Furthermore, I read your proto-DIP about Tuples, and I think it's a good step forward, but it strikes me that maybe we should just go the whole way and have first-class tuples (Even just as a direct rewrite to a struct would be a step forward in terms of allowing the kind of unpacking syntax that I would hope almost everyone wants).

On Monday, 8 March 2021 at 18:02:35 UTC, Max Haughton wrote:
> On Monday, 8 March 2021 at 17:10:38 UTC, Timon Gehr wrote:
>> [...]
>
> I agree. I also think the weird tuple situation we have now has to look bad from afar, e.g. we have Phobos tuples which aren't great, dmd tuples which are weird, AliasSeq, T... etc. Furthermore, I read your proto-DIP about Tuples, and I think it's a good step forward, but it strikes me that maybe we should just go the whole way and have first-class tuples (Even just as a direct rewrite to a struct would be a step forward in terms of allowing the kind of unpacking syntax that I would hope almost everyone wants).

Yeah, soundness is more important than features imo

On 09.03.21 09:32, Imperatorn wrote:
> On Monday, 8 March 2021 at 18:02:35 UTC, Max Haughton wrote:
>> On Monday, 8 March 2021 at 17:10:38 UTC, Timon Gehr wrote:
>>> [...]
>>
>> I agree. I also think the weird tuple situation we have now has to look bad from afar, e.g. we have Phobos tuples which aren't great, dmd tuples which are weird, AliasSeq, T... etc. Furthermore, I read your proto-DIP about Tuples, and I think it's a good step forward, but it strikes me that maybe we should just go the whole way and have first-class tuples (Even just as a direct rewrite to a struct would be a step forward in terms of allowing the kind of unpacking syntax that I would hope almost everyone wants).
> 
> Yeah, soundness is more important than features imo

It sounds nice, but I think it is just not true, and it has never been the philosophy driving D's design. Right now, D is unsound in various ways, but we like to use it anyway, because it has features.

Soundness is important, but I suffer more from lack of features than lack of full soundness. E.g., philosophically, assertion failures causing UB in @safe code is a terrible, unsound design, but in practice I can avoid it and I have given up on trying to make the point to Walter. On the topic of assertion errors: `in` contract inheritance catches AssertError. Is this an issue that's more important than built-in tuples just because it is a case of blatant unsoundness? Not even close.

I also think it is quite safe to assume that DMD will never implement any consistent semantics for the interaction of forward references and introspection (because it will never be the top-priority issue), but I don't want to give up on forward references nor introspection.

On Wednesday, 10 March 2021 at 02:46:26 UTC, Timon Gehr wrote:
>
> I also think it is quite safe to assume that DMD will never implement any consistent semantics for the interaction of forward references and introspection (because it will never be the top-priority issue), but I don't want to give up on forward references nor introspection.

I hope that we can fix that.
Any serious advance of meta-programming in D is basically not possible without having this issue fixed.
And I think that, slowly transitioning the compiler to an asynchronous task based system
(get resolution and semantic analysis to be based on co-routines);
can get us there.

On Wednesday, 10 March 2021 at 06:53:37 UTC, Stefan Koch wrote:
> On Wednesday, 10 March 2021 at 02:46:26 UTC, Timon Gehr wrote:
>>
>> I also think it is quite safe to assume that DMD will never implement any consistent semantics for the interaction of forward references and introspection (because it will never be the top-priority issue), but I don't want to give up on forward references nor introspection.
>
> I hope that we can fix that.
> Any serious advance of meta-programming in D is basically not possible without having this issue fixed.
> And I think that, slowly transitioning the compiler to an asynchronous task based system
> (get resolution and semantic analysis to be based on co-routines);
> can get us there.

Is that realistic for dmd?

On Wednesday, 10 March 2021 at 20:17:57 UTC, Max Haughton wrote:
> On Wednesday, 10 March 2021 at 06:53:37 UTC, Stefan Koch wrote:
>> On Wednesday, 10 March 2021 at 02:46:26 UTC, Timon Gehr wrote:
>>>
>>> I also think it is quite safe to assume that DMD will never implement any consistent semantics for the interaction of forward references and introspection (because it will never be the top-priority issue), but I don't want to give up on forward references nor introspection.
>>
>> I hope that we can fix that.
>> Any serious advance of meta-programming in D is basically not possible without having this issue fixed.
>> And I think that, slowly transitioning the compiler to an asynchronous task based system
>> (get resolution and semantic analysis to be based on co-routines);
>> can get us there.
>
> Is that realistic for dmd?

Let me say it like this.
I think It is more realistic than giving up on dmd.

On Wednesday, 10 March 2021 at 21:06:52 UTC, Stefan Koch wrote:
> On Wednesday, 10 March 2021 at 20:17:57 UTC, Max Haughton wrote:
>> On Wednesday, 10 March 2021 at 06:53:37 UTC, Stefan Koch wrote:
>>> On Wednesday, 10 March 2021 at 02:46:26 UTC, Timon Gehr wrote:
>>>> [...]
>>>
>>> I hope that we can fix that.
>>> Any serious advance of meta-programming in D is basically not possible without having this issue fixed.
>>> And I think that, slowly transitioning the compiler to an asynchronous task based system
>>> (get resolution and semantic analysis to be based on co-routines);
>>> can get us there.
>>
>> Is that realistic for dmd?
>
> Let me say it like this.
> I think It is more realistic than giving up on dmd.

I agree although maybe I should rephrase - what's the gameplan? Cull mutability first, then restructure, then go to some abstraction like coroutines?

On Wednesday, 10 March 2021 at 21:06:52 UTC, Stefan Koch wrote:
> On Wednesday, 10 March 2021 at 20:17:57 UTC, Max Haughton wrote:
>> Is that realistic for dmd?
>
> Let me say it like this.
> I think It is more realistic than giving up on dmd.

I only have questions about that idea of co-routines.

- would this really solve issues ?
- what is the idea on how to drive the co-routines ?
   - launch blindly new ones when the PASS value of a node is not sufficent ?
     and if so, how would that give different results of what is done actually ?
   - dont you rather think that this should be driven by a system of graph to
     determine the right order ?
- are there compilers for other other languages that are forward and implement this
  kind of "next gen" way of driving the semantic ?

There need to be some kind of proof showing the benefit. Pick an example an describe what is done for now, why this does not work then describe why this would work better with fibers.

On Wednesday, 10 March 2021 at 21:06:52 UTC, Stefan Koch wrote:
> On Wednesday, 10 March 2021 at 20:17:57 UTC, Max Haughton wrote:
>> On Wednesday, 10 March 2021 at 06:53:37 UTC, Stefan Koch wrote:
>>> On Wednesday, 10 March 2021 at 02:46:26 UTC, Timon Gehr wrote:
>>>>
>>>> I also think it is quite safe to assume that DMD will never implement any consistent semantics for the interaction of forward references and introspection (because it will never be the top-priority issue), but I don't want to give up on forward references nor introspection.
>>>
>>> I hope that we can fix that.
>>> Any serious advance of meta-programming in D is basically not possible without having this issue fixed.
>>> And I think that, slowly transitioning the compiler to an asynchronous task based system
>>> (get resolution and semantic analysis to be based on co-routines);
>>> can get us there.
>>
>> Is that realistic for dmd?
>
> Let me say it like this.
> I think It is more realistic than giving up on dmd.

A second front end effort could provide a number of benefits beyond those associated with hindsight and a clean sheet architecture.  Not the least of these is the ability to compare two implementations.

Whether it is worth redeploying some dmd resources to a second front end is a decision for those writing the checks (or donating their time) but here's a hypothetical that may help:  if you had abundant resources at your disposal would you restrict your efforts to dmd only?

I would not.  Given "abundant" resources, restricting efforts to dmd sounds much too conservative.  Also, to answer the next question, "abundant" for me means any amount of time that I have to dedicate to compiler work which, unfortunately, currently amounts to approximately a hill of beans (a few hours now and then exploring SDC, LLVM, MLIR, and SPIR-V).

Here's hoping "abundant" resources come in to view and/or incremental improvement of dmd leads towards simplicity and robustness.

On Wednesday, 10 March 2021 at 23:29:21 UTC, Basile B. wrote:
> On Wednesday, 10 March 2021 at 21:06:52 UTC, Stefan Koch wrote:
>> On Wednesday, 10 March 2021 at 20:17:57 UTC, Max Haughton wrote:
>>> Is that realistic for dmd?
>>
>> Let me say it like this.
>> I think It is more realistic than giving up on dmd.
>
> I only have questions about that idea of co-routines.
>
> - would this really solve issues ?
> - what is the idea on how to drive the co-routines ?
>    - launch blindly new ones when the PASS value of a node is not sufficent ?
>      and if so, how would that give different results of what is done actually ?
>    - dont you rather think that this should be driven by a system of graph to
>      determine the right order ?
> - are there compilers for other other languages that are forward and implement this
>   kind of "next gen" way of driving the semantic ?
>
> There need to be some kind of proof showing the benefit. Pick an example an describe what is done for now, why this does not work then describe why this would work better with fibers.

Just look at sdc if you want to have an example of what's better.
The main benefit of fibers is not that they magically resolve all the ordering issues,
the main benefit it that they allow you to cleanly suspend the resolving process and continue at a later time when it's dependencies are resolved.
The graph still needs to be explored and analyzed by the scheduler.

JAI uses a similar structure. called "queued".
Which essentially serve as scheduling units.

The issue it would surely resolve "right away" is the one of shared state and leakey managed context/scope. Since for fibers to work all the state has to be determined by the fiber stack.