Automatic typing

JS js.mdnq at gmail.com
Mon Jul 1 09:57:52 PDT 2013


On Monday, 1 July 2013 at 16:15:04 UTC, Walter Bright wrote:
> On 7/1/2013 6:39 AM, Ary Borenszweig wrote:
>>> This is not what I am talking about and it seems quite 
>>> dangerous to have
>>> one variable name masquerade as multiple variables.
>>
>> Why dangerous?
>
> D already disallows:
>
>     int x;
>     {   float x;
>     }
>
> as an error-prone construct, so why should it allow:
>
>     int x;
>     float x;
>
> ?
>
I'm not "proposing" this. There is only one variable.

I think there is big confusion in what I'm "suggesting"(it's not 
a proposal because I don't expect anyone to take the time to 
prove its validity... and you can't know how useful it could be 
if you don't have any way to test it out).

It's two distinctly different concepts when you allow a 
"multi-variable" and one that can be "up-typed" by inference(the 
compiler automatically "up-types").



>> I've been programming in Ruby for quite a time and never found 
>> it
>> to be a problem, but an advantage.
>
> What advantage? Does Ruby have a shortage of names for 
> variables? (Early versions of BASIC only allowed variable names 
> with one letter, leading to some pretty awful workarounds.)
>
>
>> Show me an example where this is dangerous (the pointer 
>> example gave by Walter
>> is not valid anymore since it has a fix).
>
> I'm actually rather sure that one can come up with rule after 
> rule to 'fix' each issue, but good luck with trying to fit all 
> those rules into some sort of comprehensible framework. 
> Consider what happened to C++ when they tried to fit new things 
> into the overloading rules - the rules now span multiple pages 
> of pretty arbitrary rules, and practically nobody understands 
> the whole. What people do is randomly try things until it seems 
> to do the right thing for them, and then they move on.
>
> And all this for what - nobody has come up with a significant 
> reason to support this proposal. I see post after post in this 
> thread trying to make it work, and nothing about what problem 
> it solves.

I'm more interested in a true counterexample where my 
concept(which I've not seen in any language before) results in an 
invalid context.... and not a naive example that uses a half 
baked implementation of the algorithm(which I've already 
outlined). Just because someone comes up with an example and says 
"this will produce a non-termination" doesn't mean it will except 
in the most naive implementations.

The problem is when such a "idea" is present you get people who 
are automatically against it for various irrational fears and 
they won't take any serious look at it to see if it has any 
merit...  If you jump to the conclusion that something is useless 
without any real thought on it then it obviously is... but the 
same type of mentality has been used to "prove" just about 
anything was useless at one time or another. (and if that 
mentality ruled we'd still be using 640k of memory)


I have a very basic question for you and would like a simple 
answer:

In some programming languages, one can do the following type of 
code:

var x; // x is some type of variable that holds data. It's type 
is not statically defined and can change at run time.
x = 3; // x holds some type of number... usually an integer but 
the language may store all numbers as doubles or even strings.

now, suppose we have a program that contains essentially the 
following:

var x;
x = 3;

Is it possible that the compiler can optimize such code to find 
the least amount of data to represent x without issue? Yes or no? 
Is this a good thing? Yes or no? (I don't need and don't want any 
explanation)

(the above example is at the heart of the matter... regardless if 
it is probably a valid semantic in D or easily to implement(since 
no one knows and most don't care because they think it won't 
benefit them(just like how bill gates thought all everyone needed 
was 640k)))


More information about the Digitalmars-d mailing list