www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - ImportC shows the way to D3?

reply claptrap <clap trap.com> writes:
So if D can "import" C code then could the same mechanism be used 
to move to D3? Have the compiler compile D2 and D3 code to the 
same AST?

Disclaimer : I dont know exactly how ImportC works but it sounds 
like it compiles C code into the same AST that D code uses. Then 
its all compiled the same.

yeah I know D3... but it could be a way to introduce breaking 
changes without too much pain?

Surely i cant be the only person who's thought of this?
Jun 20 2022
next sibling parent reply bauss <jj_1337 live.dk> writes:
On Monday, 20 June 2022 at 08:05:38 UTC, claptrap wrote:

 So if D can "import" C code then could the same mechanism be 
 used to move to D3? Have the compiler compile D2 and D3 code to 
 the same AST?

 Disclaimer : I dont know exactly how ImportC works but it 
 sounds like it compiles C code into the same AST that D code 
 uses. Then its all compiled the same.

 yeah I know D3... but it could be a way to introduce breaking 
 changes without too much pain?

 Surely i cant be the only person who's thought of this?


The only problem I see is how will you differentiate a module 
from D2 with a module from D3?

At least how would you do that without having to specify that for 
each source file that it belongs to either D2 or D3, because I 
can't really seeing it being automated easily.
Jun 20 2022
parent claptrap <clap trap.com> writes:
On Monday, 20 June 2022 at 08:19:36 UTC, bauss wrote:

 On Monday, 20 June 2022 at 08:05:38 UTC, claptrap wrote:

 So if D can "import" C code then could the same mechanism be 
 used to move to D3? Have the compiler compile D2 and D3 code 
 to the same AST?

 Disclaimer : I dont know exactly how ImportC works but it 
 sounds like it compiles C code into the same AST that D code 
 uses. Then its all compiled the same.

 yeah I know D3... but it could be a way to introduce breaking 
 changes without too much pain?

 Surely i cant be the only person who's thought of this?


 The only problem I see is how will you differentiate a module 
 from D2 with a module from D3?

 At least how would you do that without having to specify that 
 for each source file that it belongs to either D2 or D3, 
 because I can't really seeing it being automated easily.


you'd have to manually differentiate, and do it in a way that 
existing code is unaffected, so mark D3 files with a different 
file extension, like .d3?
Jun 20 2022
prev sibling next sibling parent reply IGotD- <nise nise.com> writes:
On Monday, 20 June 2022 at 08:05:38 UTC, claptrap wrote:

 So if D can "import" C code then could the same mechanism be 
 used to move to D3? Have the compiler compile D2 and D3 code to 
 the same AST?

 Disclaimer : I dont know exactly how ImportC works but it 
 sounds like it compiles C code into the same AST that D code 
 uses. Then its all compiled the same.

 yeah I know D3... but it could be a way to introduce breaking 
 changes without too much pain?

 Surely i cant be the only person who's thought of this?


I think you come with a good suggestion and we need D3 as a more 
disruptive platform in order move the language forward. What you 
suggest is similar to C++ with version switches (ex. -std=c++20).

I suggest an alternative approach than with the DIPs we have 
today. With D3 we have a lower threshold what we can add. 
Depending on how successful a new feature is, the feature can be 
considered to be migrated to D2 so we can have a "migration DIP".

Right now the project is stale which is understandable as D2 
should be somewhat stable. We need D3.
Jun 20 2022
parent forkit <forkit gmail.com> writes:
On Monday, 20 June 2022 at 08:26:35 UTC, IGotD- wrote:

 ..
 I think you come with a good suggestion and we need D3 as a 
 more disruptive platform in order move the language forward. 
 What you suggest is similar to C++ with version switches (ex. 
 -std=c++20).

 I suggest an alternative approach than with the DIPs we have 
 today. With D3 we have a lower threshold what we can add. 
 Depending on how successful a new feature is, the feature can 
 be considered to be migrated to D2 so we can have a "migration 
 DIP".

 Right now the project is stale which is understandable as D2 
 should be somewhat stable. We need D3.


+1

Finally, a vision of how to move D in the forward direction!

Personally ;-) .. for D3, I'd start the 'breaking changes' by 
ensuring the language provides support for a proper class type 
(rather that Walter's interpretation of it), and, one that can be 
checked by the compiler.

i.e private means private!

Add an internal or something, so the default in a compilation 
unit (a module) is internal. You get the same thing as you 
currently have. Just make sure you have the option to declare a 
member private, and override that default.

I'd also set up a new offical organisational mandate, to ensure 
nobody, not even Walter, can arbitrarily add something to the 
language or the compiler, on a whim. Anyone that fails to comply, 
is booted out!

Then, and only then, will I consider using D again.
Jun 20 2022
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 20 June 2022 at 08:05:38 UTC, claptrap wrote:

 So if D can "import" C code then could the same mechanism be 
 used to move to D3? Have the compiler compile D2 and D3 code to 
 the same AST?

 Disclaimer : I dont know exactly how ImportC works but it 
 sounds like it compiles C code into the same AST that D code 
 uses. Then its all compiled the same.

 yeah I know D3... but it could be a way to introduce breaking 
 changes without too much pain?

 Surely i cant be the only person who's thought of this?


Compiling to the same AST does not allow you to change semantics 
without ending up with more complex compiler internals. So you 
are limited to smaller semantic adjustments and syntax.

I've suggested somewhere else that if DMD implemented a high 
level IR between frontend and backend then you could compile D2 
and D3 to the same high level IR.

But you still have to replicate templates in both your D2 and D3 
code bases as you don't want to do D-style meta programming in 
the high level IR that sits before the backend. You also cannot 
just combine D3 with D2 templates when D2 is capable of 
introspection.

If fixing bugs and completing the semantics of D2 is time 
consuming, why would you make it even more difficult to achieve 
by merging D3 into the D2 frontend? Yes, this also applies to 
"import C". It was done at the wrong time. The internals should 
have been redesigned first to handle it gracefully.
Jun 20 2022
parent reply claptrap <clap trap.com> writes:
On Monday, 20 June 2022 at 08:46:25 UTC, Ola Fosheim Grøstad 
wrote:


 Compiling to the same AST does not allow you to change 
 semantics without ending up with more complex compiler 
 internals. So you are limited to smaller semantic adjustments 
 and syntax.

 I've suggested somewhere else that if DMD implemented a high 
 level IR between frontend and backend then you could compile D2 
 and D3 to the same high level IR.

 But you still have to replicate templates in both your D2 and 
 D3 code bases as you don't want to do D-style meta programming 
 in the high level IR that sits before the backend. You also 
 cannot just combine D3 with D2 templates when D2 is capable of 
 introspection.

 If fixing bugs and completing the semantics of D2 is time 
 consuming, why would you make it even more difficult to achieve 
 by merging D3 into the D2 frontend? Yes, this also applies to 
 "import C". It was done at the wrong time. The internals should 
 have been redesigned first to handle it gracefully.


Well if that's the case an experimental branch where the 
internals are redesigned, and if/when that's successful you work 
on D3, but you'd keep the current vanilla D2 branch as the main 
compiler until such time as the experimental/D3 one is ready for 
prime time.
Jun 20 2022
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 20 June 2022 at 23:29:04 UTC, claptrap wrote:

 Well if that's the case an experimental branch where the 
 internals are redesigned, and if/when that's successful you 
 work on D3, but you'd keep the current vanilla D2 branch as the 
 main compiler until such time as the experimental/D3 one is 
 ready for prime time.


Either that or start over from scratch (or using SDC) using the 
existing code base as an inspiration. Doable if you position D3.0 
as having a smaller and more focused scope. I.e leave out all 
features that can be done with meta programming.
Jun 21 2022