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.
