On 01/08/2013 10:06 PM, Philippe Sigaud wrote:
> ...
>
> Isn't SDC also in D? (Bernard Helyer and friends)
> https://github.com/bhelyer/SDC
>
>
> Also, Timon Gehr spoke of his own front-end (assumed to be in D) in the
> past, but did not provide any link to it.
>

Yes, it is in D. Nothing is released yet. It needs to be polished a little so that there are no known embarrassing shortcomings anymore.
(eg. the parser cannot parse extern(...) declarations in alias declarations yet, and I need to finish making a minor tweak to how template instances are analyzed in order to get circular dependency detection to work reliably. Furthermore, examples like the following are currently rejected, while I want it to work:

enum x = "enum xx = q{int y = 0;};";

struct S{
    mixin(xx);
    mixin(x);
}

<mixin@mxin.d:5>:1:6: error: declaration of 'xx' smells suspiciously fishy
enum xx = q{int y = 0;};
     ^~
mxin.d:4:11: note: this lookup should have succeeded if it was valid
    mixin(xx);
          ^~


It shouldn't be a too large change, as eg. this already works:

struct S{
    enum z = y;
    enum x = "enum xx = q{immutable y = 123;};";
    mixin(xx);
    mixin(x);
    static assert(z == 123);
}

(DMD chokes on both.)

Furthermore, I need to implement exceptions, modules, and some parts of compile time reflection + tons of really small features. (Where all ambiguities and contradictions are detected according to well-defined rules instead of resolved or choked on randomly as DMD likes to do.)

Also, it obviously needs a repl. :-)

CTFE is basically done (as a portable byte code interpreter, but other strategies, such as JIT, could be easily plugged). This is a snippet of my regression test suite:

auto dynRangePrimes(){
    DynRange!int impl(int start)=>

dynRange(cons(start,delay(()=>filter!(a=>a%start)(impl(start+1)))));
    return impl(2);
}

static assert(array(take(dynRangePrimes(), 20)) == [2,3,5,7,11,13,17,19,23,29,31,37,41,43,47,53,59,61,67,71]);

)

I also need to decide on a licence. I assume that the alpha will be out in late spring. (I am busy until early spring.)

>
> But, to answer the OP question: no, there are no plan to switch to D for
> the reference compiler in the near future, as far as I can tell.
>
>

On 2013-01-09 12:05, Timon Gehr wrote:

> Yes, it is in D. Nothing is released yet. It needs to be polished a
> little so that there are no known embarrassing shortcomings anymore.

I've might have missed this front end. Any links ?

-- 
/Jacob Carlborg

On Wed, Jan 9, 2013 at 12:05 PM, Timon Gehr <timon.gehr@gmx.ch> wrote:
> Yes, it is in D. Nothing is released yet. It needs to be polished a little so that there are no known embarrassing shortcomings anymore.

What? That's FOSS, release early, release often!

> (DMD chokes on both.)
>
> Furthermore, I need to implement exceptions, modules, and some parts of compile time reflection + tons of really small features. (Where all ambiguities and contradictions are detected according to well-defined rules instead of resolved or choked on randomly as DMD likes to do.)

Makes me salivate.


> Also, it obviously needs a repl. :-)

Obviously.

And direct programmatic access to the lexer and the parser. I'm coding a macro system for D right now, as an over-layer above DMD (like rdmd) and having to create the AST by myself to transform them according to the user-defined macros is a pain.

> CTFE is basically done (as a portable byte code interpreter, but other strategies, such as JIT, could be easily plugged).

Great!

> This is a snippet of my regression test suite:
>
> auto dynRangePrimes(){
>     DynRange!int impl(int start)=>
>
> dynRange(cons(start,delay(()=>filter!(a=>a%start)(impl(start+1)))));
>     return impl(2);
> }
>
> static assert(array(take(dynRangePrimes(), 20)) ==
> [2,3,5,7,11,13,17,19,23,29,31,37,41,43,47,53,59,61,67,71]);

Lazy recursive range, right? As the usual Haskell definition for a prime generator. Nice!

> I also need to decide on a licence.

Unless you've reason not to, I'd advise using the same as Phobos: Boost.

> I assume that the alpha will be out in late spring. (I am busy until early spring.)

You can count me in to test it (I gather to prefer to code this as you see fit, right now). You could also present it at the D conf.


In any cases, congratulations for what seems to be a elegantly done D implementation.

On Wednesday, 9 January 2013 at 11:05:56 UTC, Timon Gehr wrote:
> I also need to decide on a licence. I assume that the alpha will be out in late spring. (I am busy until early spring.)
>

I'm not really a specialist in terms of license, but it'd be nice if it is compatible with SDC's.

On 2013-01-09 13:54, deadalnix wrote:

> I'm not really a specialist in terms of license, but it'd be nice if it
> is compatible with SDC's.

SDC uses the MIT license.

-- 
/Jacob Carlborg

On Wed, Jan 9, 2013 at 1:58 PM, Jacob Carlborg <doob@me.com> wrote:
> On 2013-01-09 13:54, deadalnix wrote:
>
>> I'm not really a specialist in terms of license, but it'd be nice if it is compatible with SDC's.
>
>
> SDC uses the MIT license.

Well, I'd use (and hack) any D compiler written in D, whatever the license. Let Timon code it, when the only left is the license, all will be well and good.

On Tuesday, 8 January 2013 at 21:57:17 UTC, H. S. Teoh wrote:

>
> We *could* write a cross-compiler, of course, but it still requires that
> you first target the D compiler (written in D) to the new platform, and
> then cross-compile itself to that platform.  Whereas with DMD, you just
> use the target platform's C++ compiler and you're up and running.
>
>
> T

I think LDC 2.0 or GDC 2.0 might be able to serve this purpose.

O
> Yes, it is in D. Nothing is released yet. It needs to be polished a little so that there are no known embarrassing shortcomings anymore.
> (eg. the parser cannot parse extern(...) declarations in alias declarations yet, and I need to finish making a minor tweak to how template instances are analyzed in order to get circular dependency detection to work reliably.

How are you implementing the code generating back-end for the compiler?

In your design, I would recommend keeping the front-end separate from the back-end so that maybe the front-end can be connected to the LDC or GDC back-ends.

On 1/9/13 5:10 AM, Philippe Sigaud wrote:
> On Wed, Jan 9, 2013 at 1:58 PM, Jacob Carlborg<doob@me.com>  wrote:
>> On 2013-01-09 13:54, deadalnix wrote:
>>
>>> I'm not really a specialist in terms of license, but it'd be nice if it
>>> is compatible with SDC's.
>>
>>
>> SDC uses the MIT license.
>
> Well, I'd use (and hack) any D compiler written in D, whatever the
> license. Let Timon code it, when the only left is the license, all
> will be well and good.

Once http://d.puremagic.com/issues/show_bug.cgi?id=9285 is done we'll have a realistic means to progressively port dmd's official front end into D by translating one module at a time and linking together C++ and D code. dtoh would serve as the bridge generator and would allow us to avoid maintaining duplicate declarations.

Andrei

On Wed, Jan 09, 2013 at 12:05:55PM +0100, Timon Gehr wrote:
> On 01/08/2013 10:06 PM, Philippe Sigaud wrote:
[...]
> >Also, Timon Gehr spoke of his own front-end (assumed to be in D) in the past, but did not provide any link to it.
> >
> 
> Yes, it is in D. Nothing is released yet. It needs to be polished a little so that there are no known embarrassing shortcomings anymore.
[...]
> CTFE is basically done (as a portable byte code interpreter, but other strategies, such as JIT, could be easily plugged). This is a snippet of my regression test suite:
> 
> auto dynRangePrimes(){
>     DynRange!int impl(int start)=>
> 
> dynRange(cons(start,delay(()=>filter!(a=>a%start)(impl(start+1)))));
>     return impl(2);
> }
> 
> static assert(array(take(dynRangePrimes(), 20)) ==
> [2,3,5,7,11,13,17,19,23,29,31,37,41,43,47,53,59,61,67,71]);
> 
> )

Whoa!!! Now you really caught my interest!

Can it handle CTFE-computed mixins that declare and reference variables? If it can, I will finally be able to write a library AA implementation that allows static AA literals (no runtime init/allocation needed)!


T

-- 
Meat: euphemism for dead animal. -- Flora