On Saturday, 2 March 2013 at 19:39:15 UTC, Walter Bright wrote:
> 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.

Wow, I have never known something like that exists! Is there description of what it actually does or source code is only possible reference. Depending on actual limitations, it may be a game changer.

On Saturday, 2 March 2013 at 22:52:49 UTC, Dicebot wrote:
> ...

Missed a quotation mark there :)

On 3/2/13, Dicebot <m.strashun@gmail.com> wrote:
> Wow, I have never known something like that exists! Is there description of what it actually does or source code is only possible reference. Depending on actual limitations, it may be a game changer.

I had alook, all it does is avoids generating moduleinfo. I'm not sure how that helps, the GC still works with this switch.

On 3/2/2013 3:00 PM, Andrej Mitrovic wrote:
> On 3/2/13, Dicebot <m.strashun@gmail.com> wrote:
>> Wow, I have never known something like that exists! Is there
>> description of what it actually does or source code is only
>> possible reference. Depending on actual limitations, it may be a
>> game changer.
>
> I had alook, all it does is avoids generating moduleinfo. I'm not sure
> how that helps, the GC still works with this switch.
>

By not generating moduleinfo, which needs phobos to work, it can link with C only.

"Zach the Mystic" <reachBUTMINUSTHISzach@gOOGLYmail.com> wrote in message news:pwwrifebdwzctioujuwm@forum.dlang.org...
> 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.

Something like this https://github.com/yebblies/magicport2 ?

On Sunday, 3 March 2013 at 03:06:15 UTC, Daniel Murphy wrote:
> "Zach the Mystic" <reachBUTMINUSTHISzach@gOOGLYmail.com> wrote in message
> news:pwwrifebdwzctioujuwm@forum.dlang.org...
>> 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.
>
> Something like this https://github.com/yebblies/magicport2 ?

Yes! I need to look it over more thoroughly, but I couldn't ask for a better beginning. Can I trust that you'll be a willing part of future discussions on this matter, even if only to play Devil's Advocate?

On Saturday, 2 March 2013 at 23:09:57 UTC, Walter Bright wrote:
> On 3/2/2013 3:00 PM, Andrej Mitrovic wrote:
>> On 3/2/13, Dicebot <m.strashun@gmail.com> wrote:
>>> Wow, I have never known something like that exists! Is there
>>> description of what it actually does or source code is only
>>> possible reference. Depending on actual limitations, it may be a
>>> game changer.
>>
>> I had alook, all it does is avoids generating moduleinfo. I'm not sure
>> how that helps, the GC still works with this switch.
>>
>
> By not generating moduleinfo, which needs phobos to work, it can link with C only.

But isn't there a few language constructs the specifically rely on the GC? I thought this was the whole issue of not being able to disable the GC completely in dmd? If so, the core language spec would have to be designed to be GC agnostic.

I think the ability to mark a module with attributes would help. Possibly extend UDA's to work on the module keyword also.

"Zach the Mystic" <reachBUTMINUSTHISzach@gOOGLYmail.com> wrote in message news:pabfuaorrjbljxzrglbv@forum.dlang.org...
>>
>> Something like this https://github.com/yebblies/magicport2 ?
>
> Yes! I need to look it over more thoroughly, but I couldn't ask for a better beginning. Can I trust that you'll be a willing part of future discussions on this matter, even if only to play Devil's Advocate?

More like a full-blown attempt than a beginning.  I started this a long time ago.

There are three parts to it:
- c++ parser/d printer, with lots of cheating and special cases
- patches to the c++ source
- patched version of dmd to build the result (no error on variable shadowing
etc)

It produces a 70000 line d file which appears to get through 3/7ths of semantic1.  Root needs to be ported, and a cleaner interface to the backend is needed to compile the glue layer.

On Sunday, 3 March 2013 at 03:06:15 UTC, Daniel Murphy wrote:
>> 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.
>
> Something like this https://github.com/yebblies/magicport2 ?

Since you're obviously way ahead of me on this, I'm going to go ahead and say everything I've been thinking about this issue.

My approach to translating the source would be more-or-less naive. That is, I would be trying to do simple pattern-matching and replacement as much as possible. I would try to go as far as I could without the scanner knowing any context-sensitive information. When I added a piece of context-sensitive information, I would do so by observing the failures of the naive output, and adding pieces one by one, searching for the most bang for my context-sensitive buck. It would be nice to see upwards of 50 percent or more of the code conquered by just a few such carefully selected context-sensitive bucks.

Eventually the point of diminishing returns would be met with these simple additions. It would be of utility to have a language at that point, which, instead of seeking direct gains in its ability to transform dmd code, saw its gains in the ease and flexibility with which one could add the increasingly obscure and detailed special cases to it. I don't know how to set up that language or its data structures, but I can tell you what I'd like to be able to do with it.

I would like to be able to query which function I am in, which class I am assembling, etc. I would like to be able to take a given piece of text and say exactly what text should replace it, so that complex macros could be rewritten to their equivalent static pure D functions. In other words, when push comes to shove, I want to be able to brute-force a particularly hard substitution direct access to the context-sensitive data structure. For example, suppose I know that some strange macro peculiarities of a function add an extra '}' brace which is not read by C++ but is picked up by the naive nesting '{}' tracker, which botches up its 'nestedBraceLevel' variable. It would be necessary to be able to say:

if (currentFunction == "oneIKnowToBeMessedUp" &&
   currentLine >= funcList.oneIKnowToBeMessedUp.startingLine +50)
   { --nestedBraceLevel; }

My founding principle is Keep It Simple Stupid. I don't know if it's the best way to start, but barring expert advice steering me away from it, it would be the best for someone like me who had no experience and needed to learn from the ground up what worked and what didn't.

Another advantage of the domain-specific language as described above would its reusability of whatever transformations are common in C++, say transforming 'strcmp(a,b)' -> 'a == b', and it's possible use for adding special cases to translating from one language to another generally speaking . I don't know the difference between what I'm describing and a basic macro text processing language - they might be the same.

My last thought is probably well-tread ground, but the translation program should have import dependency charts for its target program, and automate imports on a per-symbol basis, so it lays out the total file in two steps.

import std.array : front, array;

One thing I'm specifically avoiding in this proposal is a sophisticated awareness of the C++ grammar. I'm hoping special cases cover whatever ground might be more perfectly trod by a totally grammar-aware conversion mechanism.

Now you're as up-to-date as I am on what I'm thinking.

On 3/2/2013 8:36 PM, js.mdnq wrote:
> On Saturday, 2 March 2013 at 23:09:57 UTC, Walter Bright wrote:
>> On 3/2/2013 3:00 PM, Andrej Mitrovic wrote:
>>> On 3/2/13, Dicebot <m.strashun@gmail.com> wrote:
>>>> Wow, I have never known something like that exists! Is there
>>>> description of what it actually does or source code is only
>>>> possible reference. Depending on actual limitations, it may be a
>>>> game changer.
>>>
>>> I had alook, all it does is avoids generating moduleinfo. I'm not sure
>>> how that helps, the GC still works with this switch.
>>>
>>
>> By not generating moduleinfo, which needs phobos to work, it can link with C
>> only.
>
> But isn't there a few language constructs the specifically rely on the GC?

Yes, and those will fail to link.