>>>But if someone makes this typo and gets an error message wouldnt she/he mechanically insert the ":" to make the message go away?
>> No. I have used languages with type inference.
>
>I do not get what you want to say with this.

I have used languages with type inference and I never automatically inserted the
needed synthax to define a new variable. Instead I've searched for a typo in the
variable-name.
So I wouldn't mechanically insert the ":" to make the message fo away. And I
doubt many others would do that.

>>>And if you want to prevent typos at all, what other schemes do you propose to secure that the programmer knows what she/he types?
>> 
>> This proposal has nothing to do with typos at all.
>
>Nice try. But please formally define the conditions under which a proposal has something to do with typos. ... Can it be, that you are a super programmer or a bot, capable of switching off the causes of human mistakes at will and getting everything right the first time. I wonder how many years ago the last syntactical or semantical error in one of your programs was detected by a compiler or by testing---or weren't there any ever?

I don't have a formal definition of the conditions under which a proposal has
something to do with typos.
But Ben Hinkle proposed to add more type inference to the language. Than you
asked "And if you want to prevent typos ...". He didn't. He just wanted to have
more type inference.

Matthias Becker wrote in news:dfcddp$6mf$1@digitaldaemon.com

[...]
> I have used languages with type inference and I never automatically inserted the needed synthax to define a new variable. Instead I've searched for a typo in the variable-name. So I wouldn't mechanically insert the ":" to make the message fo away.
[...]
> Than you asked "And if you want to prevent typos ...".
> He didn't. He just wanted to have more type inference.

Now we are at the critical point.

The intended type of a variable can be deduced from either
- an explicit declaration of the intended type of the variable, or
- an implicit inference from the value assigned to the variable.

Explicit declarations are currently of the form
  <defined type> <undefined name> [ '=' <initialization> ]
and assignments are of the form
  <defined name> '=' <expression>

Therefore it would be natural to define as an implicit inference of a
type the form
  <undefined name> '=' <expression>

But that is not the proposal. The proposal is of the form
  <undefined name> ':=' <expression>

A reason must be given for this syntactical salt, this deviation from the natural extension of the language. Bringing compatibility to C, Java and the like as an argument is useless, because this were never design goals for D on the language level. And the design goal of "looks like C, acts like C" has been given up long ago.

If the reason are not typos, what is it then?

-manfred

In article <dfd3dv$mm2$1@digitaldaemon.com>, Manfred Nowak says...
>
>Matthias Becker wrote in news:dfcddp$6mf$1@digitaldaemon.com
>
>[...]
>> I have used languages with type inference and I never automatically inserted the needed synthax to define a new variable. Instead I've searched for a typo in the variable-name. So I wouldn't mechanically insert the ":" to make the message fo away.
>[...]
>> Than you asked "And if you want to prevent typos ...".
>> He didn't. He just wanted to have more type inference.
>
>Now we are at the critical point.
>
>The intended type of a variable can be deduced from either
>- an explicit declaration of the intended type of the variable, or
>- an implicit inference from the value assigned to the variable.
>
>Explicit declarations are currently of the form
>  <defined type> <undefined name> [ '=' <initialization> ]
>and assignments are of the form
>  <defined name> '=' <expression>
>
>Therefore it would be natural to define as an implicit inference of a type the form
>  <undefined name> '=' <expression>
>
>But that is not the proposal. The proposal is of the form
>  <undefined name> ':=' <expression>
>
>A reason must be given for this syntactical salt, this deviation from the natural extension of the language. Bringing compatibility to C, Java and the like as an argument is useless, because this were never design goals for D on the language level. And the design goal of "looks like C, acts like C" has been given up long ago.
>
>If the reason are not typos, what is it then?
>
>-manfred

The = operator already has a well-established meaning in C/C++/Java and I think
D should keep that meaning (which you say is a useless argument but I disagree).
The := introduces extra semantics to = and so it is natural to use a different
symbol.
Another point to keep in mind is that I didn't actually say the left-hand-side
must be an undefined symbol. For example
#  int x = 2;
#  { x = 1; }  // refers to x in outer scope
#  { int x = 3; } // defines a local x in scope
is well-defined in D today. With my proposal one could code up the above as
#  x := 2;
#  { x = 1; }
#  { x := 3; }
whereas with your proposal of reusing = the last statement would have to use the
explicit declaration (presumably - I don't actually know exactly what you
propose and it isn't clear what you mean by "undefined name").

Ben Hinkle wrote in news:dfd5r0$o63$1@digitaldaemon.com

[...]
> The = operator already has a well-established meaning in C/C++/Java and I think D should keep that meaning (which you say is a useless argument but I disagree).

I do not disagree, that you think this way; we only disagree on the the validity of the content of your argument. In the same style I could say, '=' and ':=' have well-established meanings in pascal, etc... or directly attack your argument by stating that in C++ and Java the '=' operator is overloadable and therefore does not have any standard meaning.


> The := introduces extra
> semantics to = and so it is natural to use a different symbol.

This  argument does hold either, because the '=' has already also the extra semantics of separating a function name from its parameter. If your argument is valid you also have to say that natrurally a different symbol has to be used.

By the way: what is natural in a technical environment? I think we should use canonical instead of natural.


> Another point to keep in mind is that I didn't actually say the
> left-hand-side must be an undefined symbol. For example
> #  int x = 2;
> #  { x = 1; }  // refers to x in outer scope
> #  { int x = 3; } // defines a local x in scope
> is well-defined in D today. With my proposal one could code up
> the above as #  x := 2;
> #  { x = 1; }
> #  { x := 3; }
> whereas with your proposal of reusing = the last statement would
> have to use the explicit declaration (presumably - I don't
> actually know exactly what you propose and it isn't clear what
> you mean by "undefined name").

In fact I am not proposing something. I only emphasize the need to mention the rationales behind any proposal.

And I agree, that my informal dividing of the cases into "forms" may have failed. May be I should have better choosen <undefinable name> instead of <defined name> and <definable name> instead of <undefined name>. But to me this is marginal.

Your example seems also to fall short in the same sense, because hiding declared variables in the same scope is illegal in D.

But I agree, that you finally came up with a rational for having an additional token in the language.

-manfred

"Manfred Nowak" <svv1999@hotmail.com> wrote in message news:dffb5m$2j6b$1@digitaldaemon.com...
> Ben Hinkle wrote in news:dfd5r0$o63$1@digitaldaemon.com
>
> [...]
>> The = operator already has a well-established meaning in C/C++/Java and I think D should keep that meaning (which you say is a useless argument but I disagree).
>
> I do not disagree, that you think this way; we only disagree on the the validity of the content of your argument. In the same style I could say, '=' and ':=' have well-established meanings in pascal,

D doesn't try to maintain compatibility with Pascal. We shouldn't feel held back by non-C-family languages.

> etc... or directly attack your argument by stating that in C++ and Java the '=' operator is overloadable and therefore does not have any standard meaning.

Java doesn't have operator overloading. In terms of C++ overloading I have been referring to the buitin = as having standard behavior across C/C++/Java. And even with overloads one can't overload it to also declare.

>> The := introduces extra
>> semantics to = and so it is natural to use a different symbol.
>
> This  argument does hold either, because the '=' has already also the extra semantics of separating a function name from its parameter. If your argument is valid you also have to say that natrurally a different symbol has to be used.

I'm talking about = inside expressions where it already has a meaning. The = symbol is used for different purposes elsewhere in the language but that has nothing to do with = inside expressions.

> By the way: what is natural in a technical environment? I think we should use canonical instead of natural.
>
>
>> Another point to keep in mind is that I didn't actually say the
>> left-hand-side must be an undefined symbol. For example
>> #  int x = 2;
>> #  { x = 1; }  // refers to x in outer scope
>> #  { int x = 3; } // defines a local x in scope
>> is well-defined in D today. With my proposal one could code up
>> the above as #  x := 2;
>> #  { x = 1; }
>> #  { x := 3; }
>> whereas with your proposal of reusing = the last statement would
>> have to use the explicit declaration (presumably - I don't
>> actually know exactly what you propose and it isn't clear what
>> you mean by "undefined name").
>
> In fact I am not proposing something. I only emphasize the need to mention the rationales behind any proposal.

OK - but to me the whole thing seems pretty clear and the trade-offs are clear. Given the previous threads about both of the proposed behaviors I thought there was ample justification for the proposal. I can't read people's minds to know what level of detail of the rationale they want. Asking questions or proposing alternatives (or "attacking" as you say above) is I think a good way to go.

> And I agree, that my informal dividing of the cases into "forms" may have failed. May be I should have better choosen <undefinable name> instead of <defined name> and <definable name> instead of <undefined name>. But to me this is marginal.
>
> Your example seems also to fall short in the same sense, because hiding declared variables in the same scope is illegal in D.

I'm not sure what you mean by "hiding declared variables in the same scope
is illegal". Are you referring to that section in the doc about local
variable rules which is currently unenforced (and I have serious doubts it
will ever be enforced)? In any case I was hoping you'd realize the code
snippet I gave applies to many other situations when a local declaration
hides another variable. For example
  int x;
  void foo() { int x = 1; }
or
  module foo1;
  int x;

  module foo2;
  import foo1;
  void foo() { int x = 1; }

In both cases the x in foo is hiding another x.

> But I agree, that you finally came up with a rational for having an additional token in the language.

I finally decided I had to spell it out.

> -manfred

Ben Hinkle wrote:

[several more or less useful remarks]

My statements on the above would mainly consist of thanks for your kindness and remarks on my opinion how disputes should be held to come to an agreement from different positions. But especially the latter would go to far OT.


>> But I agree, that you finally came up with a rational for having an additional token in the language.
> I finally decided I had to spell it out.

Ooops. If there were posts on this before, then I missed them. Sorry for that.

-manfred

Ben Hinkle escribió:
> I don't know if this has been proposed before but I was thinking how nice it is to work in MATLAB (where you don't have to declare a variable's type) and the following operator came to mind
>   var := init;
> is the same as
>   typeof(init) var = init;
> 

What about the other syntax with this same purpose proposed... mmm... a long time ago?

var foo = <expr>;
//or
autotype foo = <expr>;

-- 
Carlos Santander Bernal

"Carlos Santander" <csantander619@gmail.com> wrote in message news:dfnsj5$19ci$1@digitaldaemon.com...
> Ben Hinkle escribió:
>> I don't know if this has been proposed before but I was thinking how nice
>> it is to work in MATLAB (where you don't have to declare a variable's
>> type) and the following operator came to mind
>>   var := init;
>> is the same as
>>   typeof(init) var = init;
>>
>
> What about the other syntax with this same purpose proposed... mmm... a long time ago?
>
> var foo = <expr>;
> //or
> autotype foo = <expr>;

That still doesn't cover the declaration-in-expressions that makes up the second half of the proposal. Plus IMHO foo := <expr> is shorter and doesn't take up a keyword.

> -- 
> Carlos Santander Bernal

"Carlos Santander" <csantander619@gmail.com> wrote in message news:dfnsj5$19ci$1@digitaldaemon.com...
> Ben Hinkle escribió:
>> I don't know if this has been proposed before but I was thinking how nice
>> it
>> is to work in MATLAB (where you don't have to declare a variable's type)
>> and
>> the following operator came to mind
>>   var := init;
>> is the same as
>>   typeof(init) var = init;
>>
>
> What about the other syntax with this same purpose proposed... mmm... a
> long
> time ago?
>
> var foo = <expr>;
> //or
> autotype foo = <expr>;
>
> -- 
> Carlos Santander Bernal

Since I can't sleep :-( I tried converting another example from dmd/samples.
I've attached four versions. The first is the original htmlget.d. The others
are htmlget_autotype.d, htmlget_colon_eq.d and htmlget_cpp.d. The changes
from the orginal have BVH in a comment in order to make it easier to pick
out the changes. The autotype file replaces 7 declarations with autotype.
The colon_eq version replaces 9 declarations and = uses with :=. The cpp
version replaces 2 class instantiations with one of the proposed shortcut
forms of using C++-like style
  ClassName var(arg1, arg2, ...);
to mean
  ClassName var = new ClassName(arg1, arg2, ...);
There isn't anything deep about the example chosen. It was another randomly
opened file from dmd/samples meant to illustrate how these different
proposals would look in (presumably typical) existing code.