groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Milles, Eric (TR Tech, Content & Ops)" <eric.mil...@thomsonreuters.com>
Subject Re: [VOTE] Polish the generics type syntax for closure
Date Sun, 17 Feb 2019 17:31:11 GMT
"The proposed syntax is actually a syntax sugar, which will be transformed to the current code
with annotations finally, so it should not result in much rework."


For the compiler this is the case.  And that is what groovy-core implements and tests.  Fully-formed
syntax compiled and transformed to class files.


For an editor, you often have malformed syntax because the source is being worked on.  Often
it is not feasible to run AST transforms on this to get the final generated state of the source
or class file.  Additionally, each new syntax element often requires additional work on the
antlr grammar to add parser recovery.  groovy-core does not do this work because they expect
the source to be final or else an error is emitted and parsing is terminated.  An editor often
needs to try and continue so that some assist can be provided on the elements that exist in
a malformed source so the user can keep working towards a properly-formed syntax.


So, parser recovery is new development.  And interpretation of new syntax in the absence of
running all AST transforms to completion is new development.


Some consideration must be given for tools in these new features.  It is not always possible
to start with fully-formed sources and process them with the compiler through to class file
generation.  In addition, a dynamic language provides many facilities based on the run-time
state of a program.  However a tools must make guesses based on static analysis of the program.
 This has led to many features that work great in a running script or program but make it
very difficult to provide quality tooling support.


________________________________
From: Daniel.Sun <sunlan@apache.org>
Sent: Sunday, February 17, 2019 10:27 AM
To: dev@groovy.incubator.apache.org
Subject: Re: [VOTE] Polish the generics type syntax for closure

> It took me a lot of work to support @ClosureParams and @DelegatesTo in
Eclipse.  I'm not looking forward to doing it all over again.

The proposed syntax is actually a syntax sugar, which will be transformed to
the current code with annotations finally, so it should not result in much
rework ;-)

P.S. If the proposal is not accepted, it will be a good news for my son(4
years old), because I will have more time to play with him :-)

Cheers,
Daniel.Sun





-----
Apache Groovy committer
Blog: https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.sunlan.me&d=DwICAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=tPJuIuL_GkTEazjQW7vvl7mNWVGXn3yJD5LGBHYYHww&m=KqNqDsWXdGa_beGx184WP9jj96ZTWfjycUilCH6-l0k&s=8owbJdkIrnrXxk16IDJxTVKQt4kUYXLKg6dbOb87bN8&e=
Twitter: @daniel_sun

--
Sent from: https://urldefense.proofpoint.com/v2/url?u=http-3A__groovy.329449.n5.nabble.com_Groovy-2DDev-2Df372993.html&d=DwICAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=tPJuIuL_GkTEazjQW7vvl7mNWVGXn3yJD5LGBHYYHww&m=KqNqDsWXdGa_beGx184WP9jj96ZTWfjycUilCH6-l0k&s=GCIq0fTbvh8voQ0v2NCjuC4EtvzXjtD83tx2pD-yXhU&e=

Mime
View raw message