Rémi Forax schrieb: > Le 01/11/2009 19:22, Charles Oliver Nutter a écrit : >> Very nice! I want to actually implement this in Duby+Surinx merged >> into a single language, but also start implementing it for JRuby. We >> are moving toward an SSA-based compiler IR for future versions of >> JRuby which may make it easier to propagate type information when >> possible. >> > > Hi Charles, > Fortunately, you're exist. I have a reader :) > When I was writing this entry I was wondering how many people > will really take a look to bytecode dumps.
Oh you would wonder... In fact we call it optional typing in Groovy, but it is really very much like gradual typing. Only the compiler is not using the type information to speed up the program. We will change that for Groovy 1.8. I should maybe try to explain a difference between the Java type system and the one Groovy uses. In Groovy a method call on an object with Type T is not limited to the methods declared for this type. Instead the runtime type is used. Since Groovy supports overloading of methods too, that means you cannot relay on information you find in the type, unless it is a really a direct match. If you have an Object typed variable x and do x.foo(), and the runtime type of x will be Foo, which has a foo() method, then the call will succeed. Since we at compile time don't know the type Foo, we cannot generate a direct method call for that. And now optional typing in 1.8 will come into play. You can type the variable as Foo and the compiler will be able to generate a direct method call on x using Foo. Also in Groovy you don't need casts when you assign something to a typed variable. Instead Groovy will add an implicit cast. This way Groovy ensures, that the variable will contain an object of at least that type all the time. It is like declaring an upper bound kind of (if parents are above). > In pseudo, I don't do any type propagation, i.e > no more that what a classical typechecking do. > I just do only one thing to avoid some dynamic cast, > I back-propagate expected type from the node to > the leaf. i.e if a function is dynamic but is assigned > to an int, I encode that this function need an int > as return type. that is different from what Groovy does. If the method would return any other number, it may still work, depending on range and kind of that number. But it needs a conversion of course. Instead in 1.8 we will try finding the called method like Java Groovy does not really support different return types. So if we know the name, the receiver and the argument types, we can maybe find a method that directly matches does requirements. If we do, then we can generate a direct method call. We will then also know the return type of course. You course is more easy, since you don't need to search the other class. On the summit I did show that Groovy can be extremely slow for the Fibonacci example. But that is because we first have to get loose of all the synchronization stuff we currently do in the runtime. That is there for a good reason, just that it does make Groovy slower even in the single threaded cases. bye blackdrag -- Jochen "blackdrag" Theodorou The Groovy Project Tech Lead (http://groovy.codehaus.org) http://blackdragsview.blogspot.com/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~---
