On Thu, 2013-05-30 at 02:19 +0200, MrzlganeE wrote:
[…]
> 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;
> }
[…]
> 
>      for (i := 0; i < 24; i++) {
>      }

Go does exactly this, and it is good.

Less is more.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Thursday, May 30, 2013 09:43:36 Russel Winder wrote:
> On Thu, 2013-05-30 at 02:19 +0200, MrzlganeE wrote:
> […]
> 
> > 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;
> > 
> > }
> 
> […]
> 
> >      for (i := 0; i < 24; i++) {
> >      }
> 
> Go does exactly this, and it is good.
> 
> Less is more.

Less would mean not having this syntax, because it would be adding more to the language and therefore increasing its complexity.

Personally, I don't think think that the extra complication caused by having another syntax for something that we already have is worth it, regardless of whether it's aesthetically pleasing or not.

And honestly, I actually think that it would make code _less_ legible. Sure, other languages use this syntax, but the difference between = and := is minor, and we already have auto. So, this adds no functionality whatsoever.

- Jonathan M Davis

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

I'm not completely sold. The convenience seems good, but having declarations and assignments clearly separable is actually rather nice.

This sort of work would - along with other ideas such as physical units etc. - be best placed in a lightweight DSL (domain specific language) that simply hides the necessary mixins etc.

D lends itself to this wonderfully, it would make for a very nice mathematical/scientific language. I'm almost tempted to make such a language myself. Integrated with SciD.... ?? Hmmm, I feel a project coming on.

On 05/30/2013 10:50 AM, Jonathan M Davis wrote:
> On Thursday, May 30, 2013 09:43:36 Russel Winder wrote:
>> On Thu, 2013-05-30 at 02:19 +0200, MrzlganeE wrote:
>> […]
>>
>>> 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;
>>>
>>> }
>>
>> […]
>>
>>>       for (i := 0; i < 24; i++) {
>>>       }
>>
>> Go does exactly this, and it is good.
>>
>> Less is more.
>
> Less would mean not having this syntax,  because it would be adding more to the
> language and therefore increasing its complexity.
>

Not noticeably.

> Personally, I don't think think that the extra complication caused by having
> another syntax for something that we already have is worth it, regardless of
> whether it's aesthetically pleasing or not.
>

The complexity argument is not a strong argument for such a simple feature (It takes around 10 minutes to implement in a compiler and 2s to learn.), especially given the existing complexity of D.

It simply does not fit nicely into the rest of the D declaration syntax. (Which I'd argue is an issue with the C-like syntax of D, but many seem to like that.)

> And honestly, I actually think that it would make code _less_ legible.

In my experience, anything that removes excessive verboseness makes the code more legible.

> Sure, other languages use this syntax, but the difference between = and := is minor,

It is noticeable at a glimpse. It's simply a matter of getting accustomed to new syntax.

> and we already have auto.  So, this adds no functionality whatsoever.
>

It adds functionality to the parser.

On 5/30/13, Timon Gehr <timon.gehr@gmx.ch> wrote:
> It is noticeable at a glimpse. It's simply a matter of getting accustomed to new syntax.

This depends on the person viewing the code. Don't forget not all people have 10/10 vision.

On Thursday, 30 May 2013 at 10:46:54 UTC, Andrej Mitrovic wrote:
> On 5/30/13, Timon Gehr <timon.gehr@gmx.ch> wrote:
>> It is noticeable at a glimpse. It's simply a matter of getting
>> accustomed to new syntax.
>
> This depends on the person viewing the code. Don't forget not all
> people have 10/10 vision.

It is not only matter of vision. People naturally read from left to right and this proposal moves important information about statement to the middle of the line.

If the programmer cannot make a distinction between an assignment and a declaration operator, there will be a lot of trouble!

You could say, p * q and p = q are not visually distinct. They only rely on the difference of an operator to distinguish them.

We can go through countless variations within the language where you get your work done every day relying on visually distinct elements more subtle than this one.

x := 2 / pi*z;
auto x = 2 / pi*z;

z := column(i, x, diag);
auto z = column(i, x, diag);

I don't think it's worth it force all people to write the second form, over a theoretical nitpick that the programmer will possibly forget how interpret symbols.

To me, 'auto' has a price. The price is a foreign word being inserted into my math. It's an invasive term. It ruins the beautiful expression.

If you think the programmer is going to forget how to read symbols, you should consider both sides: "The programmer might forget how to read symbols, but also the programmer will be able to write declarative expressions involving just their own terms."

It's not all bad, you see?

I am trying to reach for an expressiveness which allows such a simple thing -- writing expressions that involve just my own terms: x. 2. pi. z. That's the feature!

And allowing to make expressions with just my own terms is such a small change to the language, we are only inches away from that. It drives me crazy to be so close.

auto x = 2 / pi*z; is like ketchup in my sushi, every time.

Try to consider that people always oppose every single new thing. They would have said the array slices are not C-like enough, and that '..' is not in the C language and should not be used. But we have that great feature now because somebody decided not to be so conservative.

On Thursday, 30 May 2013 at 11:41:34 UTC, MrzlganeE wrote:
> To me, 'auto' has a price. The price is a foreign word being inserted into my math. It's an invasive term. It ruins the beautiful expression.

Please don't pull your math into my programming.

MrzlganeE:

> 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.

I like the ":=" syntax because an assignment is an operation very different from an equality ("="). But then I'd like equality to be expressed with a single equal sign "=", both as in Pascal.

Generally in a language it's bad to have two ore more obvious ways to do something. D is almost compatible with C, so it has several duplications in the ways to do things. Such duplication is justified only when it introduces some significant advantage. This idea introduces a syntax duplication for not enough gain. So I am against it.

Bye,
bearophile