[groovy-jsr] Re: The Groovy Language Specification

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[groovy-jsr] Re: The Groovy Language Specification

Jeremy Rayner
Hi John,
>>   I've been revisiting the Groovy specifications, trying to make
>> it into a readable, usable document.  One decision that seems
>> fairly critical is that of using full specification text, rather than
>> being a 'diff' of the original Java Language Specification.
>
> By critical you mean that a factored (diff-based) specification will fail?
> Or that a decision is needed now to avoid useless work?
<snip initial draft comments>

Thanks for your comments, I was putting my toe in the water, trying
to prevent doing too much work in the wrong direction.

>>   My quandary is that Groovy is trying to be as close to the Java platform
>> as possible, and the rigour of the JLS spec should be applied to the
>> Groovy platform too.  But in doing so I do not want to create a GLS
>> that we cannot publish due to copyright concerns.
>
> I'm sure we can get rigor enough (at least for 1.0) with a factored
> approach.
> I would be surprised to see any evidence to the contrary.

I've performed a real diff of my work and the JLS, and have fed
this back, along with your document (up till section 3.9) into
a new document at

http://groovy.codehaus.org/jsr/spec/Chapter03Lexical-Proposal.html

Hopefully this is closer to the final form of the GLS.
I'd be interested in your thoughts on this layout, and content.

>
> Regards,
>
> -- John
>
> P.S.  I'm almost done with a big wiki page on scoping.
> I hope you'll all insert comments and improvements.

Thanks for these, we will be discussing this and blackdrags
dynamic name resolution document on Thursday at the meetup in
Paris.
(Any comments on
http://docs.codehaus.org/display/GroovyJSR/dynamic+name+resolution
before the thursday meeting)?
--
Groovy JSR Co-Spec Lead
http://javanicus.com/blog2
Reply | Threaded
Open this post in threaded view
|

Re: [groovy-jsr] Re: The Groovy Language Specification

Guillaume Laforge
Administrator
On 21/11/05, Jeremy Rayner <[hidden email]> wrote:
> [...]
> I've performed a real diff of my work and the JLS, and have fed
> this back, along with your document (up till section 3.9) into
> a new document at
>
> http://groovy.codehaus.org/jsr/spec/Chapter03Lexical-Proposal.html
>
> Hopefully this is closer to the final form of the GLS.
> I'd be interested in your thoughts on this layout, and content.

Though I felt a full standalone GLS would have been better, I like
very much your approach with the "+", "-", and "!" icons to notify
about differences. The text is short and to the point, but shows how
we differ from Java.

I think this format is promising :-)

Thanks a lot for your work on the GLS, Jeremy.
Not an easy task ;-)

--
Guillaume Laforge
Groovy Project Manager
http://glaforge.free.fr/blog/groovy
Reply | Threaded
Open this post in threaded view
|

[groovy-jsr] Re: The Groovy Language Specification

Alan Green-2
Guillaume Laforge wrote:
> On 21/11/05, Jeremy Rayner <[hidden email]> wrote:
>>a new document at
>>
>>http://groovy.codehaus.org/jsr/spec/Chapter03Lexical-Proposal.html

> Though I felt a full standalone GLS would have been better, I like
> very much your approach with the "+", "-", and "!" icons to notify
> about differences. The text is short and to the point, but shows how
> we differ from Java.

I agree with Guillaume, if we could use the JLS as a basis for the GLS
text, that would be great, but this format works for me. It is entirely
reasonable to expect people reading the GLS to also have a copy of the
JLS open in front of them.

The convention of (+), (-) and (i) encourages brevity, which is a very
good thing in a specification. I'd find an (=) icon to mark unchanged
sections helpful.

It would be good to do Chapter01 next, and include in it a note on the
conventions for specifying diffs.

The only other option I can think of is to check-in machine-generated
diffs against the downloadable version of the JLS. GLS readers would
then have to download the JLS and merge the diffs to get the GLS.
However, I can think of several issues with this, including problems
with distribution.

> I think this format is promising :-)

Unless there's some other format that we can all agree is clearly
better, I think we should adopt this proposed format.

Alan.