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
