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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019