The "type" type dream

[Robert Fraser]

bearophile wrote:
> Robert Fraser:
>> For an example, take a look at ShedSkin
> 
> I have given a hand developing ShedSkin with Mark, and I am helping its development now too :-)

Awesome! That's one of the coolest OSS projects out there!

> I agree it may not be able to scale to medium or large programs, currently it can handle programs of about 3000-5000 lines. But note that:
> - it's written in Python, so using a faster language (like Java or D) it can become significantly faster (but writing it in Java or D may require lot of work, despite it's only few thousands or lines of code).
> - Mark has not used a lot of tricks that if used can speed up the code more. The code was not even profiled.
> - ShedSkin used a pure approach: it uses no type signatures at all, given by the programmer.

It would still only work for private (non-exported) function in D. If 
given the earlier example of "f(x, y) { x.add(y); }", the compiler would 
know about A and B, so could generate overloads for those two. But the 
compiler would have to know about every other class in the program with 
an "add" method to be able to codegen for the function. This just 
wouldn't be possible with D's current compilation model, and if it were, 
it would lead to crazy code bloat anyway.

> - There's also the trick of progressive compilation. If integrated into the editor such type inferencing can digest the program in smaller bites, making the actual compilation faster. This is of course not easy to do, but it's possible. Note that something similar also allows you to create an IDE for dynamic languages that has capabilities similar to the IDEs for static languages.

IDEs only need to consider the forward case (flow analysis), so it's 
much simpler. If everywhere in the current program only cals a function 
foo with Bars, it's OK to suggest methods only from Bar. However when 
exporting a function to be linked/executed in an unknown environment, 
the function needs to be ready for anything.

Also, IDEs don't need 100% accuracy in 100% of cases. If the IDE is 
missing some methods or can't make a suggestion, that sucks, but the IDE 
is still usable. Native-code compilers, however, need 100%.

 > But I was not suggesting to use a full type inferencing in D. This 
means that in a more realistic system you add several type signatures, 
and this will speed the algorithm a lot.
 > Scala is an example of OO language that also has some type inferencing.

Wish I had read this before starting on the rest of this post ;-P. Sure, 
I guess limited type inference can't be bad, though it's not on my "must 
have" list for D. "auto" is good enough, IMO.