www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - What would a minimal subset of D look like?

reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
I am wondering, what would a minimal subset of D look like?  
Something that would make the syntax/semantics look simple to a 
newbie wanting to do embedded programming, yet be useful.  Let's 
assume that we are already limited to the better-C subset.

What are the "must have" features?  I assume that "static if" 
ranks high for most D users, but what else?
Jun 21
next sibling parent reply Mike Franklin <slavo5150 yahoo.com> writes:
On Saturday, 22 June 2019 at 06:55:40 UTC, Ola Fosheim Grøstad 
wrote:
 I am wondering, what would a minimal subset of D look like?  
 Something that would make the syntax/semantics look simple to a 
 newbie wanting to do embedded programming, yet be useful.  
 Let's assume that we are already limited to the better-C subset.

 What are the "must have" features?  I assume that "static if" 
 ranks high for most D users, but what else?
I have a few ideas for removing many features of D, preferring library implementations instead, but base on your preface, I think that is a different goal than what you have in mind. I get the impression you're looking for something more like Microsoft's Bosque Language: https://github.com/Microsoft/BosqueLanguage If you want something simple for a newbie, I think any metaprogramming features are off the table. But maybe I don't understand what you're really looking for. Mike
Jun 22
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 22 June 2019 at 08:41:36 UTC, Mike Franklin wrote:
 Microsoft's Bosque Language:  
 https://github.com/Microsoft/BosqueLanguage
Thanks! Looks like an interesting project. The overview page seems to provide room for expansion so I assume they are going to extend the language quite a bit: https://github.com/microsoft/BosqueLanguage/blob/master/docs/language/overview.md
 If you want something simple for a newbie, I think any 
 metaprogramming features are off the table.  But maybe I don't 
 understand what you're really looking for.
The wording "newbie" was unfortunate, I meant for some new to the language, but not new to embedded programming. So we could assume that they know a language for embedded programming like C, C++ or Rust already. What are the essential features? Or, which ones are less essential, e.g. I don't really see the need for hex strings, but maybe they are very useful to others. Maybe this is a better phrasing: how simple can D be made without feeling limited when doing embedded programming or low level systems programming?
Jun 22
next sibling parent reply Yatheendra <3df4 gmail.ru> writes:
On Saturday, 22 June 2019 at 09:03:42 UTC, Ola Fosheim Grøstad 
wrote:
 The wording "newbie" was unfortunate, I meant for some new to 
 the language, but not new to embedded programming.  So we could 
 assume that they know a language for embedded programming like 
 C, C++ or Rust already.


 What are the essential features?  Or, which ones are less 
 essential, e.g. I don't really see the need for hex strings, 
 but maybe they are very useful to others.

 Maybe this is a better phrasing: how simple can D be made 
 without feeling limited when doing embedded programming or low 
 level systems programming?
I'm no embedded programmer, but a possible addition (not removal) might be statically proving bounds safety & reduce/avoid runtime bounds checking on array access; can D or Rust do that? Ada should be able to, with its integer range types. Actually it will have benefits beyond embedded as disabling bounds checking in release builds would no longer be justifiable.
Jun 22
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 22 June 2019 at 09:25:58 UTC, Yatheendra wrote:
 I'm no embedded programmer, but a possible addition (not 
 removal) might be statically proving bounds safety & 
 reduce/avoid runtime bounds checking on array access; can D or 
 Rust do that? Ada should be able to, with its integer range 
 types. Actually it will have benefits beyond embedded as 
 disabling bounds checking in release builds would no longer be 
 justifiable.
No, D can't. There are languages that can do it, or languages with tooling and annotations that can do it. I believe SPARK (derived from Ada) and some C-extension have such tooling available. AFAIK this is generally done by establishing an upper bound on the number of iterations you can have in a loop and then conceptually "unrolling" the loop up to that point (so that there is no for and while, just a long series of if-statements) and then using a prover that will then prove that the array bounds cannot be exceeded. It might be possible in some cases for the prover to establish this without an upper bound too, but as far as I understand, in practice you often have to provide an upper bound. Ola.
Jun 22
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 22 June 2019 at 09:42:48 UTC, Ola Fosheim Grøstad 
wrote:
 No, D can't. There are languages that can do it, or languages 
 with tooling and annotations that can do it.  I believe SPARK 
 (derived from Ada) and some C-extension have such tooling 
 available.
You can find more on Ada SPARK and handling of loops here: https://learn.adacore.com/courses/intro-to-spark/book/05_Proof_Of_Functional_Correctness.html#handling-of-loops And more on the vulnerabilities that SPARK Pro prevents here: https://www.adacore.com/sparkpro Ola.
Jun 22
prev sibling next sibling parent reply Mike Franklin <slavo5150 yahoo.com> writes:
On Saturday, 22 June 2019 at 09:03:42 UTC, Ola Fosheim Grøstad 
wrote:

 The wording "newbie" was unfortunate, I meant for some new to 
 the language, but not new to embedded programming.  So we could 
 assume that they know a language for embedded programming like 
 C, C++ or Rust already.


 What are the essential features?  Or, which ones are less 
 essential, e.g. I don't really see the need for hex strings, 
 but maybe they are very useful to others.

 Maybe this is a better phrasing: how simple can D be made 
 without feeling limited when doing embedded programming or low 
 level systems programming?
I could get by with structs, basic types, functions, and typical flow-control features of any language. I wouldn't enjoy it, though, for anything complex. When things start getting complex, that's when I want to be able to utilize the modeling and metaprogramming features of a language. So the features I would prefer would probably depend greatly on the complexity of the project I was working on and the resource constraints of the platform. That is why I think the opt-in continuum (https://forum.dlang.org/post/q7j4sl$17pe$1 digitalmars.com) that Andrei mentioned a while back is so important. It allows one to scale up with the complexity of the project and/or the available resources of the platform. Mike
Jun 22
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 22 June 2019 at 09:57:30 UTC, Mike Franklin wrote:
 I could get by with structs, basic types, functions, and 
 typical flow-control features of any language.  I wouldn't 
 enjoy it, though, for anything complex.
Yes, even though the goal is to find a minimal language subset, the resulting language shouldn't feel limiting. So does this mean that things like lacking runtime-resolved virtual functions will feel limiting? Or would statically resolved virtual functions be enough, or is not having virtual functions ok if you have some other feature like interfaces?
 So the features I would prefer would probably depend greatly on 
 the complexity of the project I was working on and the resource 
 constraints of the platform.
Yes, available memory is also growing on embedded platform.
 That is why I think the opt-in continuum 
 (https://forum.dlang.org/post/q7j4sl$17pe$1 digitalmars.com) 
 that Andrei mentioned a while back is so important.  It allows 
 one to scale up with the complexity of the project and/or the 
 available resources of the platform.
Yes, I believe that also was the goal of Rust, to have close to no runtime library. However I think one might distinguish between type-system-mechanisms and features that are necessary for code generation and those that are only for verification and testing. For instance, I am not convinced that features that enable the Rust borrow checker has to be part of the language. But I haven't given that a lot of thought. It seems like it could be done with as library types, with annotations, and an external static analysis pass. Similarily, there is no need for unittests to be a language feature in D. You can achieve the same with annotations and an external pass. More importantly, if a language is kept minimal, with solid meta programming and annotation capabilities, then you can increase the opt-in-continuum by integrating external tooling.
Jun 22
next sibling parent Mike Franklin <slavo5150 yahoo.com> writes:
On Saturday, 22 June 2019 at 10:22:10 UTC, Ola Fosheim Grøstad 
wrote:

 So does this mean that things like lacking runtime-resolved 
 virtual functions will feel limiting? Or would statically 
 resolved virtual functions be enough, or is not having virtual 
 functions ok if you have some other feature like interfaces?
I think that's a good point. In the embedded systems that I've programmed, so much is known statically, at compile-time, so I just don't really have much need for many runtime features. However, some embedded systems today are much more powerful than PC of the 1990's, and include 2D graphics and such. I might prefer more runtime features in a scenario like that, but I think I could probably get by without them, especially since you other ways to dynamically dispatch.
 Yes, I believe that also was the goal of Rust, to have close to 
 no runtime library.

 However I think one might distinguish between 
 type-system-mechanisms and features that are necessary for code 
 generation and those that are only for verification and testing.

 For instance, I am not convinced that features that enable the 
 Rust borrow checker has to be part of the language.  But I 
 haven't given that a lot of thought.  It seems like it could be 
 done with as library types, with annotations, and an external 
 static analysis pass.
I've been wondering about that too. I think D's lifetime annotations (scope and return) get you pretty far, but D still allows two mutable references to one object. It'd be nice to have some control over that in D.
 Similarily, there is no need for unittests to be a language 
 feature in D. You can achieve the same with annotations and an 
 external pass.
Agreed. It's mostly a convenience because it allows you to place the test locally next to the implementation.
 More importantly, if a language is kept minimal, with solid 
 meta programming and annotation capabilities, then you can 
 increase the opt-in-continuum by integrating external tooling.
Agreed, but I would prefer library features over tooling. Mike
Jun 22
prev sibling parent reply XavierAP <n3minis-git yahoo.es> writes:
On Saturday, 22 June 2019 at 10:22:10 UTC, Ola Fosheim Grøstad 
wrote:
 For instance, I am not convinced that features that enable the 
 Rust borrow checker has to be part of the language.  But I 
 haven't given that a lot of thought.  It seems like it could be 
 done with as library types, with annotations, and an external 
 static analysis pass.
https://dlang.org/phobos/std_typecons.html#Unique
 Similarily, there is no need for unittests to be a language 
 feature in D. You can achieve the same with annotations and an 
 external pass.
I honestly think unittest is the best idea ever... ___ I understand people frustrated with the GC, and in retrospect we all agree everything in the runtime should have been, or should be made, buy-in. But I don't understand the benefit of isolating out of the language and re-implement as libraries what is already isolated and buy-in in the language. And if I wanted that, I wouldn't start by stripping down D. I'd start by extending C. We could call it C with Templates, later rename it to C<<>>... and ten years later we could be debating again improvement proposals to implement multiple inheritance. :p
Jun 22
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 22 June 2019 at 12:27:32 UTC, XavierAP wrote:
 should be made, buy-in. But I don't understand the benefit of 
 isolating out of the language and re-implement as libraries 
 what is already isolated and buy-in in the language.
There are several benefits, one is that you can identify missing pieces in the metaprogramming feature set. Another is that it becomes easier to reimplement the language and thus you can get better static analysis. A third is that you can easier analyze the language if it is reduced to a minimal set, so you can better understand the effect of extending the language. A fourth is that you with a minimal set get the opportunity to add AST-manipulation (AST macros). A fifth is that if the optimizer can work with general implementation strategies rather than special cases then all code benefits from new optimization stages. A sixth is that there is less code to maintain, so you can get better structure on the compiler code base. Or you could just view it as a low-cost experiment.
 And if I wanted that, I wouldn't start by stripping down D. I'd 
 start by extending C.
That would be a lot of work. Besides the primary advantage of C is compatibility. Compiling to C is worthwhile though, enables support for niche hardware platforms, SoC solutions etc (System on A Chip).
Jun 22
prev sibling parent reply Kagamin <spam here.lot> writes:
On Saturday, 22 June 2019 at 09:03:42 UTC, Ola Fosheim Grøstad 
wrote:
 What are the essential features?  Or, which ones are less 
 essential, e.g. I don't really see the need for hex strings, 
 but maybe they are very useful to others.
GC (at run time), clasess and typeinfo, everything else is good for embedded. BetterC is not a good subset, it's more a PR feature.
Jun 27
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 27 June 2019 at 15:42:27 UTC, Kagamin wrote:
 GC (at run time), clasess and typeinfo, everything else is good 
 for embedded. BetterC is not a good subset, it's more a PR 
 feature.
Ok, but the question is more: what features are essential? And, which features are rarely used and can be replaced by a library solution?
Jun 27
parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Thursday, 27 June 2019 at 17:15:27 UTC, Ola Fosheim Grøstad 
wrote:
 On Thursday, 27 June 2019 at 15:42:27 UTC, Kagamin wrote:
 GC (at run time), clasess and typeinfo, everything else is 
 good for embedded. BetterC is not a good subset, it's more a 
 PR feature.
Ok, but the question is more: what features are essential? And, which features are rarely used and can be replaced by a library solution?
This is less a question of a features essential-ness and more a question of how much compiler integration is needed to implemented it in an efficient and convenient (convenient for the user) manner. For example bounds-checking and slices can be done as a library easily, but it's so much more convenient if they are part of the language. A type-system also needs to be integrated closely with the compiler because it defines which code may be rejected early thereby improving iteration times on faulty code.
Jun 28
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 28 June 2019 at 08:29:20 UTC, Stefan Koch wrote:
 This is less a question of a features essential-ness and more a 
 question of how much compiler integration is needed to 
 implemented it in an efficient and convenient (convenient for 
 the user) manner.
Well, it was posed as a question of what is essential. Clearly some features are more used than others and some are difficult to replace with a library solution.
 For example bounds-checking and slices can be done as a library 
 easily, but it's so much more convenient if they are part of 
 the language.
But is it more convenient? In terms of generic programming you often deal with array-like APIs rather than arrays and slices might need to support other indexing mappings in parallel code so that each core hits disjunct sets of cache lines etc. What you need is the basic operators and a convenient syntax, it should not matter if the implementation is in a library.
 A type-system also needs to be integrated closely with the 
 compiler because it defines which code may be rejected early 
 thereby improving iteration times on faulty code.
Not sure what is meant by "iteration times", but yes, the type system unification process is an essential part of the compiler. So which features have to be dealt with explicitly in the type system as a non-library type?
Jun 28
prev sibling next sibling parent Yatheendra <3df4 gmail.ru> writes:
On Saturday, 22 June 2019 at 08:41:36 UTC, Mike Franklin wrote:
 I have a few ideas for removing many features of D, preferring 
 library implementations instead
Would be interesting. Initially defined by its linter, I guess. Existing users with big D codebases could opine on if and how the features of D they started with stayed in use or got replaced. I don't remember how starting out with C/C++ felt, but being a D newbie feels different - becomes comfortable almost instantaneously, but the next steps have to be in a real small project, not learning more by reading. While the Phobos Github issues around testing, etc. are useful for learning more, the features to use in own small projects are fuzzier to pick out. C/C++ don't really have too many ways of doing things (and not enough things can be done), D
Jun 22
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 22 June 2019 at 08:41:36 UTC, Mike Franklin wrote:
 I have a few ideas for removing many features of D, preferring 
 library implementations instead, but base on your preface, I 
 think that is a different goal than what you have in mind.
Btw, I'd love to hear these ideas, my first post gave the wrong impression of what I am after. I am indeed interested in what can be done effectively with meta programming library types instead of language features (possibly with syntactic sugar if it is frequently used). I've toyed with my own ideas that would make templated library types for array (yes, even arrays), volatile, ownership, non-modular integers etc. But nothing serious at this stage. If there are generally useful patterns that could be done as a library then that would be very interesting. One possible pattern, that is not covered by D, is static allocation in memory tight settings. I.e. you have typed allocation, but limited to e.g. 256 live objects. So you don't get memory fragmentation and out-of-memory issues that can arise with malloc.
Jun 22
parent reply Mike Franklin <slavo5150 yahoo.com> writes:
On Saturday, 22 June 2019 at 09:31:25 UTC, Ola Fosheim Grøstad 
wrote:
 On Saturday, 22 June 2019 at 08:41:36 UTC, Mike Franklin wrote:
 I have a few ideas for removing many features of D, preferring 
 library implementations instead, but base on your preface, I 
 think that is a different goal than what you have in mind.
Btw, I'd love to hear these ideas
Interfaces are an obvious one to me. They can be implemented using D's introspection features, and in some cases they aren't even really necessary. See this discussion on the topic: https://forum.dlang.org/post/qndhfzrnipsnvsstrdvg forum.dlang.org Classes are another. See https://theartofmachinery.com/2018/08/13/inheritance_and_polymorphism_2.html for a very interesting implementation of class-like behavior without classes. I think D may need additional features to make it work seamlessly without language support, but you can get pretty far today. I'm quite convinced that if we added `opImplicitCast` to the language, we could implement `alias this` and multiple `alias this` in the language. There was a recent discussion about that too: https://forum.dlang.org/post/ozdjozskgwqxfykijrsh forum.dlang.org I have a few others, but I think those examples illustrate the general idea. Basically, I'd double-down on the introspection, metaprogramming, and compile-time features of D, and then use those features to implement whatever features one needs. Some are concerned about falling for the Lisp curse (http://winestockwebdesign.com/Essays/Lisp_Curse.html), but I think it can be done tastefully to avoid that. Mike
Jun 22
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 22 June 2019 at 10:10:13 UTC, Mike Franklin wrote:
 Interfaces are an obvious one to me.  They can be implemented 
 using D's introspection features, and in some cases they aren't 
 even really necessary.  See this discussion on the topic:  
 https://forum.dlang.org/post/qndhfzrnipsnvsstrdvg forum.dlang.org
Yes, static interfaces can be done by duck-typing and conventions. Although it is difficult to ensure type safety with duck-typing alone (but one can improve on that with an enum that says something about capabilities and test those with a static assert).
 Classes are another.  See 
 https://theartofmachinery.com/2018/08/13/inheritance_and_polymorphism_2.html
for a very interesting implementation of class-like behavior without classes. 
I think D may need additional features to make it work seamlessly without
language support, but you can get pretty far today.
Hmm, yes, that wasn't very clean... I guess this is a good argument for providing AST manipulation features ("AST macros").
 I'm quite convinced that if we added `opImplicitCast` to the 
 language, we could implement `alias this` and multiple `alias 
 this` in the language.  There was a recent discussion about 
 that too: 
 https://forum.dlang.org/post/ozdjozskgwqxfykijrsh forum.dlang.org
Hmm, yes, but if one is forced to resort to using string concatenation in a macroish fashion then I think that would be a sign of a missing language feature or that the meta programming capabilities need improvement. Although, perhaps the argument you are making is that "alias this" is not really needed, but if you absolutely need it one time, then it is possible? Like an "escape-hatch"?
 I have a few others, but I think those examples illustrate the 
 general idea.  Basically, I'd double-down on the introspection, 
 metaprogramming, and compile-time features of D, and then use 
 those features to implement whatever features one needs.
Yes, that seems reasonable, as long as it doesn't harm the type system and the bugs that a strict type system can catch. That is one of the issues that can arise with very generic template based code, that it can easily accept anything with no warning.
  Some are concerned about falling for the Lisp curse 
 (http://winestockwebdesign.com/Essays/Lisp_Curse.html), but I 
 think it can be done tastefully to avoid that.
I don't really think this necessarily is an issue for embedded/low level systems programming if you have "LISP"-like coding features limited to libraries in the same way D now does with safe. I don't think low level programmers will absorb badly written libraries in the same way that people do in some high level contexts (javascript *coughs*).
Jun 22
next sibling parent Mike Franklin <slavo5150 yahoo.com> writes:
On Saturday, 22 June 2019 at 10:50:35 UTC, Ola Fosheim Grøstad 
wrote:

 I'm quite convinced that if we added `opImplicitCast` to the 
 language, we could implement `alias this` and multiple `alias 
 this` in the language.  There was a recent discussion about 
 that too: 
 https://forum.dlang.org/post/ozdjozskgwqxfykijrsh forum.dlang.org
Hmm, yes, but if one is forced to resort to using string concatenation in a macroish fashion then I think that would be a sign of a missing language feature or that the meta programming capabilities need improvement.
Yes, my implementation in that post was extremely poor, and that's being kind. Adam's response was appropriate. It was just an illustration, and I'm sure there are better ways to implement it, as Adam showed. My point was that D has sufficient metaprogramming and introspection features to do it, and if it were implemented in the library it would be encapsulated from the user and would sit quietly in a dark corner of D's library. Most people will just use it and never look at the implementation as long as it works.
 Although, perhaps the argument you are making is that "alias 
 this" is not really needed, but if you absolutely need it one 
 time, then it is possible?  Like an "escape-hatch"?
No, I would use it extensively to implement convenient composition and avoid inheritance. Mike
Jun 22
prev sibling parent reply Yatheendra <3df4 gmail.ru> writes:
On Saturday, 22 June 2019 at 10:50:35 UTC, Ola Fosheim Grøstad 
wrote:
 Yes, static interfaces can be done by duck-typing and 
 conventions.  Although it is difficult to ensure type safety 
 with duck-typing alone (but one can improve on that with an 
 enum that says something about capabilities and test those with 
 a static assert).
This sounds like the Erlang recommendation (they call it tagged tuples, records).
 Hmm, yes, that wasn't very clean... I guess this is a good 
 argument for providing AST manipulation features ("AST macros").
Nim has AST macros.
 ...
Jun 22
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 22 June 2019 at 16:45:55 UTC, Yatheendra wrote:
 This sounds like the Erlang recommendation (they call it tagged 
 tuples, records).
Sort of, except it is compile-time only.
 Nim has AST macros.
I have no real experience with Nim, but the AST macros seems to be very close to the parse-tree. I could be wrong, but I think something more abstract is needed.
Jun 24
parent reply Araq <rumpf_a web.de> writes:
On Monday, 24 June 2019 at 10:31:27 UTC, Ola Fosheim Grøstad 
wrote:
 On Saturday, 22 June 2019 at 16:45:55 UTC, Yatheendra wrote:
 This sounds like the Erlang recommendation (they call it 
 tagged tuples, records).
Sort of, except it is compile-time only.
 Nim has AST macros.
I have no real experience with Nim, but the AST macros seems to be very close to the parse-tree. I could be wrong, but I think something more abstract is needed.
**Disclaimer**: I invented Nim. The AST is "close to" the parse-tree but that's not a problem, the usual things that a macro system is capable of can all be done (async, serialization, lazy evaluation, control flow abstractions, currying, DSLs), and reasonably easy too. It's certainly ugly in some ways but that is not because it is "close to" the parse-tree (hey, it works for Lisp too!) but because it was a research project that escaped the lab. Almost no effort was spent on API design. But we're getting there.
Jun 24
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Monday, 24 June 2019 at 13:47:06 UTC, Araq wrote:
 **Disclaimer**: I invented Nim.

 The AST is "close to" the parse-tree but that's not a problem, 
 the usual things that a macro system is capable of can all be 
 done (async, serialization, lazy evaluation, control flow 
 abstractions, currying, DSLs), and reasonably easy too.

 It's certainly ugly in some ways but that is not because it is 
 "close to" the parse-tree (hey, it works for Lisp too!) but 
 because it was a research project that escaped the lab. Almost 
 no effort was spent on API design. But we're getting there.
Is there anything you would have done differently if you started over?
Jun 24
parent Araq <rumpf_a web.de> writes:
On Monday, 24 June 2019 at 17:16:04 UTC, jmh530 wrote:
 Is there anything you would have done differently if you 
 started over?
Sure, but only details. We got most things right. But let's assume we got it wrong and there is a superior IR that also the macro system should have access to. Then we would need a translation layer from the old AST to the new IR and back so that older code keeps working. But that's well trotted ground, see GCC's various different IRs (GENERIC, GIMPLE and RTL).
Jun 24
prev sibling parent Guillaume Piolat <contact+spam spam.org> writes:
On Saturday, 22 June 2019 at 06:55:40 UTC, Ola Fosheim Grøstad 
wrote:
 I am wondering, what would a minimal subset of D look like?  
 Something that would make the syntax/semantics look simple to a 
 newbie wanting to do embedded programming, yet be useful.  
 Let's assume that we are already limited to the better-C subset.

 What are the "must have" features?  I assume that "static if" 
 ranks high for most D users, but what else?
I'd assume a D successor would be JIT'ed with a big runtime, with types as firstt-class values, erasing the difference between compile-time and runtime. In short, a bit like a typed LISP.
Jun 24