On Sunday, 3 March 2013 at 05:18:13 UTC, Daniel Murphy wrote:
> "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.

Yes, more than a beginning. This is a higher-level approach than mine, clearly.

In your estimation, how high-level is your approach compared to my lower-level one? How far would each of us have to travel to meet in the middle, in other words? :)

On Sunday, 3 March 2013 at 05:48:30 UTC, Walter Bright wrote:
> 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.

I think original we started with dmd being GC dependent and that this causes problems for some platforms. To move dmd to d source and be more platform independent one would need the core spec to be GC independent. IIRC arrays depend on the GC for cleanup and therefore this would need to be changed to allow arrays in the core. Really what is needed is gc arrays and ngc arrays as well as other essential features. e.g., gc arrays would not be part of the core spec while ngc arrays would.

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

I did something like that before (token-level pattern matching) and found the number of special cases to be much much too high.  You need so much context information you're better off just building an ast and operating on that.

For the nastier special cases, I'm modifying the compiler source to eliminate them.  This mostly means expanding macros and adding casts.

Many of the same ideas apply, although I'm not trying to eg use native arrays and strings, just a direct port.

On Sunday, 3 March 2013 at 05:48:30 UTC, Walter Bright wrote:
> 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.

Thank you. I need to check out how it works in practice to evaluate applicability but that definitely looks like a step in needed direction.

> Really what is needed is gc arrays and ngc arrays as well as other essential features. e.g., gc arrays would not be part of the core spec while ngc arrays would.

You can already use slices without a gc, like this:

T[] allocate(T)(int n)
{
    return (cast(T*) malloc(T.sizeof * n))[0 .. n];
}

void deallocate(T)(ref T[] a)
{
    free(a.ptr)
    a = null;
}

Of course, you can not append to such slices or expand them without a GC. It would be useful to have a @nogc flag which would result in an error if a feature that needs a GC was used.

I think adding @nogc would be better than defining a "core spec", because most D code does not need that feature. If we add a a @nogc flag, the people that don't need it can just ignore its existence and do not need to learn about it, but if we call the subset of D that doesn't use a GC a "core spec", people will feel that's something they need to learn, which will make the language seem more complex.

On Saturday, 2 March 2013 at 18:48:37 UTC, Dicebot wrote:
> 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.

I believe a subset of D could prove interesting to C programmers the same way the full D language looks interesting to C++ programmers. With the added benefit that one could fairly easily learn the full language from the subset language.

On Mar 3, 2013 10:56 AM, "Dicebot" <m.strashun@gmail.com> wrote:
>
> On Sunday, 3 March 2013 at 05:48:30 UTC, Walter Bright wrote:
>>
>> 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.
>
>
> Thank you. I need to check out how it works in practice to evaluate
applicability but that definitely looks like a step in needed direction.

I intend to fix this problem in gdc at least by removing _tlsstart and _tlsend from the library.

Regards
-- 
Iain Buclaw

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

On Sunday, 3 March 2013 at 13:56:57 UTC, Iain Buclaw wrote:
> I intend to fix this problem in gdc at least by removing _tlsstart and
> _tlsend from the library.
>
> Regards

Ugh, which problem are you speaking about? "betterC" flag is not working properly in gdc or what?

On Mar 3, 2013 2:21 PM, "Dicebot" <m.strashun@gmail.com> wrote:
>
> On Sunday, 3 March 2013 at 13:56:57 UTC, Iain Buclaw wrote:
>>
>> I intend to fix this problem in gdc at least by removing _tlsstart and _tlsend from the library.
>>
>> Regards
>
>
> Ugh, which problem are you speaking about? "betterC" flag is not working
properly in gdc or what?

This "betterC" is not currently implemented at all.  Would rather have, say -ffreestanding switch which would go a little further and not emit implicit library calls.

What I'm referring to is one potential  link issue when compiling C/C++ that interfaces with D.

Regards
-- 
Iain Buclaw

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

On Sunday, 3 March 2013 at 12:05:00 UTC, jerro wrote:
>> Really what is needed is gc arrays and ngc arrays as well as other essential features. e.g., gc arrays would not be part of the core spec while ngc arrays would.
>
> You can already use slices without a gc, like this:
>
> T[] allocate(T)(int n)
> {
>     return (cast(T*) malloc(T.sizeof * n))[0 .. n];
> }
>
> void deallocate(T)(ref T[] a)
> {
>     free(a.ptr)
>     a = null;
> }
>
> Of course, you can not append to such slices or expand them without a GC. It would be useful to have a @nogc flag which would result in an error if a feature that needs a GC was used.
>
> I think adding @nogc would be better than defining a "core spec", because most D code does not need that feature. If we add a a @nogc flag, the people that don't need it can just ignore its existence and do not need to learn about it, but if we call the subset of D that doesn't use a GC a "core spec", people will feel that's something they need to learn, which will make the language seem more complex.

A core spec is not just about gc features. It was also about migrating the compiler from C++ to D. The core spec can provide many useful benefits but the gc shouldn't be one of them.

What happens when you append to a slice using manual allocation? Does the compiler throw an error or just crash and burn? A core language spec for a self-compiler is required and because it must be gc agnostic to work across a multitude of platforms(most to work well with embedded apps or for performance reasons) one needs a way to signify this(hence marking modules as being gc-free and having ngc constructs).

For example, by marking a module as core it can only use other core modules. Since a core module can't use the gc any all arrays are ngc and gc operations on them would be in error. This also helps when migrating a module from non-core to core once you get the module compiled you know it is gc free(as well as other things).