Hi,

Please consider a request for just one piece of syntax sugar in D.

In places where I write a bunch of short mathy code, I do not want to use 'auto'. The := operator would allow to declare a variable, deduce its type, and define its value.

void main() {
    x := 1;
    y := 2.0;
    z := x * y;
    y = 3.0;
}

I do not want to see the word 'auto', because it has little to do with the problem I am expressing. I find it distracting. 'auto' suggests D's type system -- but I am just thinking of the algorithm. I want to see less words about the type system, and focus my eyes on the problem that I am solving.

I realize that D is not about syntax sugar, but this is different:

- It is easily understood by computer scientists, and mathematicians coming from many different backgrounds -- it's not obscure like a perl syntax construct.

- I would not write 'auto' while expressing an algorithm on a whiteboard. But I may very well write :=

- It has a historical record of use in old BNF-grammar languages.

- I think people would really *use* it, where they don't want to use auto today.

- It's not 'un-C-like' -- it is only not-like-C, because C didn't support the feature. It is actually a natural fit!

    for (i := 0; i < 24; i++) {
    }

- It is very easily remembered: If you've seen it once, you know it.

Today, I would rather write 'double y = 2.0;' than 'auto y = 2.0;'
But := would change that.

Please consider it.

- MrzlganeE

On Thursday, 30 May 2013 at 00:20:00 UTC, MrzlganeE wrote:
> Hi,
>
> Please consider a request for just one piece of syntax sugar in D.
>
> In places where I write a bunch of short mathy code, I do not want to use 'auto'. The := operator would allow to declare a variable, deduce its type, and define its value.
>
> void main() {
>     x := 1;
>     y := 2.0;
>     z := x * y;
>     y = 3.0;
> }
>
> I do not want to see the word 'auto', because it has little to do with the problem I am expressing. I find it distracting. 'auto' suggests D's type system -- but I am just thinking of the algorithm. I want to see less words about the type system, and focus my eyes on the problem that I am solving.
>
> I realize that D is not about syntax sugar, but this is different:
>
> - It is easily understood by computer scientists, and mathematicians coming from many different backgrounds -- it's not obscure like a perl syntax construct.
>
> - I would not write 'auto' while expressing an algorithm on a whiteboard. But I may very well write :=
>
> - It has a historical record of use in old BNF-grammar languages.
>
> - I think people would really *use* it, where they don't want to use auto today.
>
> - It's not 'un-C-like' -- it is only not-like-C, because C didn't support the feature. It is actually a natural fit!
>
>     for (i := 0; i < 24; i++) {
>     }
>
> - It is very easily remembered: If you've seen it once, you know it.
>
> Today, I would rather write 'double y = 2.0;' than 'auto y = 2.0;'
> But := would change that.
>
> Please consider it.
>
> - MrzlganeE


You can do this:

template Math(string code) {
    enum Math = transform(code); // Do whatever CTFE transforms you want
}

mixin Math!q{
    x := 1;
    y := 2;

    writeln(x*y);
};

Although it will be a lot easier when std.regex works at compile time...

Diggory:  That's very cool -- being able to do that in D. Thanks for showing me :)

But it is not even a remotely practical solution.
    The idea is to write less, and so the solution you've given is to write more mixins all over the place. I said I don't even want to write 'auto', I am surely not writing the big mixin chunk.

I only gave an example of math stuff.
But I'd use := for the non-math stuff too.

I want := it to be available everywhere.
Even if I am just typing a snippet into dpaste.

If D implements this, C++ will try to copy it 10 years later.
It's a futuristic thing -- what is old is new.

On Thursday, 30 May 2013 at 01:35:58 UTC, MrzlganeE wrote:
> Diggory:  That's very cool -- being able to do that in D. Thanks for showing me :)
>
> But it is not even a remotely practical solution.
>     The idea is to write less, and so the solution you've given is to write more mixins all over the place. I said I don't even want to write 'auto', I am surely not writing the big mixin chunk.
>
> I only gave an example of math stuff.
> But I'd use := for the non-math stuff too.
>
> I want := it to be available everywhere.
> Even if I am just typing a snippet into dpaste.
>
> If D implements this, C++ will try to copy it 10 years later.
> It's a futuristic thing -- what is old is new.

The mixin definition only needs to exist once, and you can use "mixin" anywhere - you could wrap an entire source file in it:

mixin!q{

/* All of your code */

}

On Thursday, 30 May 2013 at 02:51:47 UTC, Diggory wrote:
> On Thursday, 30 May 2013 at 01:35:58 UTC, MrzlganeE wrote:
>> Diggory:  That's very cool -- being able to do that in D. Thanks for showing me :)
>>
>> But it is not even a remotely practical solution.
>>    The idea is to write less, and so the solution you've given is to write more mixins all over the place. I said I don't even want to write 'auto', I am surely not writing the big mixin chunk.
>>
>> I only gave an example of math stuff.
>> But I'd use := for the non-math stuff too.
>>
>> I want := it to be available everywhere.
>> Even if I am just typing a snippet into dpaste.
>>
>> If D implements this, C++ will try to copy it 10 years later.
>> It's a futuristic thing -- what is old is new.
>
> The mixin definition only needs to exist once, and you can use "mixin" anywhere - you could wrap an entire source file in it:
>
> mixin!q{
>
> /* All of your code */
>
> }

*mixin Math!q{ ... };

mixins make the code more ugly and the error messages' line numbers will
not be in sync with the code, IIRC.
I would like this syntax sugar too.

It's also used in GO, btw.

On Wed, May 29, 2013 at 7:52 PM, Diggory <diggsey@googlemail.com> wrote:

> On Thursday, 30 May 2013 at 02:51:47 UTC, Diggory wrote:
>
>> On Thursday, 30 May 2013 at 01:35:58 UTC, MrzlganeE wrote:
>>
>>> Diggory:  That's very cool -- being able to do that in D. Thanks for showing me :)
>>>
>>> But it is not even a remotely practical solution.
>>>    The idea is to write less, and so the solution you've given is to
>>> write more mixins all over the place. I said I don't even want to write
>>> 'auto', I am surely not writing the big mixin chunk.
>>>
>>> I only gave an example of math stuff.
>>> But I'd use := for the non-math stuff too.
>>>
>>> I want := it to be available everywhere.
>>> Even if I am just typing a snippet into dpaste.
>>>
>>> If D implements this, C++ will try to copy it 10 years later. It's a futuristic thing -- what is old is new.
>>>
>>
>> The mixin definition only needs to exist once, and you can use "mixin" anywhere - you could wrap an entire source file in it:
>>
>> mixin!q{
>>
>> /* All of your code */
>>
>> }
>>
>
> *mixin Math!q{ ... };
>

Ok, Diggory, thanks for your consideration. I want to keep the code clean and direct, with reliable error messages, with consistent output line numbers, with standard semantic highlight support in D editors, etc. I do not want to use a level of indirection or CTFE all of my code. I would rather write auto than have all my code go through CTFE just for one operator. As mentioned, I want it available on dpaste too.

I'd just like to say that my intention here specifically is to request a feature for the D programming language, that we can all use -- it's not just for me and my macro.

On 05/29/2013 05:19 PM, MrzlganeE wrote:

> The := operator would allow to declare a variable, deduce
> its type, and define its value.
>
> void main() {
>      x := 1;
>      y := 2.0;
>      z := x * y;
>      y = 3.0;
> }

I like it.

Ali

Am 30.05.2013 07:41, schrieb Ali Çehreli:
> On 05/29/2013 05:19 PM, MrzlganeE wrote:
>
>  > The := operator would allow to declare a variable, deduce
>  > its type, and define its value.
>  >
>  > void main() {
>  >      x := 1;
>  >      y := 2.0;
>  >      z := x * y;
>  >      y = 3.0;
>  > }
>
> I like it.
>
> Ali
>

It is like is done in Go.

Don't like it. Makes declaration visually less distinguishable from further usage.