Ben Hinkle wrote:
> 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;
> 
I'm on the opinion that the var type is important and worthy enough to be mentioned at least once.

-- 
Bruno Medeiros
Computer Science/Engineering student

>> Note - I wouldn't say the proposal is to "get rid" of declarations. The proposal is to infer the type of the declaration from the initialization expression. The user still has to write := instead of = which indicates "declare and assign".
>
>In fact you are proposing some sort of micro template, because you need not know anything of the type of the RHS.

Type inference was there long before the word 'template' was used in programming languages. Anyway I don't get wat typeinference has to do with templates.

>Or from another point of view, you are giving names to the otherweise unnamed intermediate results of the actual parameters of function calls.
>  f( index:= g( h( 1)));
>
>Whenever this is usefull: why do you need the redundance of the ":="  and the fact, that the name on the LHS is undefined?
>
>Why doesn't it suffice to simply write
>  index= g( h( 1));
>and if `index' is not defined yet, then the "=" tranforms into your ":=" implicitely?
>
>Do you fear, that someone makes a typo and therefore
>  indx= g( h( 1));
>goes undetected?

Yes. I used BASICs and the like and this is an error that often occures.

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

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

"Bruno Medeiros" <daiphoenixNO@SPAMlycos.com> wrote in message news:df2r7u$2c6$3@digitaldaemon.com...
> Ben Hinkle wrote:
>> 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;
>>
> I'm on the opinion that the var type is important and worthy enough to be mentioned at least once.

Two points to consider:
1) the use of := is optional so if one wants to see types one can code them
in
2) temporary values hide types all the time already. Expressions like
foo(bar()) don't indicate the type of the temporary result from bar passed
to foo. In the same way
  tmp := bar();
  foo(tmp);
doesn't show the type.

It might be worthwhile to see another sample. I've pasted below the before-and-after use of := for the dmd sample sieve.d (I hope Walter doesn't mind!)

bit flags[8191];
int main()
{   int     i, prime, k, count, iter;

    printf("10 iterations\n");
    for (iter = 1; iter <= 10; iter++)
    {   count = 0;
        flags[] = true;
        for (i = 0; i < flags.length; i++)
        {   if (flags[i])
            {   prime = i + i + 3;
                k = i + prime;
                while (k < flags.length)
                {
                    flags[k] = false;
                    k += prime;
                }
                count += 1;
            }
        }
    }
    printf ("\n%d primes\n", count);
    return 0;
}


and after substituting := where appropriate

bit flags[8191];
int main()
{   int     count;

    printf("10 iterations\n");
    for (iter := 1; iter <= 10; iter++)
    {   count = 0;
        flags[] = true;
        for (i := 0; i < flags.length; i++)
        {   if (flags[i])
            {   prime := i + i + 3;
                k := i + prime;
                while (k < flags.length)
                {
                    flags[k] = false;
                    k += prime;
                }
                count += 1;
            }
        }
    }
    printf ("\n%d primes\n", count);
    return 0;
}

Notice the net effect is removing those pesky (and pretty much meaningless) int declarations just inside main().

In article <df4clp$1ng3$1@digitaldaemon.com>, Ben Hinkle says...
>
>
>"Bruno Medeiros" <daiphoenixNO@SPAMlycos.com> wrote in message news:df2r7u$2c6$3@digitaldaemon.com...
>> Ben Hinkle wrote:
>>> 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;
>>>
>> I'm on the opinion that the var type is important and worthy enough to be mentioned at least once.
>
>Two points to consider:
>1) the use of := is optional so if one wants to see types one can code them
>in
>2) temporary values hide types all the time already. Expressions like
>foo(bar()) don't indicate the type of the temporary result from bar passed
>to foo. In the same way
>  tmp := bar();
>  foo(tmp);
>doesn't show the type.
>
>It might be worthwhile to see another sample. I've pasted below the before-and-after use of := for the dmd sample sieve.d (I hope Walter doesn't mind!)
>
>bit flags[8191];
>int main()
>{   int     i, prime, k, count, iter;
>
>    printf("10 iterations\n");
>    for (iter = 1; iter <= 10; iter++)
>    {   count = 0;
>        flags[] = true;
>        for (i = 0; i < flags.length; i++)
>        {   if (flags[i])
>            {   prime = i + i + 3;
>                k = i + prime;
>                while (k < flags.length)
>                {
>                    flags[k] = false;
>                    k += prime;
>                }
>                count += 1;
>            }
>        }
>    }
>    printf ("\n%d primes\n", count);
>    return 0;
>}
>
>
>and after substituting := where appropriate
>
>bit flags[8191];
>int main()
>{   int     count;
>
>    printf("10 iterations\n");
>    for (iter := 1; iter <= 10; iter++)
>    {   count = 0;
>        flags[] = true;
>        for (i := 0; i < flags.length; i++)
>        {   if (flags[i])
>            {   prime := i + i + 3;
>                k := i + prime;
>                while (k < flags.length)
>                {
>                    flags[k] = false;
>                    k += prime;
>                }
>                count += 1;
>            }
>        }
>    }
>    printf ("\n%d primes\n", count);
>    return 0;
>}
>
>Notice the net effect is removing those pesky (and pretty much meaningless) int declarations just inside main().
>
>

Whoa now... red flag going up.  What scope are those new variables in?  If assuming the local scope of the := assignment expression, then your translation is not direct.

Regards,
James Dunne

>>and after substituting := where appropriate
>>
>>bit flags[8191];
>>int main()
>>{   int     count;
>>
>>    printf("10 iterations\n");
>>    for (iter := 1; iter <= 10; iter++)
>>    {   count = 0;
>>        flags[] = true;
>>        for (i := 0; i < flags.length; i++)
>>        {   if (flags[i])
>>            {   prime := i + i + 3;
>>                k := i + prime;
>>                while (k < flags.length)
>>                {
>>                    flags[k] = false;
>>                    k += prime;
>>                }
>>                count += 1;
>>            }
>>        }
>>    }
>>    printf ("\n%d primes\n", count);
>>    return 0;
>>}
>>
>>Notice the net effect is removing those pesky (and pretty much
>>meaningless)
>>int declarations just inside main().
>>
>>
>
> Whoa now... red flag going up.  What scope are those new variables in?  If
> assuming the local scope of the := assignment expression, then your
> translation
> is not direct.

Yup - I didn't bother pointing out that the := version also narrowed the scopes. That's why "count" needed to remain at the main() scope since it is used outside of the iter for loop. Otherwise I would have made that a := also. I think using the narrow scopes is a benefit over the original just as modern C++ coding standards recommend declaring variables in the smallest scope just before usage. We don't live in K&R C anymore.

> There could be some advantages to 'auto' too. It could be used to make
> simple
> templates:
>
> auto f(auto x) { return x+1;}
>
> This would be most useful when defining function literals. Like:
>
> LongTypeName[] all = whatever(...);
> auto good = filter(all, function auto(auto x) { return x.isGood(); });
>
> One alternative is to add type declarations implicitly when missing in
> function
> literals... Just remove the auto above:
>
> filter(all, function(x) { return x.isGood(); });

Interesting. I hadn't thought of auto in function parameter lists and return values. Do you know if the C++ auto can do that? I don't even have a reference for what C++ auto proposal actually is so any links would be appreciated.

"Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:df4uko$28pd$1@digitaldaemon.com...
> Interesting. I hadn't thought of auto in function parameter lists and return values. Do you know if the C++ auto can do that? I don't even have a reference for what C++ auto proposal actually is so any links would be appreciated.

This might help: http://www.informit.com/guides/content.asp?g=cplusplus&seqNum=219

The proposal is available here: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1607.pdf

Ben Hinkle wrote:
>>>
>>>Notice the net effect is removing those pesky (and pretty much meaningless)
>>>int declarations just inside main().
>>>
>>>
>>
>>Whoa now... red flag going up.  What scope are those new variables in?  If
>>assuming the local scope of the := assignment expression, then your translation
>>is not direct.
> 
> 
> Yup - I didn't bother pointing out that the := version also narrowed the scopes. That's why "count" needed to remain at the main() scope since it is used outside of the iter for loop. Otherwise I would have made that a := also. I think using the narrow scopes is a benefit over the original just as modern C++ coding standards recommend declaring variables in the smallest scope just before usage. We don't live in K&R C anymore. 
> 
> 

The narrow(er?) scope is indeed a benefit, but that could be done without ":=".
-- 
Bruno Medeiros
Computer Science/Engineering student

Oskar wrote:
> In article <det4pk$16si$1@digitaldaemon.com>, Ben Hinkle says...
> 
>>
>>There's a proposed C++ extension that uses 'auto' (or maybe 'decl' I can't remember). I prefer the operator because
>>1) it's less typing (one of the goals of the idea is to cut down verbosity)
>>2) it is used to declare variables in expressions, too.
> 
> 
> There could be some advantages to 'auto' too. It could be used to make simple
> templates:
> 
> auto f(auto x) { return x+1;}
> 
> This would be most useful when defining function literals.
>[...]

Please stop calling that "auto". There is already an auto keyword in D, which does a whole different thing.

-- 
Bruno Medeiros
Computer Science/Engineering student

Matthias Becker wrote in news:df47ja$1i7b$1@digitaldaemon.com

[...]
> Anyway I don't get wat typeinference has to do with templates.

Maybe there is nothing to get.


[...]
> Yes. I used BASICs and the like and this is an error that often occures.

I used especially `awk' and I had several bugs which turned out to be caused by a typo in the name of a variable, thereby destroying the intended control flow.


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


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

-manfred