2014-06-04 11:33 GMT+02:00 Henrik Johansen <henrik.s.johan...@veloxit.no>:
> > On 03 Jun 2014, at 6:32 , Camille Teruel <camille.ter...@gmail.com> wrote: > > > On 3 juin 2014, at 17:34, Johan Fabry <jfa...@dcc.uchile.cl> wrote: > > > On Jun 3, 2014, at 4:21 AM, Camille Teruel <camille.ter...@gmail.com> > wrote: > > To what I understand, types are inferred, it is not statically typed. Am I > wrong ? > > > If there is type inference then it is statically typed (at least partially > if not every variable type can be inferred) > > > To repeat myself: this is not the case. Example is the RoelTyper. > > > Yes, there are many type inferencers for dynamically-typed languages. > But that's not because one builds a type inferencer for say Smalltalk that > I can say "Smalltalk has type inference": the inferencer is not integrated > within the language, it's just an analysis tool on top. > If someone says that his language has type inference, he means that the > type inferencer is built into the language, and normally there is some type > checking and/or the compiler is designed to leverage type information which > means that the language is at least partially statically-typed (if not > entirely). > Because if a language does no type checking nor type-based optimisations, > for what purpose would it have type inference built into it? > > > Inferred types have an often overlooked purpose that, IMHO, in dynamic > languages, is their biggest benefit. > That being, it can reduce the number of false positives in common > development actions such as auto-complete, searching for implementors, etc. > > A pharo with built-in type inference would be no better. > A pharo with built-in type inference, and tools utilizing it, would. > > It’s a bit of a shame that programmer productivity is a less favourable > research area than optimization, when in that case, using the much cheaper > type info from PIC’s instead, yield equivalent results. > (ref. http://www.cs.ucsb.edu/~urs/oocsb/papers/oopsla95-tf.pdf) > > This is actually possible in Pharo. If you compile the Cog VM with the Sista Cogit, you have then in addition the introspection primitive that returns branch and send data from native code methods. Now you cannot use these inferred types for tools. There are 3 main issues, one is that the VM answers you concrete types and not an abstract type, the second is that not all message sends have type information (the method may not be linked to a native code method, the message send may not have been used since the native code method has been compiled and megamorphic send sites have no type information) and the last issue is that the type inferred are common types, if you can use another type in an uncommon case you may not see it. - you needs a type inferencer for tools. - you need type information from the inline caches for optimizations. And as proven in the early 90s type inferencer does not work well to optimize dynamic object oriented language and type-feedback does not work well for tools as I explained. Clement Cheers, > Henry >
