The D programming language is great, and it is starting to get the recognition it deserves. I've seen it reach the top 20 in many different measures of language popularity.

What it is though, is a systems language. Of course it has many features of a higher-level language, which is what makes it great. But I've had an idea for another language, a high-level language, that is nearly as fast as a similar D program.

What it looks like is a D preprocessor that translates Python-like code into D code. It was done before, and the result was called Delight. I'm reviving this idea (though with entirely new code, since the previous version was with D1).

A short list of the best features (that aren't already a part of D):

* Python-like syntax
* List comprehensions
* "0 .. x" works everywhere, as I would expect it to

If you're interested, check it out at http://github.com/pplantinga/delight. I need people to break it and argue about design decisions.

A more complete description of the language can be found at http://pplantinga.github.io/archives/delight-programming-language.html and related pages.

On Friday, 28 March 2014 at 07:20:31 UTC, Peter Plantinga wrote:
> The D programming language is great, and it is starting to get the recognition it deserves. I've seen it reach the top 20 in many different measures of language popularity.
>
> What it is though, is a systems language. Of course it has many features of a higher-level language, which is what makes it great. But I've had an idea for another language, a high-level language, that is nearly as fast as a similar D program.
>
> What it looks like is a D preprocessor that translates Python-like code into D code. It was done before, and the result was called Delight. I'm reviving this idea (though with entirely new code, since the previous version was with D1).
>
> A short list of the best features (that aren't already a part of D):
>
> * Python-like syntax
> * List comprehensions
> * "0 .. x" works everywhere, as I would expect it to
>
> If you're interested, check it out at http://github.com/pplantinga/delight. I need people to break it and argue about design decisions.
>
> A more complete description of the language can be found at http://pplantinga.github.io/archives/delight-programming-language.html and related pages.

Just out of interest, but any plans to convert blocks of delight code in a file and output the resulting D version? Also will that work at CTFE?
I could see some use for this if my plans for when D's front end is in D fully.
Note I have some evil plans involving a macro preprocessor and a c frontend ;)

> Just out of interest, but any plans to convert blocks of delight code in a file and output the resulting D version? Also will that work at CTFE?

Actually that's the way it works now. The program always outputs D code. You can also choose to pass it through to a D compiler. Since the code just gets passed to the D compiler, it does as much CTFE as D does.

On Friday, 28 March 2014 at 10:11:52 UTC, Peter Plantinga wrote:
>
>> Just out of interest, but any plans to convert blocks of delight code in a file and output the resulting D version? Also will that work at CTFE?
>
> Actually that's the way it works now. The program always outputs D code. You can also choose to pass it through to a D compiler. Since the code just gets passed to the D compiler, it does as much CTFE as D does.

Hmm I see. I haven't seen any examples using a string mixin to use a delight file. And thats what interested in.

If it's just a preprocessor, I guess string mixins with delight don't compile.

On Friday, 28 March 2014 at 11:59:47 UTC, Kagamin wrote:
> If it's just a preprocessor, I guess string mixins with delight don't compile.

In theory there should be no reason it cannot. Assuming its not doing something like reading files (note you can catch this and say not at CTFE).
Proof that a preprocessor can be used for this [0].

Yes a macro preprocessor that runs at compile time.

[0] https://github.com/rikkimax/ctfepp/blob/master/source/main.d

I'm asking because from experience the difference in design between allowing it to run at CTFE and not is quite big. And without getting heavy into it and understanding the code base I cannot go confirm that.

On 28/03/14 13:48, Rikki Cattermole wrote:

> In theory there should be no reason it cannot. Assuming its not doing
> something like reading files (note you can catch this and say not at CTFE).
> Proof that a preprocessor can be used for this [0].

You can use a string import to read a file.

-- 
/Jacob Carlborg

On Friday, 28 March 2014 at 14:34:52 UTC, Jacob Carlborg wrote:
> On 28/03/14 13:48, Rikki Cattermole wrote:
>
>> In theory there should be no reason it cannot. Assuming its not doing
>> something like reading files (note you can catch this and say not at CTFE).
>> Proof that a preprocessor can be used for this [0].
>
> You can use a string import to read a file.

As far as I'm concerned it can be simply a string in the program and I would handle it. But I am a huge buff for making things run both at ctfe and at runtime.