Quantcast

Static mode

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

Static mode

Alex Tkachman

I was so happy to learn about static mode for groovy from blog post of Hamlet and not from discussion in this list. After several years convincing the world that it is great idea and having zero help from groovy core team. Thank you very much guys. For friendship and willingness of collaborate.

Best regards
Alex

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

Re: Static mode

Jochen Theodorou
Am 02.08.2011 09:53, schrieb Alex Tkachman:
> I was so happy to learn about static mode for groovy from blog post of
> Hamlet and not from discussion in this list. After several years
> convincing the world that it is great idea and having zero help from
> groovy core team. Thank you very much guys. For friendship and
> willingness of collaborate.

We wanted to go official after Guillaume's holiday by starting the
discussions here then. And after having a more clear picture of what
exactly we want to do.

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


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

Re: Static mode

HamletDRC2
I had forgotten Guillaume's request to stay quiet until after the holidays. I'm sorry I released this information too soon.

----- Original Message -----

> Am 02.08.2011 09:53, schrieb Alex Tkachman:
> > I was so happy to learn about static mode for groovy from blog post
> > of
> > Hamlet and not from discussion in this list. After several years
> > convincing the world that it is great idea and having zero help
> > from
> > groovy core team. Thank you very much guys. For friendship and
> > willingness of collaborate.
>
> We wanted to go official after Guillaume's holiday by starting the
> discussions here then. And after having a more clear picture of what
> exactly we want to do.
>
> 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
>
>
>

---------------------------------------------------------------------
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: Static mode

Graeme Rocher-4
Yeah I gotta say it was really unwise to post that without a formal
discussion on the mailing list or anything and with Guillaume being on
holiday.

We are still some ways to having a clear picture of what to do.

Cheers

On Tue, Aug 2, 2011 at 12:09 PM, Hamlet DArcy <[hidden email]> wrote:

> I had forgotten Guillaume's request to stay quiet until after the holidays. I'm sorry I released this information too soon.
>
> ----- Original Message -----
>> Am 02.08.2011 09:53, schrieb Alex Tkachman:
>> > I was so happy to learn about static mode for groovy from blog post
>> > of
>> > Hamlet and not from discussion in this list. After several years
>> > convincing the world that it is great idea and having zero help
>> > from
>> > groovy core team. Thank you very much guys. For friendship and
>> > willingness of collaborate.
>>
>> We wanted to go official after Guillaume's holiday by starting the
>> discussions here then. And after having a more clear picture of what
>> exactly we want to do.
>>
>> 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
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>



--
Graeme Rocher
Grails Project Lead
SpringSource - A Division of VMware
http://www.springsource.com

---------------------------------------------------------------------
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: Static mode

Jochen Theodorou
In reply to this post by HamletDRC2
Am 02.08.2011 12:09, schrieb Hamlet DArcy:
> I had forgotten Guillaume's request to stay quiet until after the
> holidays. I'm sorry I released this information too soon.

I guess there's no use crying over spilt milk. Instead I want to use the
opportunity then to start the discussion. Any thoughts?

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


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

Re: Static mode

Jochen Theodorou
Am 02.08.2011 13:12, schrieb Jochen Theodorou:
> Am 02.08.2011 12:09, schrieb Hamlet DArcy:
>> I had forgotten Guillaume's request to stay quiet until after the
>> holidays. I'm sorry I released this information too soon.
>
> I guess there's no use crying over spilt milk. Instead I want to use the
> opportunity then to start the discussion. Any thoughts?

maybe I start...

Grumpy (project name, not actual name) will type check a Groovy program.
Not all Groovy programs will pass this, so Grumpy will make a real
subset of Groovy. Some things will most probably never compile. Part of
this is the spread operator. Another example would be the regexp
matching, were a Closure can have the number of matching groups as
parameters. I am intending to make an annotation used by Grumpy that can
express types more freely as strings.. for exmaple:

@StaticTyped("TT1(Ljava/lang/Object;Z)","TT1(Ljava/lang/Object)")
Object call(Object... args){...}

showing that even though the Java signature is to take any amount of
parameters and return something of type Object, that we instead define
this method to take an Object as first argument, a boolean as second
optional argument and return the generic type T1. This type information
would overwrite whatever is defined in the real signature... it simply
has to be compatible in the Groovy sense. This way Map#each can be
expressed. This is just a first step for our GDK, not really for all day
use and probably later replaced by something better. Besides this
variation system of signatures, I intend to be as close as possible to Java.

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


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

Re: Static mode

Graeme Rocher-4
Yes may I suggest "Grumpy" remain a codename and any actual code not
refer to it. It may be good as a humorous code but has no place in
Groovy itself.

I suggest the annotation be called @TypeSafe

On Tue, Aug 2, 2011 at 1:51 PM, Jochen Theodorou <[hidden email]> wrote:

> Am 02.08.2011 13:12, schrieb Jochen Theodorou:
>>
>> Am 02.08.2011 12:09, schrieb Hamlet DArcy:
>>>
>>> I had forgotten Guillaume's request to stay quiet until after the
>>> holidays. I'm sorry I released this information too soon.
>>
>> I guess there's no use crying over spilt milk. Instead I want to use the
>> opportunity then to start the discussion. Any thoughts?
>
> maybe I start...
>
> Grumpy (project name, not actual name) will type check a Groovy program. Not
> all Groovy programs will pass this, so Grumpy will make a real subset of
> Groovy. Some things will most probably never compile. Part of this is the
> spread operator. Another example would be the regexp matching, were a
> Closure can have the number of matching groups as parameters. I am intending
> to make an annotation used by Grumpy that can express types more freely as
> strings.. for exmaple:
>
> @StaticTyped("TT1(Ljava/lang/Object;Z)","TT1(Ljava/lang/Object)")
> Object call(Object... args){...}
>
> showing that even though the Java signature is to take any amount of
> parameters and return something of type Object, that we instead define this
> method to take an Object as first argument, a boolean as second optional
> argument and return the generic type T1. This type information would
> overwrite whatever is defined in the real signature... it simply has to be
> compatible in the Groovy sense. This way Map#each can be expressed. This is
> just a first step for our GDK, not really for all day use and probably later
> replaced by something better. Besides this variation system of signatures, I
> intend to be as close as possible to Java.
>
> 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
>
>
>



--
Graeme Rocher
Grails Project Lead
SpringSource - A Division of VMware
http://www.springsource.com

---------------------------------------------------------------------
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: Static mode

Daniel Henrique Alves Lima
In reply to this post by Jochen Theodorou
        Hi.

        Sorry for bothering you all. I am not a Groovy developer. I'm
just curious about how Groovy static will look like. Is it Groovy++--?
        Sometimes I just miss a @JavaNative or @Java annotation, but I
think this can't be done. Something like:


/* MyClass.groovy */


def x = 12
def y = {a ->
   println a
}


def method() {
   y('test')
}

@Java
public int doStuff(int a, int b) {
   /* No need of being Groovy here. I am a "pure" Java method. I will
use Java syntax and I will be statically compiled. */
   /* For performance purpose only. The idea of Groovy + @Java methods
is similar to Java + JNI 'native' methods, but without an external
method definition. */

   return a + b;
}




2011/8/2, Jochen Theodorou <[hidden email]>:

> Am 02.08.2011 12:09, schrieb Hamlet DArcy:
>> I had forgotten Guillaume's request to stay quiet until after the
>> holidays. I'm sorry I released this information too soon.
>
> I guess there's no use crying over spilt milk. Instead I want to use the
> opportunity then to start the discussion. Any thoughts?
>
> 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
>
>
>

---------------------------------------------------------------------
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: Static mode

Jochen Theodorou
Am 02.08.2011 14:04, schrieb Daniel Henrique Alves Lima:
>          Hi.
>
>          Sorry for bothering you all. I am not a Groovy developer. I'm
> just curious about how Groovy static will look like. Is it Groovy++--?
>          Sometimes I just miss a @JavaNative or @Java annotation, but I
> think this can't be done. Something like:

A first step is to do the type checker grumpy. And that is all Grumpy
will do for now. We may extend it to write out more native code later,
but for now we want to concentrate on that part.

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


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

Re: Static mode

Alex Tkachman
In reply to this post by HamletDRC2

As i said I really appreciate being left out of the loop after all my contributions to groovy core and to vision of static compilation.

Best regards
Alex

On Aug 2, 2011 12:09 PM, "Hamlet DArcy" <[hidden email]> wrote:
> I had forgotten Guillaume's request to stay quiet until after the holidays. I'm sorry I released this information too soon.
>
> ----- Original Message -----
>> Am 02.08.2011 09:53, schrieb Alex Tkachman:
>> > I was so happy to learn about static mode for groovy from blog post
>> > of
>> > Hamlet and not from discussion in this list. After several years
>> > convincing the world that it is great idea and having zero help
>> > from
>> > groovy core team. Thank you very much guys. For friendship and
>> > willingness of collaborate.
>>
>> We wanted to go official after Guillaume's holiday by starting the
>> discussions here then. And after having a more clear picture of what
>> exactly we want to do.
>>
>> 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
>>
>>
>>
>
> ---------------------------------------------------------------------
> 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: Static mode

Remi Forax
On 08/02/2011 05:23 PM, Alex Tkachman wrote:

As i said I really appreciate being left out of the loop after all my contributions to groovy core and to vision of static compilation.

Best regards
Alex


I've just read the post of Hamlet,
I don't think anyone is out of the loop, the news is that a team will work on grumpy
(or a more static groovy) and I don't see anything about an already decided semantics
or something like that.
If groovy and groovy++ can be merge nicely in grumpy, it will be very cool.
Now as you know, Rome wasn't built in a day...

Rémi

On Aug 2, 2011 12:09 PM, "Hamlet DArcy" <[hidden email]> wrote:
> I had forgotten Guillaume's request to stay quiet until after the holidays. I'm sorry I released this information too soon.
>
> ----- Original Message -----
>> Am 02.08.2011 09:53, schrieb Alex Tkachman:
>> > I was so happy to learn about static mode for groovy from blog post
>> > of
>> > Hamlet and not from discussion in this list. After several years
>> > convincing the world that it is great idea and having zero help
>> > from
>> > groovy core team. Thank you very much guys. For friendship and
>> > willingness of collaborate.
>>
>> We wanted to go official after Guillaume's holiday by starting the
>> discussions here then. And after having a more clear picture of what
>> exactly we want to do.
>>
>> 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
>>
>>
>>
>
> ---------------------------------------------------------------------
> 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: Static mode

Jochen Theodorou
In reply to this post by Alex Tkachman
Am 02.08.2011 17:23, schrieb Alex Tkachman:
> As i said I really appreciate being left out of the loop after all my
> contributions to groovy core and to vision of static compilation.

Alex, if you now imagine that Guillaume, myself and some other did go
and designed a "static mode" for Groovy, then you are wrong. We
contacted some people to see about their fears and concerns for such a
beast. We didn't make really any decision about how it should work, only
about if it should be done and what speaks against it. Also if you think
there had been a lot of discussion in the past... we only about started
with this 2 months ago, with last month basically nothing happening on
the outside or with these people. We put it a bit on hold because you
started the poll and I wanted to use that as entry point for more
discussion in that area with you. Only the two mails we exchanged never
reached this point, as you stopped replying to my second mail already
(that was July 13). The next planned step, once Guillaume is back from
holidays, was to start open discussion on the list including you and
starting a prototype. That's the point we wanted to include everyone and
that is right after we wanted trying to talk to you again. Since we
already know your position to static typing there was no use about
asking you about it directly before that. Only when we start with some
actual planning it makes sense to me. We didn't start the discussion
right away in the open, because we hadn't decided to even do that yet
and it makes only partially sense to stir up the community with worries
about something that is maybe never coming.

Integrating Groovy++ in Groovy is for me all about taking the concepts
that work, look good and are useful, to then make them better and free
them from all the ballast it of course has, because in Groovy++ things
are not as tightly integrated as they can probably be with Grumpy. A
goal for Grumpy is to keep things as simple as possible first. That
means no traits, no native bytecode, no SMA conversion beyond what
Groovy already has, no tail recursion, no multi property set operator,
no mixing in one block of static and nonstatic code, and more.

And the problem sphere for Grumpy and Groovy++ is different. For example
for the each method with a Closure taking an Object parameter, it is for
Grumpy enough to see the DGM-each and be done. Another example is to
subclass BigInteger and there provide your own plus method. Basically
for Grumpy it can be enough to take the BigInteger method we have
defined in the math support, because Grump won't wire that, the runtime
will still do that for us. For Groovy++ you not only want the right
implementation of that method, you also want to make the invocation of
it efficient. That is a much more complex thing to do.

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


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

Re: Static mode

Jon Cox


 Jochen,

> Am 02.08.2011 17:23, schrieb Alex Tkachman:
>> As i said I really appreciate being left out of the loop after all my
>> contributions to groovy core and to vision of static compilation.
>
[snip]
>
> Only when we start with some  
> actual planning it makes sense to me. We didn't start the discussion  
> right away in the open, because we hadn't decided to even do that yet  
> and it makes only partially sense to stir up the community with worries  
> about something that is maybe never coming.




   Early musings need to be labeled as such, but I suspect most
   people in the community would appreciate being included more
   than protected from being stirred up.

   Otherwise, it's not surprising that members of the community
   might end up feeling cheated from a well-earned spot around
   the water-cooler.

   I'd like to see groovy be both an "open planning" and
   "open musing" project, rather than simply "open source".  



> For Groovy++ you not only want the right  implementation of that method,
> you also want to make the invocation of it efficient. That is a much
> more complex thing to do.


   I want to write code that benefits from a terse
   and easy-to-learn grammar, yet is nearly as
   fast as Java.  That seems to be the high-level
   goal of Groovy++.

   What's the high-level goal of static groovy?
   Is it to be 100% compatible with groovy 1.x only more
   type-safe?  Is it to be about as fast as Java code?

   
                      Cheers,
                      -Jon


---------------------------------------------------------------------
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: Static mode

Jochen Theodorou
Am 02.08.2011 22:53, schrieb Jon Cox:
[...]
>
>     Early musings need to be labeled as such, but I suspect most
>     people in the community would appreciate being included more
>     than protected from being stirred up.

I think it depends. I think it is better you know what you talk about if
you start something that can easily become an emotion controlled debate.

[...]

>> For Groovy++ you not only want the right  implementation of that method,
>> you also want to make the invocation of it efficient. That is a much
>> more complex thing to do.
>
>     I want to write code that benefits from a terse
>     and easy-to-learn grammar, yet is nearly as
>     fast as Java.  That seems to be the high-level
>     goal of Groovy++.
>
>     What's the high-level goal of static groovy?
>     Is it to be 100% compatible with groovy 1.x only more
>     type-safe?  Is it to be about as fast as Java code?

Grumpy is not supposed to be as fast as Java. Grumpy is about more
static type safety. That is all. Once we have that, we will evaluate the
situation and experience with Grumpy and then maybe make a new project
that uses the type information from Grumpy to be on comparable speed
with Java. But that is a thing in the future and only an option if we
have some satisfactory solution for Grumpy. Also the goal to be as fast
as Java on a java5 or java6 platform means to have different semantics
then what groovy 1.x normally provides. On java7 we will make use of
invokedynamic as much as groovy 1.x allows to make it faster. But for
those bound to java5 and java6 this may be not really an option. In the
end it depends a lot on how fast we can get groovy with invokedynamic. I
think if that is fast enough we may not make a static version with
differing semantics just for java5 and java6. We have to see once we are
in that situation.

Groovy++ is suffering from the semantic gap of static and dynamic
aspects. I think there is no 100% solution possible for these things.
Just compare our DGM and its semantics with for example extension
methods as they are available in C#. Compared to DGM that is like a half
hearted solution, born from the need for such a thing, but not really
being able to express that statically.

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


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

Re: Static mode

Alex Tkachman
In reply to this post by Jochen Theodorou

Jochen,

first of all thank you for explaination. Secondly sorry for not repliing for email you mentioned - i am on long vacations since that time and have pretty much no internet access. Right now i typing this email from mobile phone with only hope that i will be able to send it so please sorry for typos.

Now. We obviously deal with very wrong communication. As far as i know i never was fired from groovy core team (and still contribute) and if there is discussion publicly or just between team members i think i have right to be part of the discussion. I can not speak for Roshan but as far as i know him (one of groovy despots) was not part of the discussion as well.

Yes, my opinion is well known but did i have opportunity to explain to others why i believe approach you choose is wrong? i wish i knew who were these "senior members of groovy community") - at least i would have chance to ask each an every person to have dedicated conversation with me and hear my arguments. But now it seems that basic decision is taken.

Best regards
Alex

On Aug 2, 2011 6:35 PM, "Jochen Theodorou" <[hidden email]> wrote:
> Am 02.08.2011 17:23, schrieb Alex Tkachman:
>> As i said I really appreciate being left out of the loop after all my
>> contributions to groovy core and to vision of static compilation.
>
> Alex, if you now imagine that Guillaume, myself and some other did go
> and designed a "static mode" for Groovy, then you are wrong. We
> contacted some people to see about their fears and concerns for such a
> beast. We didn't make really any decision about how it should work, only
> about if it should be done and what speaks against it. Also if you think
> there had been a lot of discussion in the past... we only about started
> with this 2 months ago, with last month basically nothing happening on
> the outside or with these people. We put it a bit on hold because you
> started the poll and I wanted to use that as entry point for more
> discussion in that area with you. Only the two mails we exchanged never
> reached this point, as you stopped replying to my second mail already
> (that was July 13). The next planned step, once Guillaume is back from
> holidays, was to start open discussion on the list including you and
> starting a prototype. That's the point we wanted to include everyone and
> that is right after we wanted trying to talk to you again. Since we
> already know your position to static typing there was no use about
> asking you about it directly before that. Only when we start with some
> actual planning it makes sense to me. We didn't start the discussion
> right away in the open, because we hadn't decided to even do that yet
> and it makes only partially sense to stir up the community with worries
> about something that is maybe never coming.
>
> Integrating Groovy++ in Groovy is for me all about taking the concepts
> that work, look good and are useful, to then make them better and free
> them from all the ballast it of course has, because in Groovy++ things
> are not as tightly integrated as they can probably be with Grumpy. A
> goal for Grumpy is to keep things as simple as possible first. That
> means no traits, no native bytecode, no SMA conversion beyond what
> Groovy already has, no tail recursion, no multi property set operator,
> no mixing in one block of static and nonstatic code, and more.
>
> And the problem sphere for Grumpy and Groovy++ is different. For example
> for the each method with a Closure taking an Object parameter, it is for
> Grumpy enough to see the DGM-each and be done. Another example is to
> subclass BigInteger and there provide your own plus method. Basically
> for Grumpy it can be enough to take the BigInteger method we have
> defined in the math support, because Grump won't wire that, the runtime
> will still do that for us. For Groovy++ you not only want the right
> implementation of that method, you also want to make the invocation of
> it efficient. That is a much more complex thing to do.
>
> 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
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Static mode

Jochen Theodorou
Am 02.08.2011 23:34, schrieb Alex Tkachman:
> Jochen,
>
> first of all thank you for explaination. Secondly sorry for not repliing
> for email you mentioned - i am on long vacations since that time and
> have pretty much no internet access.

I was thinking that this might be the reason... Another fact for which I
wanted to wait a bit longer.

> Right now i typing this email from
> mobile phone with only hope that i will be able to send it so please
> sorry for typos.

ah don't worry ;)

[...]
> Yes, my opinion is well known but did i have opportunity to explain to
> others why i believe approach you choose is wrong?

That is exactly why we wanted to talk to you after we have decided for
the approach or not. Since the time table is now messed up, I would like
to ask you now about what you think we will do and why you think it is
wrong. Vocations are obviously a problem though.

> i wish i knew who
> were these "senior members of groovy community") - at least i would have
> chance to ask each an every person to have dedicated conversation with
> me and hear my arguments. But now it seems that basic decision is taken.

Again, we didn't design a static mode with them. We asked about their
fears, hopes, expectations and opinions. And we wanted those original,
without the influence of others, which is why we asked not all in one
group. The actual design of Grumpy is what comes now.

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


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

Re: Static mode

Andrew Eisenberg
In reply to this post by Jochen Theodorou
> Grumpy (project name, not actual name) will type check a Groovy program. Not
> all Groovy programs will pass this, so Grumpy will make a real subset of
> Groovy. Some things will most probably never compile. Part of this is the
> spread operator. Another example would be the regexp matching, were a
> Closure can have the number of matching groups as parameters. I am intending
> to make an annotation used by Grumpy that can express types more freely as
> strings.. for exmaple:
>
> @StaticTyped("TT1(Ljava/lang/Object;Z)","TT1(Ljava/lang/Object)")
> Object call(Object... args){...}

Not a huge fan of this syntax.  I can't expect normal users to be able
to write anything like this, and furthermore the text inside the
annotation is not easily checked by an IDE.  How about something more
like this:

@TypeSuggestion T1 call(Object arg1, boolean arg2) { }

The @TypeSuggestion means that the compiler will erase all types when
producing the byte code.  The benefits is that IDEs can use this
information much more easily and everyone would know how to write and
understand it.

The downside that I can see is that you could not easily convert to
varargs as in your example above.

---------------------------------------------------------------------
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: Static mode

Jochen Theodorou
Am 03.08.2011 19:11, schrieb Andrew Eisenberg:
[...]
>> @StaticTyped("TT1(Ljava/lang/Object;Z)","TT1(Ljava/lang/Object)")
>> Object call(Object... args){...}
>
> Not a huge fan of this syntax.

It is not supposed to be used by normal user, but an information used by
the compiler and emitted. If the user is using this, then only in Java
programs and only as last resort. And... it is only a first draft ;)

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


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

Re: Static mode

HamletDRC2
> It is not supposed to be used by normal user, but an information used
> by
> the compiler and emitted. If the user is using this, then only in
> Java
> programs and only as last resort. And... it is only a first draft ;)


Do I understand this correctly?

The user writes this:
  def call(Object... args) { ... }

And the compiler adds on an annotation to the bytecode:

  @StaticTyped("TT1(Ljava/lang/Object;Z)","TT1(Ljava/lang/Object)")
  def call(Object... args) { ... }

And the type inference mechanism for code that invokes this method uses the data stuffed in @StaticTyped in order to verify types.

Is that correct?

--
Hamlet

----- Original Message -----

> Am 03.08.2011 19:11, schrieb Andrew Eisenberg:
> [...]
> >> @StaticTyped("TT1(Ljava/lang/Object;Z)","TT1(Ljava/lang/Object)")
> >> Object call(Object... args){...}
> >
> > Not a huge fan of this syntax.
>
> It is not supposed to be used by normal user, but an information used
> by
> the compiler and emitted. If the user is using this, then only in
> Java
> programs and only as last resort. And... it is only a first draft ;)
>
> 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
>
>
>

---------------------------------------------------------------------
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: Static mode

Chanwit Kaewkasi
In reply to this post by Jochen Theodorou
Hi Jochen,

This idea is really quite interesting. You now have runtime type
information attached to each method.
This not only optionally allows very late type checking, but also
invoking methods in the normal Groovy way.

Cheers,

Chanwit

On Thu, Aug 4, 2011 at 00:52, Jochen Theodorou <[hidden email]> wrote:

> Am 03.08.2011 19:11, schrieb Andrew Eisenberg:
> [...]
>>>
>>> @StaticTyped("TT1(Ljava/lang/Object;Z)","TT1(Ljava/lang/Object)")
>>> Object call(Object... args){...}
>>
>> Not a huge fan of this syntax.
>
> It is not supposed to be used by normal user, but an information used by the
> compiler and emitted. If the user is using this, then only in Java programs
> and only as last resort. And... it is only a first draft ;)
>
> 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
>
>
>



--
Chanwit Kaewkasi
code.google.com/p/zkgrails
twitter.com/chanwit

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

    http://xircles.codehaus.org/manage_email


123
Loading...