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.
