GSOC - Holiday Edition

[Mike via Digitalmars-d]

On Saturday, 3 January 2015 at 14:14:42 UTC, Adam D. Ruppe wrote:

>
> What changes did you have in mind? When I played with it, it 
> was mostly using the C-like subset, but I still think it was 
> worth it because bits like operator overloading and slicing are 
> really convenient.
>
> What I've wanted before is better ability to remove dependency 
> on stuff like moduleinfo. Though that isn't a big deal on 
> something like x86 where an extra 30 KB is fine, I think it 
> would be really important on something like a arduino. (Which I 
> intend to play with - finally have one here - but haven't 
> gotten around to yet.)

Indeed, by using a C-like subset of D you have a much more 
powerful and convenient language than C.  But the compiler is not 
aware of that subset, so it's not a professional experience.  
That's why it plays second fiddle to C.  I need that polished 
experience before I can sell D to my employer, my customers, or 
even myself.

Right now if you step outside of the aforementioned subset, 
you'll only get a linker error.  Furthermore, you have limited 
facilities outside of hacks and creative linker scripting to 
reign in code generation.  And programmers have to create their 
own port of the runtime to provide that subset, but there is no 
hope in that port every making it upstream, so 
bare-metal/embedded/kernel programmers will always be forced to 
their own corner of the world, with a different dialect of the 
language.

There have been suggestions to create compiler flag in order 
restrict compilation to a minimal subset of D, but I don't think 
that's the right solution.  Programmers will define "minimal" 
differently. For example, I would like to be able to use 
exceptions, but I don't want that to implicitly require the 
garbage collector.  A better approach would be to modularize the 
language so users can start with something very minimal and add 
features (rather than remove features) to scale the language to 
their needs.

Here are some of the changes I had in mind:

1.  Move the runtime hook definitions out of the compiler to .di 
files so programmers wanting to create a subset of the language 
can decorate those definitions, or omit them, in order to get 
compiler errors instead of linker errors when they explicitly or 
implicitly use an unimplemented language feature.

2.  Add toolchain support (compiler and especially linker) to 
reign in all the implicit code generation and remove dead code.  
This is crucial for microcontroller programming.

3. The GC, and other automatic memory management strategies, 
should be opt-in library features, instead of default language 
features one has to avoid.  Other emerging languages have shown 
that D can have much more elegant lifetime management if it broke 
with the past, but it's clear that's not going to happen.

4. But it's not just a laundry list of individual features that's 
needed.  The community and the language leaders need a change in 
perspective.  Even if the above were addressed, a port (or 
potentially ports) of the runtime would still be required.  But, 
the current runtime is designed in such a way that it implicitly 
expects an underlying operating system.  I don't think that's a 
characteristic of a systems programming language.  All the 
platform-specific code and language features that are provided by 
the OS need to be moved to libraries and encapsulated.  I would 
like to see "language", "library", and "platform" clearly 
separated so the language can be modularized and we can choose 
what features of the language to support in our ports.  
Unfortunately, this has proven to be very unpopular in this 
community.

I've tried a few things, but it's clear I need to learn the 
compiler in order to do anything significant, and that's not 
really within my interest or ability.  Furthermore, the 
controversy surrounding some of my most trivial ideas has left me 
feeling that even if I rolled up my sleeves and implemented a few 
things, it would be such an uphill battle justifying it to this 
community that my time would be far better spent studying 
compiler implementation and going my own way.

Again, using D for bare-metal/embedded/kernel programming shows 
huge potential as you know, but it's currently not a professional 
experience, and getting it there would be a difficult, 
frustrating, and likely doomed experience.  I think users serious 
about using D for such programming should fork and go their own 
way, or start over with D as an inspiration...and that would be a 
good GSOC bare-metal project.

Mike