Re: final Groovy JSR?
Hi Bill,
Thanks a lot for your explanations.
I haven't been able to answer earlier, I'm sorry.
Some comments inline.
On Sat, Mar 22, 2008 at 8:24 PM, Bill Shannon <bill.shannon@...> wrote:
> [...]
> You need a spec that's sufficient for someone else to implement
> Groovy support without reference to your code. I don't know that
> much about Groovy, but you might want to split the spec into a
> language/compiler portion and a runtime portion (assuming runtime
> support beyond what's in Java SE is needed).
What do you mean by language/compiler portion, and runtime portion exactly?
I just want to be sure I understood correctly.
For the language part, we need to explain the semantics of the
language, its grammar, etc.
For the runtime part, you mean things like the libraries? ie. a
closure class, a GString class, etc.
Is that what you meant?
> Do you want someone
> else to be able to implement a Groovy compiler that generates code
> that works with your runtime? And vice versa? And if the Groovy
> compiler or interpreter needs to be available to applications at
> runtime, how does that work and what level of mix-and-match do you
> want to support?
Okay, it's up to us to decide the level of integration the spec
mandates or not for a language to be considered a valid Groovy
implementation. Furthermore the TCK will help ensure this.
> Very precise syntax specifications for a language
> are critical, but you also need to specify the semantics as precisely
> as possible. This kind of specification is different than the
> typical user documentation people produce; rather than describing how
> it *does* work, you have to describe how it *must* work, in sufficient
> detail that someone else implementing your specification will end up
> with behavior the same as yours, without reference to your code or
> (ideally) your implementation. In cases where the specification isn't
> sufficiently complete, we often rely on the behavior of the reference
> implementation to determine what is intended, although independent
> implementors of the specification don't really like it when we do that.
Ok, that makes perfect sense.
> You also need a test suite that tests as much of this as you think
> is necessary to ensure application portability and interoperability.
Back on the level of integration mentioned above, and on this
portability / interoperability aspect, Groovy mandates a seamless
integration with Java. But does it mean we'd also mandate a perfect
interoperability with other Groovy implementations?
The fact Groovy is a dynamic language, with a MOP, a double dispatch
system, means that we rely on some proprietary APIs for generating
bytecode, for handling method calls, doing some clever call site
caching techniques, etc.
If we'd choose to totally specify these aspects, it'd mean that we
couldn't extend Groovy or improve its performance by introducing other
improvement techniques or that we could evolve the underlying code
generation classes.
Is it okay if we dont specify these to avoid restraining further
development, perhaps at the cost of making two compiled Groovy classes
incompatible if compiled with two different compilers?
Obviously, it's a problem Java doesn't have since it's a statically
compiled language.
> We all recognize that there is no such thing as a "complete" test suite,
> and a high quality test suite is a lot of work. You get to decide how
> complete the test suite needs to be, and the JCP EC gets to decide
> whether it's "complete enough" when they approve your JSR. The more
> likely it is that there will be independent implementations, the more
> important it is to have a high quality test suite. If you expect
> everyone to use your implementation, you can probably get by with less.
Ok.
> In addition to the actual tests in the test suite, you get to decide
> what the rules are for running your test suite. Do people have to
> run the binaries in your test suite? Are they allowed to recompile
> your test suite with any arbitrary compiler? Can they modify the tests
> in your test suite? Are they allowed to extend the Groovy language or
> Groovy APIs to add their own value-added, non-standard features? What
> exactly is considered "passing" your test suite? If someone questions
> whether tests in your test suite are correct, how do they interact with
> you to get a fix?
And where these rules should be explained? In the TCK itself?
> We have a set of rules we use for all Sun TCKs, and we can give you a
> template you can start with for these compatibility test suite rules.
I'd be interested in seeing these rules.
> In addition to "run rules" and process issues, our TCK rules also
> describe things that we want to be true of any implementation, but for
> which there's no easy way to test. Especially important to us is the
> issue of language extensions, but you get to decide what rules you want
> to enforce for your language.
Ok.
> Of course, we also have an (open source) test suite harness, but you're
> free to use whatever harness you want. The major advantage of using
> our harness is that it makes it easier to integrate your TCK with a
> Java platform TCK, if your JSR were to be included as part of a Java
> platform specification. That may not be an issue for you.
Have you got something in mind here? 
(ie. integrating Groovy in the JDK)
I haven't looked yet at the OpenJDK project.
Is the test harness available in the OpenJDK project?
Is there any place explaining how this test harness is working?
> In terms of process, there's lots of information available on jcp.org.
> You should of course produce a Public Draft specification, collect
> comments from the public, incorporate those comments as appropriate,
> produce a Proposed Final Draft specification, and eventually submit
> your JSR for a Final Approval Ballot.
Ok.
> I hope that helps. Please feel free to ask if you have any more questions.
I'm sure I'll have many more questions along the way!
> I'm looking forward to a final Groovy specification! We're very excited
> about supporting Groovy in GlassFish!
Thanks a lot for those great explanations and these kind words.
--
--
Guillaume Laforge
Groovy Project Manager
G2One, Inc. Vice-President Technology
http://www.g2one.com
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
))
Thanks again Bill for your explanations, the links, and your fast replies!
This is very much appreciated.
RSS Feed