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?

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

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?

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

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.

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.

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.

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.

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

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