D for embedded system

[Timo Sintonen]

On Saturday, 17 November 2012 at 23:08:04 UTC, maarten van damme 
wrote:
> Why is so much built in to druntime? creating classes, AA's,....
> Is it normal? does c++ do the same thing?
>
> Why wasn't opted for making opIndex overloadable with other 
> objects so
> AA's could be moved out of druntime and in phobos?
>
> I have no experience with language design but wouldn't it be 
> great if
> druntime was more modular to make porting (and stripping) of 
> features
> for for example embedded platforms more easy?
>
> And is somewhere documented which functions need to be 
> implemented in druntime?

Druntime is a mixture of functions that the application may call, 
functions that the generated code calls and internal library 
functions. As pointed out earlier in this thread, there is no 
more documentation than those generated from the source files. 
They tell how to use the functions but does not tell when and why 
we need it.

I started with my test class and object.d and added files one by 
one and commented out some features until all references were 
solved in that particular case. Nearly every file in the library 
is related to some d construction or keyword. If I use a 
construction in my application, I need a file from the library. 
Unfortunately, the whole file is included from the library even 
if I need a single funtion from it.

The library has lots of version dependencies. First it has been 
made for win/mac/linux, then it has been ported to gdc. The next 
challenge is to add support for all mobile platforms and embedded 
systems with no os at all. In my opinion the version system will 
not work any more when we have 10 different systems to support. 
We should have abstract classes an put the real implementation to 
os specific directory. Then we make that directory as import 
directory.

It might also be good to have a minimum implementation in 
configure. That would include only the necessary files and define 
version=minimum. This option would leave out as much as possible 
from the code. To make it work with all possible configuration 
may not be an easy task.

All these takes lots of time and work. If the library is only for 
gdc, it would be simpler. To have a library that is totally 
different from the dmd version might not be a good idea. A 
library with different features and bugs may reduce the amount of 
possible users and it is harder to get people to maintain it.