Re: Re: static versus dynamic typing policy

This is a lengthy discussion and I'm a bit snowed under today to answer 
every nuance, but a few quick replies..

On 15 Feb 2005, at 17:18, Mike Spille wrote:
> At 03:30 AM 2/15/2005, you wrote:
> So let us speak plainly.
>
> In Classic Groovy, parenthesis are optional because some people don't 
> like parenthesis.  No MOP or bipartites or Scheme namespaces need 
> apply.
>
> In Classic Groovy, a.x can be a short cut for "getX()" or "setX()".  
> Additionally, inside of a class a field definition may have these 
> methods auto-generated for them.  Groovy provides convenient 
> property-style access because it's easier.  Note there is no such 
> thing as a "property" in Groovy - there is only property access.

I'm afraid the Classic Groovy MOP does indeed have properties. Sure 
properties are things which are read & written, but they do exist. See 
MetaProperty , MetaClass.getProperties(), getProperty(), setProperty(), 
getStaticProperty(), setStaticProperty() etc

>  A field inside of a class is a field, period, that may have 
> property-access bolted onto it.
>
> Both optional parenthesis and properties access were added to Groovy 
> _to make scripting easier_.  Again, we do not need to invoke MOP or 
> unified access or Scheme.  They're just ways to make scripting easier.

There's still a MOP underpinning it even if you don't wanna think about 
it that way.

> Now, you can use MOP and Scheme principles and a number of other 
> techniques to clean up the rules.  That is one approach - your 
> approach.  In essence you're describing rebuilding Groovy from the 
> ground up.

i.e. defining semantics which pretty much mirrors what we do in Groovy 
right?

> Another approach is to get back to basics and fundamentals.

I thought that's what we were - describing how the language works from 
the fundamentals.

> Everyone wants scripting to be easy.  How can that be done?  OK, 
> optional parens and "f()" style closure calls have problems in Classic 
> Groovy.  What can we do to fix those problems?  Is a complete redesign 
> of the rules necessary to address these?  Or can they be addressed 
> with a few simple rules and small changes?
>
> I think it's clear that many people are opting for the "simple 
> changes" approach.  Make parens mandatory and get rid of "f()" on 
> closures, and Groovy works - and is still recognizably Groovy.

Ignoring the use of closures which have clear optional parens rules

> The use cases for this is clear - many people want Groovy that's 
> simple to understand, simple for Java programmers, and simple to 
> integrate with Java code.  The use case for a full-blown Scheme MOP 
> approach has not been defined.  Who wants this?  Why do they want it?  
> What sort of scripts will they be writing that need this sort of 
> language design?

Classic Groovy has a MOP. You can slam Scheme all you like but the fact 
is from day one we've had a MOP.

> I'll ask this as a general question (not to John but to everyone): 
> what do you use Groovy for now?  How much Groovy code have you 
> written?  Will requiring parenthesis somehow compromise that code?

Yes - see pretty much every closure example in CVS / website.

> And let's continue in that vein: how will adopting John's proposal 
> improve your scripts?  What problems that you face today will be 
> addressed by the changes?  What value will it give you?

We're having an open discussion, I thought, on the JSR list over how we 
could describe the semantics of Groovy in a clear & concise way.

> As a final note, you also have to think in terms of what is 
> implementable.  I think everyone on this list knows that mandating 
> parenthesis and eliminating "f()" closure call syntax is pretty easy 
> to do.  We know it will work, and will fit the timeline Guillaume put 
> together.
>
> What of this proposal?  Can it be implemented at all?  If it can be 
> implemented, will Groovy and Java still be as easily mixed and 
> matched?  And if it can be implemented, how long will it take?

Its a bit early for that - we're still discussing ideas here...

> It's Feb 15th, and the ANTLR parser still has ambiguities.  There are 
> still basic constructs that are broken in that parser.  Above the 
> parser, the ANTLR->Groovy AST also still doesn't handle everything.

Actually it handles pretty much all of the Groovy AST already - its 
just the Antlr grammar has a few glitches that need fixing. FWIW all of 
the classic groovy test cases are parsing now with the new groovy Antlr 
parser apart from about 6-7 bugs...

> With these pieces still not working, this is another proposal that 
> adds more changes and is demonstrably much more difficult than the 
> obvious simple fixes.  John, this is your proposal so I assume you 
> know: how long will this proposal take to implement?

Just because the Antlr grammar today has a few bugs doesn't mean we 
should stop discussing things - I don't follow your reasoning here.

James
-------
http://radio.weblogs.com/0112098/