headers
John Rose | 1 Mar 2005 04:18
Picon
Gravatar

Re: Support the math power operator **

On Feb 28, 2005, at 2:37, Alan Green wrote:
> So, what kinds of things need to change before 1.0 is released?

1. Reserve ("for future use") a largish set of operator spellings, a la 
Borneo.
It will be a set of regular expressions.  I can propose such a set.
The actual 2.0 set need not use the whole reserved space.

2. Reserve the dollar '$' character for future use (for name mangling 
in VM-level names).

3. (Optional.)  Specify a mangling for unicode strings (including 
operator spellings)
that (a) uniquely encodes all unicode strings into valid VM-level 
method names,
and (b) maps valid dollar-free Java method names to themselves.  Use 
this mangling
even in 1.0 for representing operator methods at the VM level.

4. (Optional.)  Specify direct rules for operator overloading that use 
the operator spellings
themselves instead of English words and phrases, in Groovy source code:
   - def leftShift(int y) {  this.multiply(1<<y)  }
   + def '<<'(int y) {  this.'*'(1<<y)  }
   or (targeted exclusively to operators, and less flexible and general 
IMO)
   + def op<<(int y) {  this.op*(1<<y)  }

At the VM level, a name like '<<' or '*' would be spelled something 
like '$3C$3C' or '$2A'.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alan Green | 1 Mar 2005 11:56
Picon

The Java Compatibility Kit


As I've been looking into the Groovy TCK recently, it struck me that it 
may be profitable to compare it with the Java Compatibility Kit (JCK), 
the test suite that Sun use to certify JRE's and compilers as Java 
compliant.

License and Availability
------------------------

Recently, Sun released the Java Compatibility Kit (JCK) "under read-only 
terms for evaluation and understanding by the larger Java development 
community." Essentially the license allows one to read the source code, 
but not compile it or use to build another product. Public commentary 
("feedback") is allowed, as is use of "ideas, concepts, know-how or 
techniques related to the Licensed Technology that are retained in the 
unaided memories of You". But I am not a lawyer.

The JCK can be downloaded here: https://jck.dev.java.net/

Despite the restrictive license, it is proper to thank Sun for opening 
this important part of the Java story to public scrutiny.

Running The Tests
-----------------

According to the included manual, tests are run via a graphical 
front-end. Tests may be run on the local machine, or a remote one 
through the use of a remote agent. A fresh JVM is started for each 
test's compile and run.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jochen Theodorou | 3 Mar 2005 12:49
Picon
Favicon

Re: RE: [groovy-user] Groovy beta 10 released! (+JSR Early Access)

Duke Tantiprasut schrieb:

> Keep up the good work guys. 
> 
> Do you have any links / more details on what the JSR Parser is?

http://groovy.codehaus.org/Migration+From+Classic+to+JSR+syntax

but keep in mind that this is work in progress.

bye blackdrag
Permalink | Reply | 0 comments |
headers
jastrachan | 4 Mar 2005 08:26
Picon

brace placement - a possible solution

The topic of { brace placement has come up recently on the lists so I 
thought I'd briefly outline the issues involved and propose a solution.

Use case
=======
Many developers wish to use arbitrary brace placement, aligning braces 
on newlines like you can do in Java and C/C++

Background
=========
Before we start, a little background. So far we've had a rule, rather 
like Ruby, JavaScript and most other scripting languages that says if a 
statement is valid when a newline is reached, the statement is 
considered to be terminated. i.e. its like the compiler added a ; at 
the end of the line for you.

e.g.

x = y + 1 	// implicit ; goes here
z = y +
5		// implicit ; goes here as the previous line wasn't complete

In general this works well and is a natural rule when people use shells 
and scripting languages.

However in Groovy we use { a fair bit, its a very magical token and the 
mixture of newlines and { can lead to ambiguities - particularly with 
closure passing syntax on method invocations.

Up to now we've tried to encourage people to use { on the same line its
(Continue reading)

Permalink | Reply | 4 comments |
headers
John Rose | 4 Mar 2005 09:06
Picon
Gravatar

Re: brace placement - a possible solution

The grammar changes are probably simple:

         LPAREN argList RPAREN
    -    ( appendedBlock )?     // maybe append a closure
    +    ( nls appendedBlock )?     // maybe append a closure

The lookahead for an appended block becomes NLS? LCURLY, which is LL(2).

As a consequence of reaching across the newline, there could be a few 
errors where blocks are unexpectedly appended.
But I agree that, with the restrictions on free-floating left-braces, 
this won't be so common as to ruin the language.

The occasional accidentally-appended block will be a pitfall, though.
If there's enough static typing, it will be caught at compile time, but 
the worst case is run-time errors.
Personally, I'd feel a little safer if some lint-like mode would warn 
me if I put a NL before a left-brace, but that's just me.

So, I like it on balance.

There's one small wrinkle in this proposal I want to call out 
explicitly.
Some of use have spoken of the possibility of appending multiple blocks 
with keywords:
	foo { bar } lock: {baz } unlock: {bat}

This would be more or less equivalent to:
	foo( { bar }, lock: {baz }, unlock: {bat} )
(Continue reading)

Permalink | Reply | 2 comments |
headers
jastrachan | 4 Mar 2005 09:17
Picon

Re: brace placement - a possible solution

Agreed with all of that.

Just a thought on the named parameter passing...

On 4 Mar 2005, at 08:06, John Rose wrote:
> The grammar changes are probably simple:
>
>         LPAREN argList RPAREN
>    -    ( appendedBlock )?     // maybe append a closure
>    +    ( nls appendedBlock )?     // maybe append a closure
>
> The lookahead for an appended block becomes NLS? LCURLY, which is 
> LL(2).
>
> As a consequence of reaching across the newline, there could be a few 
> errors where blocks are unexpectedly appended.
> But I agree that, with the restrictions on free-floating left-braces, 
> this won't be so common as to ruin the language.
>
> The occasional accidentally-appended block will be a pitfall, though.
> If there's enough static typing, it will be caught at compile time, 
> but the worst case is run-time errors.
> Personally, I'd feel a little safer if some lint-like mode would warn 
> me if I put a NL before a left-brace, but that's just me.
>
> So, I like it on balance.
>
> There's one small wrinkle in this proposal I want to call out 
> explicitly.
> Some of use have spoken of the possibility of appending multiple
(Continue reading)

Permalink | Reply | 0 comments |
headers
Guillaume Laforge | 4 Mar 2005 09:52
Picon
Gravatar

Re: brace placement - a possible solution

On Fri, 4 Mar 2005 07:26:06 +0000, jastrachan@...
<jastrachan@...> wrote:
> The topic of { brace placement has come up recently on the lists so I
> thought I'd briefly outline the issues involved and propose a solution.
> [snip]

Brilliant! I just love this solution! Let's go for it!
The neverending discussions on brace placement can be over thanks to
this clear and simple solution!

--

-- 
Guillaume Laforge
http://glaforge.free.fr/weblog
Permalink | Reply | 0 comments |
headers
Guillaume Laforge | 4 Mar 2005 10:42
Picon
Gravatar

Closure syntax

Hello all,

There are different kinds of closures:
- parameter-less closures
- closures with non-typed parameters
- closures with typed parameters
- closures with parameters with default values

So far, we're using | as the parameter/body separator token.
Like in:

{ println it }
{ s | println s }
{ String s | println s }
{ String s, t | println "$s: $t" }

For those cases, this is fine. But as soon as we use default values,
we're hitting a problem:

{ int i = 1 | 2 | 3 }
{ int i = 1, j = 1 | 2, k = 3 | func() | otherFunc() } 
// func() and otherFunc() returning ints as well
// currently, to avoid this ambiguity, 
// the parser requires parens around the parameters:
// like in: { ( int i = 1, j = 1 | 2, k = 3 | func() ) | otherFunc() } 

It's neither easy to read for the developer nor for the parser.
Adding a pipe at the beginning of the closure doesn't seem to solve
the problem either.
And the () around parameters with values isn't very nice to the eye: { ()| }
(Continue reading)

Permalink | Reply | 8 comments |
headers
Jeremy Rayner | 4 Mar 2005 11:10
Picon
Gravatar

Re: brace placement - a possible solution

> Personally, I'd feel a little safer if some lint-like mode would warn
> me if I put a NL before a left-brace, but that's just me.
I added the 'nlsWarn' production to the grammar for just this sort of thing,
it does exactly the same kind of job, but it is a grammar visible difference
for acceptable nls, and the kind of nls that you'd rather didn't happen, but
the world wouldn't stop turning if they did.
This provides a placeholder for us to put lint-style observers to watch.

e.g. http://groovy.codehaus.org/jsr/spec/grammar/#tryBlock

jez.
--

-- 
http://javanicus.com/blog2
Permalink | Reply | 0 comments |
headers
Jochen Theodorou | 4 Mar 2005 12:02
Picon
Favicon

Re: Closure syntax

Guillaume Laforge schrieb:
> Hello all,
> 
> There are different kinds of closures:
> - parameter-less closures
> - closures with non-typed parameters
> - closures with typed parameters
> - closures with parameters with default values
> 
> So far, we're using | as the parameter/body separator token.
> Like in:
> 
> { println it }
> { s | println s }
> { String s | println s }
> { String s, t | println "$s: $t" }
> 
> For those cases, this is fine. But as soon as we use default values,
> we're hitting a problem:
> 
> { int i = 1 | 2 | 3 }
> { int i = 1, j = 1 | 2, k = 3 | func() | otherFunc() } 
> // func() and otherFunc() returning ints as well
> // currently, to avoid this ambiguity, 
> // the parser requires parens around the parameters:
> // like in: { ( int i = 1, j = 1 | 2, k = 3 | func() ) | otherFunc() } 
> 
> It's neither easy to read for the developer nor for the parser.

yes, I saw this in the posting with Chris...
(Continue reading)

Permalink | Reply | 4 comments |

Gmane