GSOC - Holiday Edition

[Johannes Pfau via Digitalmars-d]

Am Sun, 04 Jan 2015 18:25:32 +0100
schrieb Martin Nowak <code+news.digitalmars at dawg.eu>:

> 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.
> 

The question is basically if you want a 100% polished experience or if
you just want something that works with some effort.

One example of many: If you disable ModuleInfo we still happily compile
module constructors, they'll never be called though. Sure you can avoid
this if you know about it, but we can't promote D as a reasonable
replacement for C as long as these issues exist.

I agree that such changes are not really big language changes.