On 01/04/2015 04:50 AM, Mike wrote:
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.
The situation is similar to C where you have a specialized nanolib
runtime, have to come up with your own linker script and need to avoid
big dependencies (like printf with float support).
https://launchpad.net/gcc-arm-embedded
We already have a designated -betterC compiler switch that should avoid
all dependencies (it's incomplete though). Overall I think this is
fairly trivial to achieve.
I don't see what part of the runtime would be needed for an embedded
target, except for maybe 2 hooks http://wiki.dlang.org/Runtime_Hooks or so.
If you're using C++, you also need to fill in some missing runtime
functions (__init_array, __cxa_pure_virtual, _sbrk).
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.
Exceptions on MC sounds like a bad idea, you can avoid the GC by
throwing static instances of exceptions.
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.
Maybe for a polished experience, but it's worth the trouble in the
beginning.
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.
Last time I build an embedded ARM project the resulting D binary was as
small as the C++ one.
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.
It's a known issue that certain language constructs require memory
management. That's not a big deal, you can't use C++'s std::map either.
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.
A group of people that builds the infrastructure is needed.
I can't strictly follow your conclusion, that half of the language needs
to be change.
The only thing I needed to do last time, was to disable ModuleInfo
generation in the compiler.
