[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[technology-pmc] Jiffle language and String template
|
Evening Michael: I am just going to do a sanity check with the technology-pmc list on this.
Michael is in the middle of updating Jiffle to use Antlr 4 (as it is a version we can distribute from uDig). Antlr is a one two punch consisting of the antlr-runtime (supporting parsing), and a string template library (used for emitting).
Today I noticed that the antlr StringTemplate 3.2.1 has previously been approved (CQ6759).
This has lead to the following discussion about how Jiffle can be fixed up so we can distribute it:
1) If we have Jiffle use ST 3.2.1 we end up with ANTLR 2.7.7 as a
transitive dependency and there is no way to avoid it.
2) If we use ST 4.0.x we get ANTLR 3.5 as a transitive dependency.
3) If we use FreeMarker you obviously ending up with two ANTLR
versions plus it has no other dependencies.
Our anchor in all this is that I'm definitely going to use ANTLR 4 -
it makes the Jiffle grammars and compiler code so much cleaner. That,
in turn, means that (1) is obsolete so we can forget about it. Out of
(2) and (3) I think my preference is (2). The reason for that is that
ST seems a bit easier than FreeMarker for turning the intermediate
representation of a Jiffle program (annotated parse tree) into the
final Java sources.
If I understand Michael correctly he is interested in the following course of action:
Jiffle
<-- Antlr Runtime 4
<-- Antlr StringTemplate 4 <-- Antlr Runtime 3.5
Aside: I really do not understand why Antlr insists of depend ending on older versions of itself :(
--
Jody Garnett
On Tuesday, 13 August 2013 at 11:03 AM, Michael Bedward wrote:
That,
in turn, means that (1) is obsolete so we can forget about it. Out of
(2) and (3) I think my preference is (2). The reason for that is that
ST seems a bit easier than FreeMarker for turning the intermediate
representation of a Jiffle program (annotated parse tree) into the
final Java sources.
