On Tuesday, 16 June 2015 at 20:57:03 UTC, Walter Bright wrote:
> Use of expression templates in C++ to implement DSLs is probably some of the most awful code ever conceived.

Whereas string mixins allow us to do all kinds of crazy stuff with DSLs if you want to - but they're clearly confined in strings where you're not going to mistake them for normal D code. It's _very_ cool how Pegged is able to take a grammar in normal, PEG format, and generate a parser from it. But attempting anything like that with expression templates would have been horrible.

- Jonathan M Davis

On 2015-06-16 22:36, Jonathan M Davis wrote:

> Sounds like it's preventing an abuse of operator overloading to me... :)

Sounds like it's preventing a perfectly good use case. Or do you prefer AST macros instead :)

-- 
/Jacob Carlborg

On 2015-06-16 22:59, Walter Bright wrote:

> #define BEGIN {
> #define END }
>
> Freedom! Freedom! Freedom!
>
> https://www.youtube.com/watch?feature=player_detailpage&v=lEOOZDbMrgE#t=163

And the current approach to operator overload is soooo much better, preventing all abuse:

struct Int
{
    int a;

    int opBinary(string s)(Int rhs) if (s == "+")
    {
        return a - rhs.a;
    }
}

-- 
/Jacob Carlborg

On Wednesday, 17 June 2015 at 05:09:54 UTC, Jonathan M Davis wrote:
> On Tuesday, 16 June 2015 at 20:57:03 UTC, Walter Bright wrote:
>> Use of expression templates in C++ to implement DSLs is probably some of the most awful code ever conceived.

A lot of things in C++ are ill-conceived, but templates were not designed to do things like that. So the language does not endorse it.

Mal-features like string-mixins and multiple-alias-this endorse writing ugly code. Those are deliberate features. And it is actually worse than Javascript...

> Whereas string mixins allow us to do all kinds of crazy stuff with DSLs if you want to - but they're clearly confined in strings where you're not going to mistake them for normal D code. It's _very_ cool how Pegged is able to take a grammar in normal, PEG format, and generate a parser from it. But attempting anything like that with expression templates would have been horrible.

I've noticed that a key difference between D and Javascript programmers is that the latter group through-and-through acknowledge that eval() is a problematic feature.

On Wednesday, 17 June 2015 at 06:23:15 UTC, Jacob Carlborg wrote:
> Sounds like it's preventing a perfectly good use case. Or do you prefer AST macros instead :)

Given the direction D2 has taken since D1, I'd say that I'm starting to agree with you that powerful symbolic programming would be the better deal overall.

But it would take a major restructuring:

1. a simpler more orthogonal core language to cut down on the special casing when doing AST manipulations

2. a clean separation between library and application code (that way you can limit AST hacks to libraries tie library versions to language versions.

So it won't happen… since you would then have essentially need a new language?

On Wednesday, 17 June 2015 at 06:23:15 UTC, Jacob Carlborg wrote:
> On 2015-06-16 22:36, Jonathan M Davis wrote:
>
>> Sounds like it's preventing an abuse of operator overloading to me... :)
>
> Sounds like it's preventing a perfectly good use case. Or do you prefer AST macros instead :)

I prefer that operators actually do what they're supposed to do per how they work with the built-in types and that they not be redefined to do something else. An operator which is overloaded specifically do something other than what occurs with the built-in types is just begging for problems. Sure, we can't prevent all operator overloading abuses, and they can be misimplemented just like any other function, but the whole point of having operator overloading is to make it so that user-defined types can look and operate like built-in types, not to invent new syntax, and I think that inventing new syntax via operator overloading is a _very_ clear abuse of it. And I really don't think that folks should be trying to add syntax to the language for DSLs or anything of the sort, and I'm very glad that D prevents that in many cases while still allowing us to have useful features such as operator overloading.

- Jonathan M Davis

On 06/17/2015 02:28 PM, Jonathan M Davis wrote:
> On Wednesday, 17 June 2015 at 06:23:15 UTC, Jacob Carlborg wrote:
>> On 2015-06-16 22:36, Jonathan M Davis wrote:
>>
>>> Sounds like it's preventing an abuse of operator overloading to me... :)
>>
>> Sounds like it's preventing a perfectly good use case. Or do you
>> prefer AST macros instead :)
>
> I prefer that operators actually do what they're supposed to do per how
> they work with the built-in types and that they not be redefined to do
> something else. An operator which is overloaded specifically do
> something other than what occurs with the built-in types is just begging
> for problems. Sure, we can't prevent all operator overloading abuses,
> and they can be misimplemented just like any other function, but the
> whole point of having operator overloading is to make it so that
> user-defined types can look and operate like built-in types, not to
> invent new syntax, and I think that inventing new syntax via operator
> overloading is a _very_ clear abuse of it. And I really don't think that
> folks should be trying to add syntax to the language for DSLs or
> anything of the sort, and I'm very glad that D prevents that in many
> cases while still allowing us to have useful features such as operator
> overloading.
>
> - Jonathan M Davis

FWIW, the use case presented was roughly to make the database look and operate like built-in arrays.

On Tue, 16 Jun 2015 03:05:06 -0700, Walter Bright wrote:

> On 6/14/2015 4:03 AM, ketmar wrote:
>> honestly, if i'll want to have a limited language, i'll take Go.
> 
> Go doesn't have conditional compilation.

you got it!


>  > removing a power only 'cause it can be abused is not in a "spirit of
>  > D",
> 
> Actually, D does quite a bit of that. For example, it deliberately does not allow > to be overloaded separately from <. It does not allow multiple inheritance. It does not allow structs to have virtual functions.
> 
> (All of these deliberate limitations have had their proponents.)

and you know what? people constantly trying to "fix" that. what is funny is that sometimes ugly kludges are even considered for inclusion into language ("multiple `alias this`, i'm looking at you! ah, and `alias this` for that matter).

i also wonder why we have `opCmp` and `opEquals` instead of `opEquals` and `opLess` only. having so powerful `opCmp` surely opens alot way to abuse it.

On Tue, 16 Jun 2015 03:10:01 -0700, Walter Bright wrote:

> I have yet to see a single case of "needing" boolean versions that could not be refactored into something much more readable and maintainable that did not use such.

and i have yet to see such cases for multiplication operator. it's cryptic, it's hard to read, it looks like line noise. isn't this clear and readable?

  a = 5.mul(12);

and now see the stupid line noise, introduced by "*":

  a = 5*12;

wtf?! what is that star? some trash from modem?! surely, people can write a function to do multiplication if they need it:

  T mul(T a, T b) { T res = a; foreach (_; 1..b) res += a; return res; }

simle and elegant. yes, it doesn't work with floats or negative `b`, but hey, it's for readability! if you want to process negative `b`, write `mulneg`!

so i'm sure that "*" as multiplication should be removed from the language.

On Wednesday, 17 June 2015 at 17:18:42 UTC, ketmar wrote:
> On Tue, 16 Jun 2015 03:05:06 -0700, Walter Bright wrote:
>
>> On 6/14/2015 4:03 AM, ketmar wrote:
>>> honestly, if i'll want to have a limited language, i'll take Go.
>> 
>> Go doesn't have conditional compilation.
>
> you got it!
>
>
>>  > removing a power only 'cause it can be abused is not in a "spirit of
>>  > D",
>> 
>> Actually, D does quite a bit of that. For example, it deliberately does not allow > to be overloaded separately from <. It does not allow multiple inheritance. It does not allow structs to have virtual functions.
>> 
>> (All of these deliberate limitations have had their proponents.)
>
> and you know what? people constantly trying to "fix" that. what is funny is that sometimes ugly kludges are even considered for inclusion into language ("multiple `alias this`, i'm looking at you! ah, and `alias this` for that matter).

sometimes I find 'alias this' quite elegant, such as using alias this to a function. Other times I find it to be a poor hack to get around the lack of struct inheritance.