Jochen Theodorou wrote: > why do we discuss that? You are talking about the development process of > the spec itself. I not. It is simply a difference if you specify > something, write tests for that and then test if your implementation > works according to the spec, or if you use an implementation and say > that is my spec. The first requires a finished spec, the second a > finished implementation. What we really have is that we have a draft for > the spec and an implementation, and the spec will be updated because of > the implementation and the implementation will be updated because of the > spec... it is an incremental process to develop something. And in such > cases you cannot take any test as if it where your final spec.
No, but we can identify a behavior that's been implemented and has a test written and say "this should/will be in the spec". We can also identify behavior that's missing and needs a test. I have a lot of respect for John but he can't know all the vagaries of implementing Ruby. So I'm trying to make sure he understands each and every pain point in JRuby, to ensure that invokedynamic addresses as many of them as possible. That's what I'm hoping to accomplish with a lot of back-and-forth during these early stages. Perhaps I just like experimenting, but it seems like there's a lot of value to be had from diving in right now and pushing the design forward. > hehe, no, of course not. Groovy too does not use all bytecode commands, > that are available, only a subset. But I doubt that you in JRuby have to > worry about a method argument being an int or long. longs require two > slots, ints only one, so it influences indexes for local variables and > also commands when you reorder the arguments. Well I guess you know that. JRuby uses local variables whenever possible, just like Groovy does, and we have to adjust incoming method signatures and local variable offsets the same. And there's various bits and pieces in my compiler to support different argument list lengths and make sure everything lines up correctly. We don't accept non-reference types, but it wouldn't be hard to add; I've prototyped some optimizations that allow exactly that. They weren't useful from an optimization perspective because we need to box the types for almost everything else anyway, but it wasn't particularly difficult to make the modification. - Charlie --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to jvm-languages@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
