On 7/1/2013 10:07 AM, Timon Gehr wrote:
> module b;
> int x;
>
> module a;
>
> void main(){
>      int x;
>      {
>          import b;
>          x = 2;

I'd encourage you to submit an enhancement request that would produce the message:

Error: import b.x hides local declaration of x

>      }
>      import std.stdio;
>      writeln(x); // prints 0
> }
>

On 7/1/2013 10:51 AM, deadalnix wrote:
> But if you one very stupid one, I declared in the late 90s that a phone with a
> tactile screen on its whole surface was a stupid idea and that it would never work.
> I you look hard enough, I guess we all said the most stupid thing at some point.
> We got to admit it and not repeat the mistake.

None of us have to look very hard at ourselves to find such, if we're being remotely honest.

I don't much care for the popular "gotcha" practice of digging up something someone did or said decades ago. It presumes that we are all born wise, and offers no hope for learning from our mistakes. Sadly, the internet and the surveillance state are going to make life difficult for anyone trying to live down something stupid.

Makes me glad I grew up before the internet. Makes me glad that most of the drivel I posted to Usenet back in the 80's has been hopefully lost :-)

On Monday, 1 July 2013 at 17:51:02 UTC, deadalnix wrote:
> On Monday, 1 July 2013 at 16:57:53 UTC, JS wrote:
>> (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)))
>
> For the record, this quote is plain wrong : https://groups.google.com/forum/#!msg/alt.folklore.computers/mpjS-h4jpD8/9DW_VQVLzpkJ


I liked this answer:

" QUESTION: I read in a newspaper that in 1981 you said, "640K  should be enough for anybody."

I always thought he was talking about his monthly bonus,  not computer memory... "

:)

Matheus.

On 07/01/2013 10:51 AM, deadalnix wrote:

> I declared in the late 90s that a phone
> with a tactile screen on its whole surface was a stupid idea and that it
> would never work.

I still think so. :D

Ali

On 7/1/13 9:57 AM, JS wrote:
> 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").

To me the basic notion was very clear from day one. Changing the type of a variable is equivalent with "unaliasing" the existing variable (i.e. destroy it and force it out of the symbol table) and defining an entirely different variable, with its own lifetime. It just so happens it has the same name.

It's a reasonable feature to have -- a nice cheat that brings a statically-typed language closer to the look-and-feel of dynamic languages. Saves on names, which is more helpful than one might think. In D things like overloading and implicit conversions would probably make it too confusing to be useful.

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

It's obvious to me that the concept is sound within reasonable use bounds.

> 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 think this is an unfair characterization. The discussion was pretty good and gave the notion a fair shake.

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

Yes, and in fact it's already done. Consider:

if (expr)
{
    int a;
    ...
}
else
{
    int b;
    ...
}

In some C implementations, a and b have the same physical address. In some others, they have distinct addresses. This appears to not be related, but it is insofar as a and b have non-overlapping lifetimes.

>  Is this a
> good thing? Yes or no?

It's marginally good - increases stack locality and makes it simpler for a register allocator. (In fact all register allocators do that already, otherwise they'd suck.)

> (I don't need and don't want any explanation)

Too late :o).


Andrei

On 7/1/13 9:59 AM, Walter Bright wrote:
> Sorry for the sarcasm, but I just don't get the notion that it's a
> burden to use a different name for a variable that has a different type
> and a different purpose. I'd go further and say it is a bad practice to
> use the same name for such.

Reducing the number of names seems worthless, but increasing it can be quite annoying.

Andrei

On 7/1/2013 4:30 PM, Andrei Alexandrescu wrote:
> Yes, and in fact it's already done. Consider:
>
> if (expr)
> {
>      int a;
>      ...
> }
> else
> {
>      int b;
>      ...
> }
>
> In some C implementations, a and b have the same physical address. In some
> others, they have distinct addresses. This appears to not be related, but it is
> insofar as a and b have non-overlapping lifetimes.

What is happening with (modern) compilers is the "live range" of each variable is computed. A live range is nothing more than a bitmap across the instructions for a function, with a bit set meaning "the variable is in play at this point".

The compiler then uses a "tetris" style algorithm to try to fit as many variables as possible into the limited register set, and to use as little stack space as possible.

The usual algorithms do not use scoping to determine the live range, but look at actual usage. A variable that, for example, that has no usage is considered 'dead' and is removed.

The proposal here neither adds nor subtracts from this.

On Monday, 1 July 2013 at 23:30:19 UTC, Andrei Alexandrescu wrote:
> On 7/1/13 9:57 AM, JS wrote:
>> 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").
>
> To me the basic notion was very clear from day one. Changing the type of a variable is equivalent with "unaliasing" the existing variable (i.e. destroy it and force it out of the symbol table) and defining an entirely different variable, with its own lifetime. It just so happens it has the same name.
>
> It's a reasonable feature to have -- a nice cheat that brings a statically-typed language closer to the look-and-feel of dynamic languages. Saves on names, which is more helpful than one might think. In D things like overloading and implicit conversions would probably make it too confusing to be useful.
>
>> 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....
>
> It's obvious to me that the concept is sound within reasonable use bounds.
>
>> 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 think this is an unfair characterization. The discussion was pretty good and gave the notion a fair shake.
>
>> 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?
>
> Yes, and in fact it's already done. Consider:
>
> if (expr)
> {
>     int a;
>     ...
> }
> else
> {
>     int b;
>     ...
> }
>
> In some C implementations, a and b have the same physical address. In some others, they have distinct addresses. This appears to not be related, but it is insofar as a and b have non-overlapping lifetimes.
>
>> Is this a
>> good thing? Yes or no?
>
> It's marginally good - increases stack locality and makes it simpler for a register allocator. (In fact all register allocators do that already, otherwise they'd suck.)
>
>> (I don't need and don't want any explanation)
>
> Too late :o).
>
>
> Andrei

Too be honest, your reply seems to be the only one that attempts to discuss exactly what I asked. Nothing more, nothing less. I do realize there was some confusion between what Crystal does and what I'm talking about... I still think the two are confused by some and I'm not sure if anyone quite gets exactly what I am talking about(Which is not re-aliasing any variables, using a sort of variant type(directly at least), or having a multi-variable(e.g., crystal)).

Would would be nice is an experimental version of D where would could easily extend the language to try out such concepts to see if they truly are useful and how difficult to implement. e.g., I could attempt to add said "feature", it could be merged with the experimental compiler, those interested can download the compiler and test the feature out... all without negatively affecting D directly. If such features could be implemented dynamically then it would probably be pretty powerful.


The example I gave was sort of the reverse. Instead of expanding the type into a supertype we are reducing it.

  float x;
  x = 3;

x could be stored as a byte which would potentially be an increase in performance. Reducing the type can be pretty dangerous though unless it is verifiable. I'm somewhat convinced that expanding the type is almost always safe(at least in safe code) although not necessarily performant. IMO it makes auto more powerful in most cases but only having a test bed can really say how much.

On 7/1/13 6:29 PM, JS wrote:
> Would would be nice is an experimental version of D where would could
> easily extend the language to try out such concepts to see if they truly
> are useful and how difficult to implement. e.g., I could attempt to add
> said "feature", it could be merged with the experimental compiler, those
> interested can download the compiler and test the feature out... all
> without negatively affecting D directly. If such features could be
> implemented dynamically then it would probably be pretty powerful.

I don't think such a feature would make it in D, even if the implementation cost was already sunken (i.e. an implementation was already done and one pull request away).

Ascribing distinct objects to the same symbol is a very core feature that affects and is affected by everything else. We'd design a lot of D differently if that particular feature were desired, and now the fundamentals of the design are long frozen. For a very simple example, consider:

auto a = 2.5; // fine, a is double
...
a = 3;

By the proposed rule a will become an entirely different variable of type int, and the previous double variable would disappear. But current rules dictate that the type stays double. So we'd either have an unthinkably massive breakage, or we'd patch the language with a million exceptions.

Even so! If the feature were bringing amazing power, there may still be a case in its favor. But fundamentally it doesn't bring anything new - it's just alpha renaming; it doesn't enable doing anything that couldn't be done without it.


Andrei

On Tuesday, 2 July 2013 at 02:15:09 UTC, Andrei Alexandrescu wrote:
> On 7/1/13 6:29 PM, JS wrote:
>> Would would be nice is an experimental version of D where would could
>> easily extend the language to try out such concepts to see if they truly
>> are useful and how difficult to implement. e.g., I could attempt to add
>> said "feature", it could be merged with the experimental compiler, those
>> interested can download the compiler and test the feature out... all
>> without negatively affecting D directly. If such features could be
>> implemented dynamically then it would probably be pretty powerful.
>
> I don't think such a feature would make it in D, even if the implementation cost was already sunken (i.e. an implementation was already done and one pull request away).
>
> Ascribing distinct objects to the same symbol is a very core feature that affects and is affected by everything else. We'd design a lot of D differently if that particular feature were desired, and now the fundamentals of the design are long frozen. For a very simple example, consider:
>
> auto a = 2.5; // fine, a is double
> ...
> a = 3;
>

No, not under what I am talking about. You can't downgrade a type, only upgrade it. a = 3, a is still a float. Using the concept I am talking about, your example does nothing new.

but reverse the numbers:

auto a = 3;
a = 2.5;

and a is now a float, and your logic then becomes correct EXCEPT a is expanded, which is safe.

I really don't know how to make it any clearer but I'm not sure if anyone understands what I'm talking about ;/



> By the proposed rule a will become an entirely different variable of type int, and the previous double variable would disappear. But current rules dictate that the type stays double. So we'd either have an unthinkably massive breakage, or we'd patch the language with a million exceptions.
>
> Even so! If the feature were bringing amazing power, there may still be a case in its favor. But fundamentally it doesn't bring anything new - it's just alpha renaming; it doesn't enable doing anything that couldn't be done without it.
>
>

Expanding a type is always valid because it just consumes more memory. A double can always masquerade as an int without issue because one just wastes 4 bytes. An int can't masquerade as a double because any function think uses it as a double will cause corruption of 4 bytes of memory.

(I'm ignoring that a double and int use different cpu instructions. This is irrelevant unless we are hacking stuff up)


The simplest example I can give is:

auto x = 2;
x = 2.5;

x IS a double, regardless of the fact that auto x = 2; makes it look like an int BECAUSE that is how auto currently is defined(which might be the confusion).

The reason is, that the compiler looked at the scope for all assignments to x and was able to determine automatically that x needed to be a double.


I'll give one more way to look at this, that is a sort of inbetween but necessary logical step:

We have currently that auto looks at the immediate assignment after it's keyword to determine the type, correct?

e.g.,

auto x = 3;

What if we allow auto to look at the first assignment to x, not necessarily the immediate assignment, e.g.:

auto x;
x = 3;

(should be identical to above)

or

auto x;
.... (no assignments to x)
x = 3;

All this should be semantically equivalent, correct? To me, the last case is more powerful since it is more general. Of course, one could argue that it makes it more difficult to know the type of x but I doubt this would be a huge issue.