On Sat, 29 Jun 2013 17:01:54 -0400, Walter Bright
<[email protected]> wrote:
On 6/29/2013 12:18 PM, Ary Borenszweig wrote:
What you are asking is essentially what Crystal does for all variables
(and types):
https://github.com/manastech/crystal/wiki/Introduction#type-inference
Your example would be written like this:
x = 3
y = f()
x = 3.9
But since Crystal transforms your code to SSA
(http://en.wikipedia.org/wiki/Static_single_assignment_form) you
actually have
*two* "x" variables in your code. The first one is of type Int32, the
second of
type Float64.
Sorry, but that seems like a solution in search of a problem.
And besides, yuk. Imagine the bugs caused by "hey, it doesn't implicitly
convert, so instead of letting the user know he goofed, let's just
silently create a new variable!"
x is a variant that is compile-time optimized to be an int or a float.
Where would the bug be? If x could possibly change types depending on
runtime data, then x is given a type of a union between int or float.
It would be somewhat like the compiler optimizing this:
{
Variant v = 1;
v = 3.5;
}
to:
{
int v = 1;
}
{
float v = 3.5;
}
because it sees that during the optimized scopes, v is only used as that
specific type.
It seems like the compiler is generating variants that can hold exactly
the types that are used for that variable. Interesting concept.
-Steve
