Migrating dmd to D?

[js.mdnq]

On Saturday, 2 March 2013 at 15:12:40 UTC, Iain Buclaw wrote:
> On Mar 2, 2013 3:01 PM, "SomeDude" <lovelydear at mailmetrash.com> 
> wrote:
>>
>> On Saturday, 2 March 2013 at 14:47:55 UTC, David Nadlinger 
>> wrote:
>>>
>>> On Saturday, 2 March 2013 at 07:16:04 UTC, SomeDude wrote:
>>>>
>>>> On Saturday, 2 March 2013 at 06:50:32 UTC, SomeDude wrote:
>>>>>
>>>>>
>>>>> Exactly. This fixed subset would be very limited in 
>>>>> comparison to the
> full language (I can imagine something looking a bit like a 
> smaller Go,
> there would probably be no templates at all, no CTFE, maybe 
> even no
> exceptions, for instance), but would be orthogonal, completely 
> stable in
> terms of spec, and known to work. It could be defined for other 
> real world
> usages as well, like embedding in small appliances.
>>>>
>>>>
>>>> It would also make it easy to bootstrap the compiler on new 
>>>> platforms.
>>>
>>>
>>> I don't see how this would help with proting to different 
>>> platofrms at
> all if you have a cross-compiler.
>>>
>>> Yes, the DMD frontend currently isn't really built with
> cross-compilation in mind (e.g. using the host's floating point 
> arithmetic
> for constant folding/CTFE), but once this has been changed, I 
> don't see how
> the language used would make any difference in re-targetting at 
> all.
>>>
>>> You simply use another host system (e.g. Windows/Linux x86) 
>>> until the
> new backend/runtime is stable enough for the compiler to 
> self-host.
>>>
>>> David
>>
>>
>> And what if you *don't* have a cross compiler ? You compile 
>> the D subset
> (bootstrapper) in C and off you go (provided you have a 
> reasonable C
> compiler on that platform).
>
> I don't see how using only a subset of the language would have 
> an effect on
> cross compiling or porting of a compiler self hosted in D.  
> Your argument
> is lost on me some dude...
>
> Regards



For the same reason that most embedded languages use C and not 
C++. Obviously it is easier to implement a subset of something 
than the full set(at the very least, less work). Most embedded 
applications don't have the resources to deal with higher level 
constructs(since these generally come at a real cost). For 
example, a GC is generally an issue on small embedded apps. The D 
core language spec would have to be GC agnostic(in fact, I think 
the full spec should be).

I actually prefer to use C++ in embedded apps but use static 
classes. It just looks better than traditional C because of the 
logical separation it creates.

For the core language spec, things like templates, mixins, and 
other useful logical language constructs(these are more like 
macros than objects) should be included.

One could propose the following: The core language spec is the 
specification of the core language elements of D that can run on 
any modern processing unit, compiled as is and without "issue". 
That is, say you have a model with functions in it. These 
functions are just mathematical calculations and should have no 
issue running on any cpu. Hence, mark the module as core(core 
language spec, no GC, etc) and porting is not an issue. You know 
because it is using the core spec that no advanced language specs 
are being used that will break the bank.

Every major revision the core spec can be updated to include new 
logical language constructs that were added to the previous major 
version.

By being able to mark modules one can gain some benfit:


module mymodule : core, gc, ...;

states that mymodule uses the core language spec, the garbage 
collector, and whatever else.

You can think of the "core" language spec as being analogous to 
purity. It offers similar benefits because it restricts what can 
happen to a smaller universe.