Re: [groovy-dev] groovy + maven

Re: [groovy-dev] removing features in Groovy 2

 Alex,

> >  foo[42]     // indexing op:     foo.getAt(42);
> >  foo [42]    // current:         foo.getAt(42);
> >              // __PROPOSED__:    foo([42]);
> 
> I wonder if
> 
>  foo[42, 43]
> 
> would then be the same as
> 
>  foo [42, 43]

  
  No.  

  If [ does not snuggle up to foo, then you're calling the foo function.
  Otherwise, you're doing whatever groovy 1 did (getAt, slice, whatever).

  Thus, under the proposal:     

          foo   42         // foo( 42 )     
  and:    foo  [42]        // foo( [42] )
  and:    foo  [42,43]     // foo( [42,43] )
  and:    foo  [x:"y"]     // foo( [x:"y"] )

  Unchanged by the proposal:

          foo[42]          // foo.getAt(42)
          foo[42,43]       // 2 element slice at index 42 and 43.

  Equivalent function calls under the proposal:

     foo  [42]             // foo( [42] )
     foo  [ 42]            // foo( [42] )
     foo  [42 ]            // foo( [42] )
     foo  [ 42 ]           // foo( [42] )

     foo  [42,43]          // foo( [42,43] )
     foo  [ 42,43]         // foo( [42,43] )
     foo  [42 ,43]         // foo( [42,43] )
     foo  [42, 43]         // foo( [42,43] )
     foo  [42,43 ]         // foo( [42,43] )
     foo  [ 42 ,43]        // foo( [42,43] )
     foo  [ 42, 43]        // foo( [42,43] )
     foo  [ 42,43 ]        // foo( [42,43] )
     foo  [ 42 ,43 ]       // foo( [42,43] )
     foo  [ 42, 43 ]       // foo( [42,43] )

     foo  [x:"y"]          // foo( [x:"y"] ) 
     foo  [ x:"y"]         // foo( [x:"y"] )
     foo  [x:"y" ]         // foo( [x:"y"] )
     foo  [ x:"y" ]        // foo( [x:"y"] )
     foo  [ x :"y" ]       // foo( [x:"y"] )
     foo  [ x: "y" ]       // foo( [x:"y"] )
     foo  [ x : "y" ]      // foo( [x:"y"] )

  The following non-surprising equivalences also hold, 
  as all the [ are snuggly with foo:

     foo[42]               // foo.getAt(42)
     foo[ 42]              // foo.getAt(42)
     foo[42 ]              // foo.getAt(42)
     foo[ 42 ]             // foo.getAt(42)

     foo[42, 43]           // 2 element slice
     foo[42,43]            // 2 element slice
     foo[ 42 , 43 ]        // 2 element slice

  What we've got with groovy currently is kind of a mess, 
  because you can usually elide parens, but if the 1st arg is  
  an array or hash, you either:

        (1)  Can do it, but you get an array lookup 
             exactly where you'd get a function call 
             with other inital arg types

        (2)  Hit an error when you discover that you can't 
             elide parens with a hash that has explicit square 
             braces, but can if the square braces are implicit.   
             Gak.

  The proposal removes all weirdness from groovy's 1st argtype rules
  when you're calling a function with elided parens, as whitespace 
  between foo and '[' always means the same thing: 
  "function with elided parens".

                        -Jon

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

Re: [groovy-dev] removing features in Groovy 2

On Thu, 2011-06-02 at 12:03 -0700, Jon Cox wrote:
[ . . . ]
>   If [ does not snuggle up to foo, then you're calling the foo function.
>   Otherwise, you're doing whatever groovy 1 did (getAt, slice, whatever).
[ . . . ]
>   What we've got with groovy currently is kind of a mess, 
>   because you can usually elide parens, but if the 1st arg is  
>   an array or hash, you either:
[ . . . ]

But please recognize that the proposal to have significant space between
a variable name and a [ is just as much of a mess for those people who
like to use space as insignificant whitespace.

There is no way out of the mess here arguing in this way, there are two
equally right (equally wrong) opinions and one is going to have to win
over the other at the expense of one group of people being outraged.
This is very much a little-endian vs big-endian argument, there is no
right answer, nor a wrong answer so there has to be an arbitrary
decision which one group will just have to bit the bullet and live with.
So let us not attempt to prolong this debate with attempts to prove one
view is right and the other not, let us move to a phase of asking which
of these equally right, equally wrong positions is least offensively
wrong.

Either that or take the opportunity of making a 1.x ->2.x breaking
change that means there can be a regular context insensitive grammar.
Why don't we think "out of the box":  why don't we argue about how to
introduce a different syntax for either sequence indexing, or sequence
literals, such that the problem simply goes away? 

--

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder <at> ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@...
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Re: [groovy-dev] Re: removing features in Groovy 2

On Sun, 2011-05-29 at 19:12 -0700, Dimitar Dimitrov wrote:

[ . . . ]

So if there is going to be 1.x -> 2.x upgrade pain anyway, let us
separate sequence indexing syntax from list literal syntax such that we
have a regular context insensitive grammar for Groovy such that the
"significant whitespace" vs "optional parentheses" problem is no longer
a problem.

Basically why do we have to stick with [ as both the introducer for
indexing and the introducer for list and map literals?  This position
seems far too "we must preserve backward compatibility at all costs" to
me.

Yes I know large tracts of computer users out there are pathologically
afraid of any trivial breaking change, in which case let them stick with
Groovy 1.x and miss out on all the benefits of Groovy 2.x.  After all
there are large number of people out there still on Java 1.3 and 1.4
because they are afraid of the changes in Java 1.5.  So fine, that is
their problem.  Even though Gosling hates them all.

--

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder <at> ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@...
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

[groovy-dev] GPars release

Last evening Václav released GPars 0.12.  There are some breaking
changes over 0.11 -- not least of which is various spelling changes to
some of the classes and methods.  Please can Groovy HEAD move from using
0.11 to 0.12 immediately and deal with the breaking changes?

Clearly the 1.8.x and 1.7.x maintenance branches should stay as they
are, but HEAD should move so that 1.9.x uses the shiny new stuff, that
is far nicer and faster and more functional and better.

If Groovy were using Git instead of Subversion, I'd just clone the
repository and try some experiments myself.  Oh, I have a git-svn clone
of the Subversion repository, maybe I will do this anyway.  Is the
Ant/Maven plugin build still the official build or have we upgraded to
Gradle as the main build?

(I may have a window of opportunity today to do this, but I don't want
to put in effort that is not constructive.)

Thanks.

--

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder <at> ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@...
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Re: [groovy-dev] removing features in Groovy 2

Am 03.06.2011 08:37, schrieb Russel Winder:
> [ ... ]
>
> why don't we argue about how to
> introduce a different syntax for either sequence indexing, or sequence
> literals, such that the problem simply goes away?

I am not sure building on the sequence alone will be helping very much. 
You have the same problem for a list with a single element as well as 
for the traditional getAt. Actually I am wondering if array (getAt) 
access shouldn't be different. And my path of thought sees, that the 
square bracket is used a lot, especially in C tradition, for the array, 
which worries me. But the other often used version is the round bracket. 
That would mean "array[x]" would become "array(x)" instead and thus look 
more like a method call. Of course something like "array(x)=y" does look 
a bit strange from Java perspective. And the only language I know that 
makes it this way are VisualBasic and Fortran - not exactly giving a 
good feeling about this.

bye blackdrag

--

-- 
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead
http://blackdragsview.blogspot.com/
For Groovy programming sources visit http://groovy.codehaus.org

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

Re: [groovy-dev] GPars release

Re: [groovy-dev] GPars release

Re: [groovy-dev] GPars release

On trunk:

gpars is now 0.12 (includes jsr166y extra166y  jars)
jansi is now 1.4 (not related  but was also in need of an update)

Let me know if you see any issues.

Paul.

On 3/06/2011 9:51 PM, Vaclav Pech wrote:
> Hi guys,
>
> one thing to take into account - gpars 0.12 depends on the recent jsr-166y artifacts, unlike 0.11, which
uses a pretty old version of fork-join. Groovy 1.8 thus needs to bundle the new jars.
>
> Cheers,
>
> Vaclav
>
>
> On Fri, Jun 3, 2011 at 1:21 PM, Guillaume Laforge <glaforge@...
<mailto:glaforge@...>> wrote:
>
>     Hi Russel,
>
>     On Fri, Jun 3, 2011 at 08:51, Russel Winder <russel@...
<mailto:russel@...>> wrote:
>
>         Last evening Václav released GPars 0.12.  There are some breaking
>         changes over 0.11 -- not least of which is various spelling changes to
>         some of the classes and methods.  Please can Groovy HEAD move from using
>         0.11 to 0.12 immediately and deal with the breaking changes?
>
>
>     You can go ahead and change the pom.xml and build.gradle with the new version (I guess it's already on Maven
Central by now?)
>
>         Clearly the 1.8.x and 1.7.x maintenance branches should stay as they
>         are, but HEAD should move so that 1.9.x uses the shiny new stuff, that
>         is far nicer and faster and more functional and better.
>
>
>     1.7.x doesn't bundle GPars, so nothing to change here.
>     But for 1.8 and 1.9 (Trunk), I would also update the version distributed.
>
>         If Groovy were using Git instead of Subversion, I'd just clone the
>         repository and try some experiments myself.  Oh, I have a git-svn clone
>         of the Subversion repository, maybe I will do this anyway.  Is the
>         Ant/Maven plugin build still the official build or have we upgraded to
>         Gradle as the main build?
>
>
>     Still Ant.
>     Ant will stay for the 1.8.x releases, but 1.9/Trunk will soon be Gradle only.
>
>         (I may have a window of opportunity today to do this, but I don't want
>         to put in effort that is not constructive.)
>
>
>     I guess it's just a matter of trying Groovy 1.8 and Trunk with 0.12 and see if some of the examples with GPars
just work?
>
>     Thanks for looking into this.
>
>     Guillaume
>
>         Thanks.
>
>         --
>         Russel.
>         =============================================================================
>         Dr Russel Winder      t: +44 20 7585 2200 <tel:%2B44%2020%207585%202200>   voip:
sip:russel.winder@... <mailto:sip%3Arussel.winder@...>
>         41 Buckmaster Road    m: +44 7770 465 077 <tel:%2B44%207770%20465%20077>   xmpp:
russel@... <mailto:russel@...>
>         London SW11 1EN, UK   w: www.russel.org.uk <http://www.russel.org.uk>  skype: russel_winder
>
>
>
>
>     --
>     Guillaume Laforge
>     Groovy Project Manager
>     Head of Groovy Development at SpringSource
>     http://www.springsource.com/g2one
>
>
>
>
> --
> E-mail: vaclav.pech@... <mailto:vaclav.pech@...>
> Blog: http://www.jroller.com/vaclav
> Linkedin page: http://www.linkedin.com/in/vaclavpech

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

Re: [groovy-dev] removing features in Groovy 2

On Fri, 2011-06-03 at 12:42 +0200, Jochen Theodorou wrote:
[ . . . ]
> I am not sure building on the sequence alone will be helping very much. 
> You have the same problem for a list with a single element as well as 
> for the traditional getAt. Actually I am wondering if array (getAt) 
> access shouldn't be different. And my path of thought sees, that the 
> square bracket is used a lot, especially in C tradition, for the array, 
> which worries me. But the other often used version is the round bracket. 
> That would mean "array[x]" would become "array(x)" instead and thus look 
> more like a method call. Of course something like "array(x)=y" does look 
> a bit strange from Java perspective. And the only language I know that 
> makes it this way are VisualBasic and Fortran - not exactly giving a 
> good feeling about this.

Quick response, I'll cogitate on this a bit more:

Scala uses function call syntax for indexing, presumably because a
function is a transform from one set to another, and a list is a
transform from index type to something else, and maps are transforms
from keys to values.  Or some such argument.

--

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder <at> ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@...
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder