"Zach the Mystic" <reachBUTMINUSTHISzach@gOOGLYmail.com> wrote in message news:bueceuemxqmflixkqbuz@forum.dlang.org...
> On Saturday, 2 March 2013 at 04:28:40 UTC, Zach the Mystic wrote: You would definitely need an identifier translation table:
>
> "Dsymbols *" -> "Dsymbol[]"

Might as well just define ArrayBase etc

> "NULL" -> "null"

Sure, but what about all the places 0 is used to mean NULL?

> `//printf("...%d...", s)` -> `writef("...%s...", s)`

Why not just keep it as printf?

> "#ifdef XIFDEFVERSION" + nested ifdefs + "#endif"
> -> "version(XIFDEFVERSION) {" + nested {}'s + "}"
>
> "#ifdef 0" -> "version(none)"
>

No luck, dmd source uses #ifdefs mid-declaration, mid-statement, and
mid-expression (even mid-string-literal)
It also uses #ifs with complex conditions.

And don't forget no-args ctors, implicit calling of ctors, stack allocated classes, new keywords, narrowing integer conversions, 'virtual', pure virtual function syntax, macros as expression aliases, string literal constness, the EXP_CANT_INTERPRET cast hack, macros, namespaces, macros, structs using inheritance, and of course more macros.

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

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

On Mar 2, 2013 3:01 PM, "SomeDude" <lovelydear@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
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On Saturday, 2 March 2013 at 15:12:40 UTC, Iain Buclaw wrote:
> On Mar 2, 2013 3:01 PM, "SomeDude" <lovelydear@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.

On Saturday, 2 March 2013 at 10:05:08 UTC, Daniel Murphy wrote:
>
> "Zach the Mystic" <reachBUTMINUSTHISzach@gOOGLYmail.com> wrote in message
> news:bueceuemxqmflixkqbuz@forum.dlang.org...
>> On Saturday, 2 March 2013 at 04:28:40 UTC, Zach the Mystic wrote:
>> You would definitely need an identifier translation table:
>>
>> "Dsymbols *" -> "Dsymbol[]"
>
> Might as well just define ArrayBase etc
>
>> "NULL" -> "null"
>
> Sure, but what about all the places 0 is used to mean NULL?
>
>> `//printf("...%d...", s)` -> `writef("...%s...", s)`
>
> Why not just keep it as printf?
>
>> "#ifdef XIFDEFVERSION" + nested ifdefs + "#endif"
>> -> "version(XIFDEFVERSION) {" + nested {}'s + "}"
>>
>> "#ifdef 0" -> "version(none)"
>>
>
> No luck, dmd source uses #ifdefs mid-declaration, mid-statement, and
> mid-expression (even mid-string-literal)
> It also uses #ifs with complex conditions.
>
> And don't forget no-args ctors, implicit calling of ctors, stack allocated
> classes, new keywords, narrowing integer conversions, 'virtual', pure
> virtual function syntax, macros as expression aliases, string literal
> constness, the EXP_CANT_INTERPRET cast hack, macros, namespaces, macros,
> structs using inheritance, and of course more macros.

Every single one of these would have to be special-cased. If you had a domain-specific language you could keep track of whether you were mid-declaration, mid-statement, or mid-string-literal. Half the stuff you special-case could probably be applied to other C++ projects as well.

If this works, the benefits are just enormous. In fact, I would actually like to "waste" my time trying to make this work, but I'm going to need to ask a lot of questions because my current programming skills are nowhere near the average level of posters at this forum.

I would like a c++ lexer (with whitespace) to start with. Then a discussion of parsers and emitters. Then a ton of questions just on learning github and other basics.

I would also like the sanction of some of the more experienced people here, saying it's at least worth a go, even if other strategies are simultaneously pursued.

On Saturday, 2 March 2013 at 17:26:52 UTC, js.mdnq wrote:
> 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).

As an embedded guy I dream of direct @safe opposite, somewhat similar to @nogc proposal but even more restrictive, one that could work with minimal run-time. I have tried to interest someone in experiments with D at work but lack of compiler verified subset that is embedded-ready was a big issue.

On 3/2/2013 6:47 AM, David Nadlinger wrote:
> 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.

In fact, if the new system supports sshfs, it is fairly easy to do.

On Mar 2, 2013 5:31 PM, "js.mdnq" <js_adddot+mdng@gmail.com> wrote:
>
> On Saturday, 2 March 2013 at 15:12:40 UTC, Iain Buclaw wrote:
>>
>> On Mar 2, 2013 3:01 PM, "SomeDude" <lovelydear@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++.

These aren't self hosting if they are written in another language.

Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 3/2/2013 10:48 AM, Dicebot wrote:
> As an embedded guy I dream of direct @safe opposite, somewhat similar to @nogc
> proposal but even more restrictive, one that could work with minimal run-time. I
> have tried to interest someone in experiments with D at work but lack of
> compiler verified subset that is embedded-ready was a big issue.

You can do that now. Use the badly named and rather undocumented "betterC" switch and you can build D apps that don't need phobos at all - they can be linked with the C runtime library only.

I use it to bring D up on a new target.