Quantcast

[grumpy mode] what to do on assignment?

classic Classic list List threaded Threaded
35 messages Options
1234
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[grumpy mode] what to do on assignment?

Jochen Theodorou
Hi all,

as many may know we started with the project Grumpy, an annotation
@StaticTypes, which will do static type checking on Groovy code. Of
course that means not all groovy programs will compile in this mode. The
semantics of the groovy program stay the same though.

Anyway, this post is not really to discuss grumpy in its all, it is more
about needing a decision on how we should let it behave in a certain
situation.

In Java if you have

long x = 1;
int y = x;

then the compiler will complain because the long value may not fit in
the int and you will need to add a cast to force this to pass.

In standard Groovy the same program will pass, in fact it will compile
the program as this:

long x = 1;
int y = (int) x;

that means the cast required in Java is there already, even though it is
an implicit one. And we support things like

int[] x = [1,2,3]
Dimension d = [100,200]

for example, which is far from what Java allows you to do. Now the
question is how grumpy should handle this. Should it go the Java path,
disallowing a large part of groovy programs and not leaving a nice way
to create arrays... or should we stay in the groovy path, meaning there
are almost no type checks on assignment?

bye blackdrag

--
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [grumpy mode] what to do on assignment?

Dierk König
I'd say that Grumpy should be grumpy enough to require an explicit cast.
(this should be a rather easy codenarc-style rule ;-)

A second question is whether to require an explicit call to castToType.
I'm not yet decided on this one.
The code will not look nice anymore but not requiring it would defeat the purpose of Grumpy.

cheers
Dierk

P.S. great to see this effort going forward!


Am 07.10.2011 um 22:55 schrieb Jochen Theodorou:

> Hi all,
>
> as many may know we started with the project Grumpy, an annotation @StaticTypes, which will do static type checking on Groovy code. Of course that means not all groovy programs will compile in this mode. The semantics of the groovy program stay the same though.
>
> Anyway, this post is not really to discuss grumpy in its all, it is more about needing a decision on how we should let it behave in a certain situation.
>
> In Java if you have
>
> long x = 1;
> int y = x;
>
> then the compiler will complain because the long value may not fit in the int and you will need to add a cast to force this to pass.
>
> In standard Groovy the same program will pass, in fact it will compile the program as this:
>
> long x = 1;
> int y = (int) x;
>
> that means the cast required in Java is there already, even though it is an implicit one. And we support things like
>
> int[] x = [1,2,3]
> Dimension d = [100,200]
>
> for example, which is far from what Java allows you to do. Now the question is how grumpy should handle this. Should it go the Java path, disallowing a large part of groovy programs and not leaving a nice way to create arrays... or should we stay in the groovy path, meaning there are almost no type checks on assignment?
>
> bye blackdrag
>
> --
> Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
> blog: http://blackdragsview.blogspot.com/
> german groovy discussion newsgroup: de.comp.lang.misc
> For Groovy programming sources visit http://groovy-lang.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>   http://xircles.codehaus.org/manage_email
>
>


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [grumpy mode] what to do on assignment?

Cédric Champeau
Le 08/10/2011 00:39, Dierk König a écrit :
> I'd say that Grumpy should be grumpy enough to require an explicit cast.
> (this should be a rather easy codenarc-style rule ;-)
>
> A second question is whether to require an explicit call to castToType.
> I'm not yet decided on this one.
I'm not sure I understand what you mean. Can you give an example ?

BTW, there's now a Groovy Enhancement Proposal page for the static type
checking mode. Here is the link :

http://docs.codehaus.org/display/GroovyJSR/GEP+8+-+Static+type+checking

I will update the page based on our different discussions.

Cédric


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [grumpy mode] what to do on assignment?

Peter Niederwieser
In reply to this post by Jochen Theodorou
"grumpy" should only allow what it can prove to be safe. Your three examples are safe coercions, and if "grumpy" can prove them safe, it should allow them. It's more a question of how smart you can and want to make "grumpy", and what other goals you have for it (like leveraging it for a static compilation mode).

Cheers,
Peter
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [grumpy mode] what to do on assignment?

Guillaume Laforge-4
In reply to this post by Dierk König
Perhaps you can elaborate on your expectations for Grumpy?
What would you like it to tell you for some cases you could think of?
Where do you think it should be pretty strict, where it should be more relaxed, etc.

Guillaume

On Sat, Oct 8, 2011 at 00:39, Dierk König <[hidden email]> wrote:
I'd say that Grumpy should be grumpy enough to require an explicit cast.
(this should be a rather easy codenarc-style rule ;-)

A second question is whether to require an explicit call to castToType.
I'm not yet decided on this one.
The code will not look nice anymore but not requiring it would defeat the purpose of Grumpy.

cheers
Dierk

P.S. great to see this effort going forward!


Am 07.10.2011 um 22:55 schrieb Jochen Theodorou:

> Hi all,
>
> as many may know we started with the project Grumpy, an annotation @StaticTypes, which will do static type checking on Groovy code. Of course that means not all groovy programs will compile in this mode. The semantics of the groovy program stay the same though.
>
> Anyway, this post is not really to discuss grumpy in its all, it is more about needing a decision on how we should let it behave in a certain situation.
>
> In Java if you have
>
> long x = 1;
> int y = x;
>
> then the compiler will complain because the long value may not fit in the int and you will need to add a cast to force this to pass.
>
> In standard Groovy the same program will pass, in fact it will compile the program as this:
>
> long x = 1;
> int y = (int) x;
>
> that means the cast required in Java is there already, even though it is an implicit one. And we support things like
>
> int[] x = [1,2,3]
> Dimension d = [100,200]
>
> for example, which is far from what Java allows you to do. Now the question is how grumpy should handle this. Should it go the Java path, disallowing a large part of groovy programs and not leaving a nice way to create arrays... or should we stay in the groovy path, meaning there are almost no type checks on assignment?
>
> bye blackdrag
>
> --
> Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
> blog: http://blackdragsview.blogspot.com/
> german groovy discussion newsgroup: de.comp.lang.misc
> For Groovy programming sources visit http://groovy-lang.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>   http://xircles.codehaus.org/manage_email
>
>


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

   http://xircles.codehaus.org/manage_email





--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [grumpy mode] what to do on assignment?

Guillaume Laforge-4
In reply to this post by Peter Niederwieser
Peter, perhaps you could tell us a few words of what you'd like this "grumpy" static type checking mode to do?
Do you have some particular ideas of things that you think Grumpy should be complaining about?
As well as other aspects it should be cool with?

Guillaume

On Sat, Oct 8, 2011 at 18:02, Peter Niederwieser <[hidden email]> wrote:
"grumpy" should only allow what it can prove to be safe. Your three examples
are safe coercions, and if "grumpy" can prove them safe, it should allow
them. It's more a question of how smart you can and want to make "grumpy",
and what other goals you have for it (like leveraging it for a static
compilation mode).

Cheers,
Peter

--
View this message in context: http://groovy.329449.n5.nabble.com/grumpy-mode-what-to-do-on-assignment-tp4881375p4883040.html
Sent from the groovy - user mailing list archive at Nabble.com.

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

   http://xircles.codehaus.org/manage_email





--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [grumpy mode] what to do on assignment?

Wilson MacGyver
In reply to this post by Jochen Theodorou
What if in static mode, no coercion takes place much like Haskell?

The traditional argument for static are type and speed. This is an optional mode, so if someone care enough to want to turn this on, seems no coercion is worth exploring as a path  

On Oct 7, 2011, at 4:55 PM, Jochen Theodorou <[hidden email]> wrote:

> Hi all,
>
> as many may know we started with the project Grumpy, an annotation @StaticTypes, which will do static type checking on Groovy code. Of course that means not all groovy programs will compile in this mode. The semantics of the groovy program stay the same though.
>
> Anyway, this post is not really to discuss grumpy in its all, it is more about needing a decision on how we should let it behave in a certain situation.
>
> In Java if you have
>
> long x = 1;
> int y = x;
>
> then the compiler will complain because the long value may not fit in the int and you will need to add a cast to force this to pass.
>
> In standard Groovy the same program will pass, in fact it will compile the program as this:
>
> long x = 1;
> int y = (int) x;
>
> that means the cast required in Java is there already, even though it is an implicit one. And we support things like
>
> int[] x = [1,2,3]
> Dimension d = [100,200]
>
> for example, which is far from what Java allows you to do. Now the question is how grumpy should handle this. Should it go the Java path, disallowing a large part of groovy programs and not leaving a nice way to create arrays... or should we stay in the groovy path, meaning there are almost no type checks on assignment?
>
> bye blackdrag
>
> --
> Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
> blog: http://blackdragsview.blogspot.com/
> german groovy discussion newsgroup: de.comp.lang.misc
> For Groovy programming sources visit http://groovy-lang.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>   http://xircles.codehaus.org/manage_email
>
>

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [grumpy mode] what to do on assignment?

Jochen Theodorou
Am 08.10.2011 19:26, schrieb Wilson MacGyver:
> What if in static mode, no coercion takes place much like Haskell?

This is not about a static compilation, this is only about a static
compile time checking. If you mean with coercion what "our" as-operator
does, then there is no coercion. But the standard Groovy cast contains
transformations of values into other types, like for example widening -
like Java, but of course also much more. The result would thus be, that
quite many Groovy programs would be rejected by grumpy, even though they
would work.

bye blackdrag

--
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [grumpy mode] what to do on assignment?

Wilson MacGyver
On Sat, Oct 8, 2011 at 1:33 PM, Jochen Theodorou <[hidden email]> wrote:

> Am 08.10.2011 19:26, schrieb Wilson MacGyver:
>>
>> What if in static mode, no coercion takes place much like Haskell?
>
> This is not about a static compilation, this is only about a static compile
> time checking. If you mean with coercion what "our" as-operator does, then
> there is no coercion. But the standard Groovy cast contains transformations
> of values into other types, like for example widening - like Java, but of
> course also much more. The result would thus be, that quite many Groovy
> programs would be rejected by grumpy, even though they would work.

right, I understand your original point. I assumed grumpy will reject
a bunch of valid
regular groovy code. So to me the question is how much to reject.

Unless you are saying grumpy mode aims for 100% compatibility with
regular groovy,
and this is purely a performance play?


--
Omnem crede diem tibi diluxisse supremum.

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [grumpy mode] what to do on assignment?

Jochen Theodorou
Am 08.10.2011 20:24, schrieb Wilson MacGyver:
[...]
> Unless you are saying grumpy mode aims for 100% compatibility with
> regular groovy, and this is purely a performance play?

100% compatibility is impossible, since the checks are static and Groovy
is a dynamic language. It will always reject programs that are perfectly
find in Groovy. The question is more to waht extend this should be done.
Performance doesn't matter here at all for now. On the other hand, if
you compare "Dimension d = [100,200]" and "Dimension d = new
Dimension(100,200)", then there is no real performance hit in this - at
least none that has to be there. Actually the same for "long x=1; int y=x"

So even if we statically compile this, performance would be no reason,
if then the user would do what the compiler does for him. Performance
becomes a reason, if that would cause the suer to change the code in a
way that does not require to bypass the compiler... for example making x
an int. But have these code transformation cases really more weight than
the ability to write less code in all?

bye blackdrag

--
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org


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

    http://xircles.codehaus.org/manage_email


1234
Loading...