On Wednesday, 13 November 2013 at 19:25:18 UTC, Walter Bright wrote:
> On 11/13/2013 11:24 AM, Walter Bright wrote:
>> Actually, there is a way to do this. I wrote an article years back on how to
>> write "statement" workalikes using lazy function parameters. I suppose I should
>> dig that up if I can find it.
>
> Ah, found the code:
>
> void ifthen(bool cond, lazy void dg)
> {
>     if (cond)
>         dg();
> }
>
> void ifthen(bool cond, lazy void dgthen, lazy void dgelse)
> {
>     if (cond)
>         dgthen();
>     else
>         dgelse();
> }
>
> void dotimes(int i, lazy int dg)
> {
>     for (int j = 0; j < i; j++)
>         dg();
> }
>
> void switcher(bool delegate()[] cases...)
> {
>     foreach (c; cases)
>     {
>         if (c())
>             break;
>     }
> }
>
> bool scase(bool b, lazy void dg)
> {
>     if (b)
>     {
>         dg();
>         return true;
>     }
>     return false;
> }
>
> bool sdefault(lazy void dg)
> {
>     dg();
>     return true;
> }
>
> void whiler(lazy bool cond, lazy void bdy)
> {
>     while (cond())
>         bdy();
> }
>
> void test1()
> {
>     int x = 3;
>     dotimes(5, printf("%d\n", ++x));
>
>     ifthen(true, printf("yes\n"));
>     ifthen(false, printf("no\n"));
>
>     ifthen(true, printf("yes\n"), printf("no\n"));
>     ifthen(false, printf("yes\n"), printf("no\n"));
>
>     int v = 2;
>     switcher(
>         scase(v == 1, printf("it is 1\n")),
>         scase(v == 2, printf("it is 2\n")),
>         scase(v == 3, printf("it is 3\n")),
>         sdefault( printf("it is default\n"))
>     );
>
>     whiler( x < 100,
>         (printf("%d\n", x), x *= 2)
>     );
> }

Was is missing is the capability to look into the lazy parameter's ast and act accordingly.

Here you can wrap something around code, not generation code depending on passed code.

> //this would invoke compiler's parser at CTFE
> auto ast = "x = y;".astof
> ast.toString() //get back a string of D code
>
Right, that's the basic functionality we want.
What's not clear is how to get the type of y.

On 11/12/2013 10:16 PM, Dicebot wrote:
> Add there "foo.codeof" in the toolset and it will pretty much give core
> needed stuff.

Well, codeof is nice but it lacks the parser.

On 11/13/2013 2:18 PM, deadalnix wrote:
> Was is missing is the capability to look into the lazy parameter's ast and act
> accordingly.
>
> Here you can wrap something around code, not generation code depending on passed
> code.

That's correct. But you can look into the AST with expression templates. So, expression templates combined with lazy arguments and mixin templates may fill the problem space.

On Wednesday, 13 November 2013 at 12:21:22 UTC, Jacob Carlborg wrote:

> I need to read up on what expression templates can do.

But where to read? There's no such thing as "expression template" explicitly mentioned in here.

http://dlang.org/template.html

--rt

On Wednesday, 13 November 2013 at 22:34:02 UTC, Walter Bright wrote:
> On 11/13/2013 2:18 PM, deadalnix wrote:
>> Was is missing is the capability to look into the lazy parameter's ast and act
>> accordingly.
>>
>> Here you can wrap something around code, not generation code depending on passed
>> code.
>
> That's correct. But you can look into the AST with expression templates. So, expression templates combined with lazy arguments and mixin templates may fill the problem space.

Expression templates are limited to expression and require to use its own set of types. Still the idea has some merits.

On 11/13/2013 3:58 PM, deadalnix wrote:
> On Wednesday, 13 November 2013 at 22:34:02 UTC, Walter Bright wrote:
>> On 11/13/2013 2:18 PM, deadalnix wrote:
>>> Was is missing is the capability to look into the lazy parameter's ast and act
>>> accordingly.
>>>
>>> Here you can wrap something around code, not generation code depending on passed
>>> code.
>>
>> That's correct. But you can look into the AST with expression templates. So,
>> expression templates combined with lazy arguments and mixin templates may fill
>> the problem space.
>
> Expression templates are limited to expression and require to use its own set of
> types.

Yes. But that's a good thing. I'd be pretty skeptical of the value of an AST macro that took 3+4 and changed it so it did something other than compute 7.


> Still the idea has some merits.

It has the merit of being implemented and available right now :-)

I do understand that expression templates aren't very sexy, and are kinda hard to wrap one's head around. But they're not so bad from the perspective of the user of the expression templates, and I really think that the limits of existing features should be explored before inventing wholesale new ones that may turn out to be redundant.

On 11/13/2013 3:27 PM, Rob T wrote:
> But where to read? There's no such thing as "expression template" explicitly
> mentioned in here.


This may help:

http://www.dsource.org/projects/ddl/browser/trunk/meta/regex.d

On Thursday, 14 November 2013 at 00:16:45 UTC, Walter Bright wrote:
> I do understand that expression templates aren't very sexy, and are kinda hard to wrap one's head around. But they're not so bad from the perspective of the user of the expression templates, and I really think that the limits of existing features should be explored before inventing wholesale new ones that may turn out to be redundant.

My very first project in D involved quite a lot of them. So I very aware of what they are.

The whole idea is to be able to extends that to statement and declarations. Making what expression templates can do is simply a side effect so to speak.

On 11/13/2013 5:14 PM, deadalnix wrote:
> My very first project in D involved quite a lot of them. So I very aware of what
> they are.
>
> The whole idea is to be able to extends that to statement and declarations.

My question about that is just what problem is this trying to solve, and why that problem cannot be reformulated in terms of expression templates?

I.e. we shouldn't be adding things to D just because they are cool. They need to solve a problem that is fairly commonplace and too painful to solve with existing mechanisms. The larger the proposed language enhancement is, the more commonplace and and painful the problems must be that it purports to solve.


> Making what expression templates can do is simply a side effect so to speak.