Re: To PMC (and others): Board report draft for February
On Thu, Feb 15, 2024 at 7:08 PM wrote: > Ok, I see that my confusion is definitely justified. > Well, only insofar as willful ignorance is justified. I already explained that there is no copyright issue regarding the FreeMarker 3 that I announced. FreeMarker 3 is based on code that was never at Apache. It is the continuation of the trunk (a.k.a. "master"/"main") of development from when FreeMarker was on Sourceforget.net. (Apache FreeMarker is based on the obsolete code from the 2.3 maintenance branch.) Ask Daniel. He'll tell you the same thing. > > I would definitely bring this up to the Apache board. > I am not a lawyer, but am familiar somewhat with the issue at hand, and it > looks like a copyright dispute, at least in the making. > No, not at all. There is no copyright issue. There could conceivably be a trademark issue, but I doubt it really. As Daniel pointed out, and I do not dispute this, I did sign some document or other where, presumably, I agreed not to use the name FreeMarker. However, it can't really be a binding contract since there was no quid pro quo. It's just me promising something in exchange for absolutely nothing. So, since it's not a binding contract, what it boils down it is that I simply changed my mind. (Shrug.) > An entity with a copyright needs to defend it, thus it needs to be brought > up to the Board. This is what it’s there for. > Well, you are quite a pugnacious little punk, aren't you? Well, fine. Such is life. I am quite satisfied that there is no particular reason that I cannot resume work on the main stream of FreeMarker development and simply say that this is what it is. I mean, really, what are you going to do about it? (Punk...) Regards, Jonathan Revusky -- CongoCC Parser Generator: https://parsers.org/ Try out the FreeMarker 3 Preview: https://github.com/freemarker/freemarker3/wiki > > > > On Feb 15, 2024, at 8:37 AM, Jonathan Revusky wrote: > > > > On Thu, Feb 15, 2024 at 9:28 AM Daniel Dekany > > wrote: > > > >> As far as Apache is concerned, there will be no other template engine > with > >> "FreeMarker" in its name, only Apache FreeMarker. > > > > > > Well, yeah, I anticipated that this would be your position. Basically, > the > > idea is that you'll just pretend, month after month, year after year... > > that the more advanced version of the tool does not exist. And maybe, due > > to the visibility advantage of the Apache name, most people won't realize > > that the more advanced version exists. (That remains to be seen.) > > > > Regardless, the whole thing is really quite ignoble and downright > pathetic. > > Frankly, it boils down to the idea that people should be saddled with > > something completely obsolete and inferior so that people like you can > feel > > like you're somebody... though that seems to be what ASF is about mostly. > > But surely you can understand that I don't feel like encouraging that > kind > > of thing or supporting it. > > > > > > > >> Even if an Apache project > >> is retired, its name goes into the grave with it (usually). There are no > >> plans to retire Apache FreeMarker. > >> > >> This is simply because the "FreeMarker" name was given to the Apache > >> Software Foundation (in 2015). Jonathan signed the Software Grant > Agreement > >> back then. > > > > > > That is true. I did sign that. At that time, I did not anticipate doing > > anything further with FreeMarker. > > > > So, I stated my intent at that point in time and have now changed my > mind. > > I am quite satisfied that there is no breach of contract. There can't be > a > > binding contract without any quid pro quo whatsoever. I hand over > something > > in exchange for what exactly? Nothing. You don't need to have gone to law > > school to know that that is not a binding contract -- one party promising > > something in exchange for nothing... > > > > So I said (though it was not really legally binding) that I did not > intend > > to use the FreeMarker name any more. And I did not intend to, but I have > > since changed my mind. > > > > So, as things stand now, you can expect that there will be some new > > FreeMarker releases forthcoming, based on the much more advanced codebase > > developed outside ASF. > > > > Jonathan Revusky > > -- > > Check out the new features in FreeMarker 3: > > https://github.com/freemarker/freemarker3/wiki > > CongoCC Parser Generator: > https://github.com/congo-cc/congo-parser-generator > > > >
Re: To PMC (and others): Board report draft for February
On Thu, Feb 15, 2024 at 9:28 AM Daniel Dekany wrote: > As far as Apache is concerned, there will be no other template engine with > "FreeMarker" in its name, only Apache FreeMarker. Well, yeah, I anticipated that this would be your position. Basically, the idea is that you'll just pretend, month after month, year after year... that the more advanced version of the tool does not exist. And maybe, due to the visibility advantage of the Apache name, most people won't realize that the more advanced version exists. (That remains to be seen.) Regardless, the whole thing is really quite ignoble and downright pathetic. Frankly, it boils down to the idea that people should be saddled with something completely obsolete and inferior so that people like you can feel like you're somebody... though that seems to be what ASF is about mostly. But surely you can understand that I don't feel like encouraging that kind of thing or supporting it. > Even if an Apache project > is retired, its name goes into the grave with it (usually). There are no > plans to retire Apache FreeMarker. > > This is simply because the "FreeMarker" name was given to the Apache > Software Foundation (in 2015). Jonathan signed the Software Grant Agreement > back then. That is true. I did sign that. At that time, I did not anticipate doing anything further with FreeMarker. So, I stated my intent at that point in time and have now changed my mind. I am quite satisfied that there is no breach of contract. There can't be a binding contract without any quid pro quo whatsoever. I hand over something in exchange for what exactly? Nothing. You don't need to have gone to law school to know that that is not a binding contract -- one party promising something in exchange for nothing... So I said (though it was not really legally binding) that I did not intend to use the FreeMarker name any more. And I did not intend to, but I have since changed my mind. So, as things stand now, you can expect that there will be some new FreeMarker releases forthcoming, based on the much more advanced codebase developed outside ASF. Jonathan Revusky -- Check out the new features in FreeMarker 3: https://github.com/freemarker/freemarker3/wiki CongoCC Parser Generator: https://github.com/congo-cc/congo-parser-generator > The project can be freely forked, but the result should be > released under a different name. That's that simple. > > > On Thu, Feb 15, 2024 at 5:40 AM wrote: > > > I am still confused about “Apache FreeMarker 3” vs “FreeMarker 3” > > Are these two separate projects? Is the direction to remove FreeMarker > > from Apache eventually? > > I don’t think I am the only one that’s confused. > > Would that something that would require Apache Board attention? > > > > > On Feb 14, 2024, at 12:20 PM, Daniel Dekany > wrote: > > > > > > It's here: > > > > > > https://cwiki.apache.org/confluence/display/FREEMARKER/Board+report+draft+-+February+2024 > > > > > > Anything to add, especially for PMC members? Though not sure there will > > be > > > time for updates before they close it... but still. > > > > > > -- > Best regards, > Daniel Dekany >
Re: Request for feedback: Switch directive proposal
On Sat, Feb 10, 2024 at 5:48 PM Simon Hartley wrote: > I've made an implementation of #on here: > > https://github.com/scrhartley/apache-freemarker/commit/cee8d076b02e8dbcae0b84eabc76814aaea8baf6 > > * Fall-through does not occur when using #on. > * #on supports multiple conditions > * #default may be used with #on > * This implementation doesn't allow mixing #case and #on. > * When #on has been used in the #switch then #break and #continue are not > supported, otherwise the legacy behavior is used. This means that the > behavior in a #default depends upon whether an #on has been used. > I would say that if you're going to go for this, you should really introduce an entirely new directive, like maybe #match, either #match/#case or maybe #match/#on. And then just leave #switch alone. That strikes me as cleaner, though what do I know? I'm just the guy who implemented this in code all those years ago. Actually, now that I think about it, this #switch/#case with default fall-through should really have been deprecated and then later removed in the early 2000's. As far as I can see, everybody would be better off without it! But now it's been there for so many years...This kind of construct made sense in a system programming language like C because the construct can be translated into a very efficient jump table in machine code, but... JR > > I've updated some of the tests, but I'm unsure if that's sufficient. I saw > that switch.ftl exists, but since it's in the jython25 tests I left it > alone. After my changes "gradlew check" still passes. I haven't updated the > manual. > > I'm now looking for feedback and possibly next steps. What should happen > to get this ready for merge request? > > --- > Best regards, > Simon Hartley > > > > > > > > > On Saturday, 10 February 2024 at 09:31:32 GMT, Daniel Dekany < > daniel.dek...@gmail.com> wrote: > > > > > > > Because there's not an explicit closing tag for #case or #on, the use of > #break in the following avoids a trailing newline > > > Yeah, but that's really a hack. I mean, we have the same whitespace issue > with #else, and #elseif. So this is just not the feature where we address > whitespace issues in general. > >
Re: What's the status of FREEMARKER-35?
On Tue, Feb 6, 2024 at 10:53 AM Taher Alkhateeb
wrote:
>
> When you have two code bases that share a common ancestry, then the two
> different lines of development are called forks,
Well, no. That's just not true. Do people say that JDK 7 and JDK 8 are
forks? No. The latter is not a fork, but just a continuation of development
on the same project.
I already explained the history of this. The FreeMarker 3 that I am working
on is the continuation of development on the trunk ("master" or "main" in
Git-speak) of the code from when the project was hosted on Sourceforge. A
continuation of development by the person who is, to all intents and
purposes, the original author. I daresay that nobody who understood the
situation would call this a "fork".
> it's not a bad thing and if you check github you'll notice that it's kind
> of a popular button over there.
Well, it's true that in git, the term "fork" does not have a negative
connotation, but I was pretty certain that the way you were using the term,
you did mean it negatively. That view is reinforced by the hostile tone of
your message.
In any case, if anything is a "fork", it is "Apache FreeMarker" because
Daniel chose to fork off from the main stream of development by taking an
older obsolete version of the code base, the FreeMarker 2.3 maintenance
branch and using that as the basis for "Apache FreeMarker". Once I resumed
my FreeCC work, which used the more advanced version of the code (the trunk
in the code repository), yes, there was effectively a fork, as in a
bifurcation, but the record is clear. The person who forked, i.e. caused a
bifurcation, was Daniel. My work is simply a continuation of work on the
main stream of development.
The history of all this is kind of convoluted in a way, but it's not really
that hard to understand either -- unless you very much don't want to
understand, which I suspect is your case...
> Sorry but I will refrain from nothing, especially when it's just _your_
> interpretation or mind-reading attempt.
>
Well, I do not think that I am imagining the hostility in your tone.
Anyway, I would re-iterate that you really ought to refrain from referring
to my work as a "fork" because it is not, and I already explained this. If
somebody was misspelling your last name, let's say with one 'e' instead of
two, and you corrected him, and he kept misspelling your name regardless,
would this not be some kind of passive aggression?
>
> I don't know you nor do I know Daniel beyond just interactions in here,
> but at this point and after everything I read, I don't care if your code
> quality is 10,000 times better. I just don't want to deal with you
> regardless of who you are or what your code is like.
Well, the "Apache FreeMarker" code was also largely written by me. I mean,
certainly the core parser/renderer part which is what FreeMarker mostly is.
"Apache FreeMarker" also includes the BeansWrapper written entirely by
Attila Szegedi, which was 12000 lines of rather grotesquely over-engineered
code. I ended up rewriting all of that in about 400 lines. So, as you could
imagine, it is a lot easier to work with!
But the problem with what you're saying is that if you get in there and
work on the "Apache FreeMarker" code, you're largely just working with an
older, obsolete version of the code by same author. Me!
But anyway, there's not much point in announcing loudly to the world that
you don't want to collaborate with me. Just don't collaborate with me. I
don't know what the point of this is. It's like you're trying to "virtue
signal" or something. Somehow making a show of this hostility towards me is
somehow virtuous or something... (SMH).
Check out new FreeMarker 3 features:
https://github.com/freemarker/freemarker3/wiki
Jonathan Revusky
>
> On Monday, February 05, 2024 15:44 +03, Jonathan Revusky <
> revu...@gmail.com> wrote:
> (Sigh.)
>
> Well, first of all, your characterization of the overall situation is
> pretty dubious. For one thing, you refer to *my* work as a "fork", which is
> quite loaded language, since a "fork" is usually taken to be a bad thing.
> But really, this is a very tenuous concept in this context. A "fork" is
> short for a bifurcation of effort, no? That would mean that I'm doing
> something and you guys are doing something, right? Except that is hardly a
> correct characterization. The cold, hard truth is that, over the last year
> in particular, I have been working on the thing (I mean in a fundamental,
> meaningful way, making significant, even revolutionary changes, to the code
> base, it's much better structured now) and this community has
Re: What's the status of FREEMARKER-35?
he FreeMarker 3 code that I'm working on is not a "fork". It's just a continuation (after a long hiatus) of the main line of development which stems from the SVN trunk back when the project was on Sourceforge. > If the interest of the community is in moving the technology forwards, > then that work would seem a suitable starting point, rather than an old > branch which seems very out of date but just happens to be in the same > repository. Well, sure, but the most advanced version of the code was just mothballed for no obvious reason back when, so... Actually, I think the reason mainly was to NOT use FreeCC. Daniel very much did not want any further involvement on my part (and I think still doesn't) so that would surely be the reason for all that. But if there is some other reason, Daniel is around and can explain it. > You'll see that for whatever reason, it's hard to innovate in the Apache > project because the challenges are not only technical (getting some work > done) but also social (getting others to accept to work with it, or with > you). Well, yeah. Even aside from the aforementioned skullduggery with so much of my work (everything I did from 2006-2008) being thrown away, just the whole idea of trying to operate in this scene... it just looks so unappealing. Well, the appealing aspect is that your work automatically gets a lot more usage and visibility, but for me, that's just not a positive tradeoff. There are aspects of the "culture" here that I would be very disinclined to deal with... > What are the recent innovations in Apache FreeMarker, apart from working a > bit on the margins like servlet API-related stuff (hardly core to a > template engine)? I'm only a recent subscriber to this list so I've only > seen discussion of that kind of thing, but happy to be informed about other > more substantial innovations. Now it's a very mature project that perhaps > doesn't need much in the way of innovation, but for me the new syntax > changes in Jonathan's project (the ability to use e.g. #if ... /#if > instead of [#if...] [/#if] in many contexts) is a readability win, even if > it seems a small change. Well, actually, there are much more profound changes now in FreeMarker 3 that are not so readily apparent. Pretty much all that object wrapper stuff is gone. Objects are exposed to the template layer as POJOs. So, in FreeMarker 2.x, anything exposed to the template layer was some sort of TemplateModel instance. So, if you exposed a string, it was either a SimpleScalar or a StringModel, depending on whether you were using the full beans wrapping or not. Now, any string you expose is just a java.lang.String. Same with numbers as well as maps and lists. This version of FreeMarker just uses POJOs pretty much, so it's much less unwieldy to deal with -- for any application programmer who has to interface with FreeMarker. Of course, also, the rewritten parser using CongoCC is such that it is vastly easier to implement new language features than it ever was before. > Not sure how much work would be required to retrofit that in Apache > FreeMarker, but I doubt anyone will step up to do that kind of thing. It seems quite unlikely. :-) In any case, any new language feature is much harder to implement in Apache FreeMarker, because it still uses the old legacy JavaCC. > So if one's primary interest is in the technology and advancing the state > of the art, one tries to work with whatever is the best of breed in an > area. If one's interest is more in being part of a community, then one > works with the community, no matter the technical and social limitations > that this entails. In that case, the technology / technical solutions seem > secondary. > Well, the desire to be part of a community that coalesces around some very obsolete, inferior version of something... also, probably with the unwritten rule that you're never supposed to mention that the more advanced version of the tool exists... Really, c'mon, WTF kind of "community" is that to want to get involved in? But, okay, it's true that different people have a different world view, so JR > > Regards, > Vinay Sajip > > On Monday, 5 February 2024 at 06:22:15 GMT, Taher Alkhateeb > wrote: > > > Hello Jonathan, > > Why yes if you recall I actually replied to you in that thread, and I was > asking you why not join hands in here instead of maintaining a fork and > confusing everyone as to what's going on not to mention fragmenting an > already small community? > > Regards, > > Taher Alkhateeb > > On Sunday, February 04, 2024 23:27 +03, Jonathan Revusky < > revu...@gmail.com> wrote: > Hi Taher (and everyone else). > > A couple of months ago, I announced the availabi
Re: What's the status of FREEMARKER-35?
rsion, with the cleanest, best structured codebase... WITH my collaboration, the involvement of the original author. Based on my own values, it would be a very easy decision. Jon Revusky On Mon, Feb 5, 2024 at 7:22 AM Taher Alkhateeb wrote: > > Hello Jonathan, > > Why yes if you recall I actually replied to you in that thread, and I was > asking you why not join hands in here instead of maintaining a fork and > confusing everyone as to what's going on not to mention fragmenting an > already small community? > > Regards, > > Taher Alkhateeb > > On Sunday, February 04, 2024 23:27 +03, Jonathan Revusky < > revu...@gmail.com> wrote: > Hi Taher (and everyone else). > > A couple of months ago, I announced the availability of a more advanced > FreeMarker 3 version here: https://github.com/freemarker/freemarker3 > > Really, the bottom line is that if you do want to get involved in hacking > the FreeMarker code, this is the one you should get involved in. This is a > continuation of work by the original author (ME) and if you get in there > and have whatever questions about how the code works, you have the > collaboration of the original author (ME). > > If you work on Apache FreeMarker 2.x or 3.x you're working on a much more > primitive, older version of the code. For one thing, the FreeMarker 3 that > I point to is rewritten to use a much more powerful parser generator, which > is CongoCC. And this really has allowed quite a streamlining of the code. > Just look at what the CongoCC grammar looks like: > https://github.com/freemarker/freemarker3/tree/master/src/parser And > compare that with what the legacy JavaCC grammar looks like for Apache > FreeMarker: > > https://github.com/apache/freemarker/blob/2.3-gae/freemarker-core/src/main/javacc/freemarker/core/FTL.jj > > Just eyeball the two and think about which one you would rather work with! > I can be quite objective because I am basically the author of both > versions! > > On Sat, Feb 3, 2024 at 9:20 AM Taher Alkhateeb > wrote: > > > Hello, we were just having a discussion about this: > > > > https://lists.apache.org/thread/2p3521br9jnp9ww1f5vf80l90fntmfdf > > > > Essentially the way I understood it, it's better to focus on 2 and get > > things done as 3's future is not very clear and requires a lot of work > from > > developers intimate with the code base. > > > > Look, the real truth of the matter is that working with either Apache > FreeMarker 2 codebase or the 3, it's just an exercise in necrophilia. > Nothing meaningful has been done for ages and, at this point, there is just > about no prospect of anything happening. By all means, you could get in > there and try to clean it all up and so on, but frankly, your prospects of > ever catching up to the state of the FreeMarker 3 that I have pointed to... > it's quite bleak really. > > I mean, really, c'mon, even just reading between the lines in Daniel's > response to this question about FreeMarker development, you can get the > feeling that it's really just a waste of time. The thing is dead and Daniel > is not hardly even trying to hide this. > > But anyway, 'nuff said. I just would tell you to do your due diligence and > figure out which way is up! I would be delighted to have collaborators, and > you would be collaborating with the person who is, to all intents and > purposes, the original author of the tool. > > It really ought to be a very easy decision. > > Best Regards, > > Jonathan Revusky > > > > > > On February 3, 2024 10:51:15 AM GMT+03:00, Alon Ziv > > wrote: > > >Specifically - is there anything contributors can help with to get this > > >completed? > > >
Re: What's the status of FREEMARKER-35?
Hi Taher (and everyone else). A couple of months ago, I announced the availability of a more advanced FreeMarker 3 version here: https://github.com/freemarker/freemarker3 Really, the bottom line is that if you do want to get involved in hacking the FreeMarker code, this is the one you should get involved in. This is a continuation of work by the original author (ME) and if you get in there and have whatever questions about how the code works, you have the collaboration of the original author (ME). If you work on Apache FreeMarker 2.x or 3.x you're working on a much more primitive, older version of the code. For one thing, the FreeMarker 3 that I point to is rewritten to use a much more powerful parser generator, which is CongoCC. And this really has allowed quite a streamlining of the code. Just look at what the CongoCC grammar looks like: https://github.com/freemarker/freemarker3/tree/master/src/parser And compare that with what the legacy JavaCC grammar looks like for Apache FreeMarker: https://github.com/apache/freemarker/blob/2.3-gae/freemarker-core/src/main/javacc/freemarker/core/FTL.jj Just eyeball the two and think about which one you would rather work with! I can be quite objective because I am basically the author of both versions! On Sat, Feb 3, 2024 at 9:20 AM Taher Alkhateeb wrote: > Hello, we were just having a discussion about this: > > https://lists.apache.org/thread/2p3521br9jnp9ww1f5vf80l90fntmfdf > > Essentially the way I understood it, it's better to focus on 2 and get > things done as 3's future is not very clear and requires a lot of work from > developers intimate with the code base. > Look, the real truth of the matter is that working with either Apache FreeMarker 2 codebase or the 3, it's just an exercise in necrophilia. Nothing meaningful has been done for ages and, at this point, there is just about no prospect of anything happening. By all means, you could get in there and try to clean it all up and so on, but frankly, your prospects of ever catching up to the state of the FreeMarker 3 that I have pointed to... it's quite bleak really. I mean, really, c'mon, even just reading between the lines in Daniel's response to this question about FreeMarker development, you can get the feeling that it's really just a waste of time. The thing is dead and Daniel is not hardly even trying to hide this. But anyway, 'nuff said. I just would tell you to do your due diligence and figure out which way is up! I would be delighted to have collaborators, and you would be collaborating with the person who is, to all intents and purposes, the original author of the tool. It really ought to be a very easy decision. Best Regards, Jonathan Revusky > > On February 3, 2024 10:51:15 AM GMT+03:00, Alon Ziv > wrote: > >Specifically - is there anything contributors can help with to get this > >completed? >
Re: Request for feedback: Switch directive proposal
I never liked the #switch directive. There is about 15000 lines of FTL here: https://github.com/congo-cc/congo-parser-generator/tree/main/src/templates that I mostly wrote. It's part of the CongoCC parser generator. I just checked and there is not a single #switch directive in all of it. Not one. I just never use it. I guess I always use #if...#elseif.../#if. The reason there is a #switch directive in FreeMarker is because the original author of FreeMarker 1.x had it in there. (That would be from 1998 or thereabouts.) And (rightly or wrongly) when I took over FreeMarker development towards the end of 2001, I continued to have it, even though I said openly that I didn't like it. You know, the main reason (AFAICS) that switch/case is appealing in C (and C++/Java etc) is because in a compiled language, you can translate this into a jump table that is, in principle, more efficient than if-elseif..else. Well, somewhat more efficient, probably not a significant difference usually. But that consideration does not apply to FreeMarker anyway. As for default fall-through, that's probably just a design mistake from way back that we're still living with -- though, as you point out, Go finally corrects that. On Sat, Feb 3, 2024 at 10:20 PM Simon Hartley wrote: > If you leave the parent directive as switch, then there would need to be a > decision for what should happen if the user tries to mix option and case in > the same switch, i.e. should it "just work"? > > I did remember that JSP used choose/when/otherwise, so your previous > suggestion isn't without precedence. #option is as good as any (ahead of > #choice and #when ???), but here are some more random words anyway: #check, > #criterion, #test > I'm not 100% certain that there is any need for a #switch directive in a template language like FreeMarker. (As I said, I never use it myself.) Probably I should have axed it back in 2001! But, yes, one possibility would be to just get rid of it, or only support it in a backward compatibility mode maybe, and then consider whether to introduce some newer construct like #match or #choice or something like that, that is less problematic. > > Your idea for multiple values per case seemed like a nice upgrade. What > are your thoughts on "values" being expressions as I touched on in the > Future Work section? > Well, actually, having multiple values in a switch looks like a good idea. However, it also seems like a good idea to get rid of the switch with the error-prone fall-through, so... I think it would be better to have a newer construct that introduces these ideas and does not have the fall-through behavior. Well, just to tell you that you do have me thinking about it. I might implement something like this in FreeMarker 3 but then again, there are a lot of other pending issues, and I don't see this as having very high priority. Regards, Jon > > > > > > On Saturday, 3 February 2024 at 18:19:09 GMT, Daniel Dekany < > daniel.dek...@gmail.com> wrote: > > > > > > > <#switch value fallthrough="explicit"> > > With that it's at least clear which behavior we get, but then I guess it's > too verbose. > > > I would point out that Java switch expressions (not statements) don't > allow fall-through at all. > > I'm pretty confident that if we support multiple values per #case (or > whatever it will be called), then fall-through is just not worth the > trouble. > > > Java 21 Pattern Matching syntax > > That's unfortunate, as #when was high on my list. Though it's not in place > of "case" in Java, so it's maybe not that confusing if we have it in place > of #case. Anyway, how about #option then? > > <#switch contact.type> > <#option 'INDIVIDUAL', 'PROXY'> > ... > <#option 'ORGANIZATION'> > ... > <#default> > ... > > > > On Sat, Feb 3, 2024 at 6:11 PM Simon Hartley .invalid> > wrote: > > > Cool. > > > > Just to cover all bases, what about the switch behavior remaining the > same > > unless you opt-in using something like: > > <#switch value fallthrough="explicit"> > > Would you still rather not add the mental overhead of such modal > behavior? > > Given your reaction to Go's choice, I assume you'd rather not do that. > > I would point out that Java switch expressions (not statements) don't > > allow fall-through at all. (There is a compile error if you try to use > the > > block syntax that doesn't contain a yield and without the block syntax > then > > the yield is implicit.) > > > > If we went the new directive route, should it allow fall-through at all? > > > > Naming with a new directive may require care, since when clauses are part > > of Java's new Java 21 Pattern Matching syntax and so may lead to higher > > expectations. > > (see: > > > https://docs.oracle.com/en/java/javase/21/language/pattern-matching-switch-expressions-and-statements.html#GUID-A5C220F6-F70A-4FE2-ADB8-3B8883A67E8A > > ) > > > > > > > > > > > > On Saturday, 3 February 2024 at 09:44:38 GMT, Daniel Dekany < > > daniel.dek...@gmail.com
Re: Long-Awaited FreeMarker 3 Preview Available
On Sun, Nov 12, 2023 at 12:01 PM Daniel Dekany wrote: > To clarify, he calls it simply "FreeMarker" (no "Apache" in it), and it's > from a branch that was made (and then was abandoned for, I guess, 12 years, > or so) long before donation to Apache. Right. Thanks for making that point. Though I would correct your referring to this as being a "branch". Actually, it was the trunk! But regardless, that was the 2.4 codebase which was never hosted at Apache. > But, with the donation to ASF, > "FreeMarker" is the trademark of the ASF. > Well... I've seen this claimed, and one would assume it's true. But a few years ago, I was trying to see whether there really was a trademark registered. I don't really know much about these sorts of issues, but there are these database lookups you can do online and I could never find any proof that ASF really registered the trademark. Well, maybe they did. I honestly don't know. But, hey, it costs money to register a trademark. So maybe they just figured they could save that money by just claiming that they registered it and never did. I mean, who's going to notice after all? LOL. But, you know, finally, I don't really care about this much. You see, sometimes, it takes me a while to figure out certain things, so it took a good while for it to dawn on me that the whole idea that I'm in some breach of contract with ASF by using the name FreeMarker... it's a very dubious idea. Even at the risk of playing lawyer, let me explain my thinking about this. A contract between two parties is when one party promises something in exchange for the other party providing something. So you sell your house and the buyer gives you X money and you give them the house and the contract makes explicit certain things about whatever, like what date you'll vacate the premises and that you are providing them the house with no "lien", A mortgage in this case. Things like this, right? If I just tell you that I'm giving you my house in exchange for *absolutely nothing*, that's not really a contract. Certainly, not in British Common Law. Actually, you'll notice if you study your history that these very unequal treaties imposed on Indian tribes or what was imposed on Mexico after the Mexican-American war, there is actually some quid pro quo. Like, even after defeating the Mexicans thoroughly in the war, they did not take California and Texas etcetera for nothing. They paid (probably a symbolic amount admittedly) for these territories. The same applies to the Brits taking over Hong Kong after whatever "Opium War". In British common law, there has to be "consideration" for something to be a contract. I honestly don't remember what I signed back then (I think around 2014.) Possibly I did promise that I wasn't going to use the name "FreeMarker" but I'm not sure, because, to be honest, I probably didn't even read it. But the fact remains that if I promise something in exchange for ABSOLUTELY NOTHING, it's very hard to see how I am in any breach of contract, because there never really was a binding contract. If ASF had given me some derisory symbolic amount, like a hundred dollars or something, one might think they had a bit more of a case, but when there is ZERO "consideration" in the so-called "contract" I honestly just don't see it. So, my intuition is that any legal case that ASF tried to bring against me would have a very very flimsy basis. I actually doubt they'll even try. There's a lot of bluff in all this. ASF, frankly, is kind of a big edifice of flim-flam, which makes me suspect that they never even registered the trademark either! But do understand, that I don't even care hardly. The bottom line is that I'm just going to do whatever I do. You all might as well understand, sooner rather than later, that I don't recognize the authority of anybody here to tell me what I can or can't do. That way, you can save yourselves a lot of time and emotional energy. Thanks, Jon (See https://github.com/freemarker/freemarker3/wiki for information about FreeMarker 3. CongoCC parser generator: https://github.com/congo-cc/congo-parser-generator) > > On Sun, Nov 12, 2023 at 6:45 AM wrote: > > > Hi, Jonathan, > > > > First of all, I am disappointed to see all the personal attacks from you > > here. There is no cause of need for this. > > Let’s keep civilized. > > > > The major issue here I believe is that (at least in my perception) you > are > > trying to take the project out of Apache, > > but not following the rules for doing so (are there rules?). > > > > You can’t have your cake and eat it too. IMHO you can’t call it Apache > > Freemarker and not follow Apache rules.
Re: Long-Awaited FreeMarker 3 Preview Available
ker" and leave the SVN trunk abandoned. (Well, God knows and Daniel knows as well, but I get the feeling that neither of them are going to tell us why.) > > > For reasons that I can only speculate about, when Daniel Dekany took the > > FreeMarker code to Apache > > Instead, please focus on not blaming Daniel or me or anyone else here. > Well, why shouldn't I blame Daniel? The current mess was largely engineered by him. I suppose nobody should hold Daniel responsible for the utter stagnation of this project either. Well, he was the point man. Who is one to hold responsible? But, actually, in terms of blaming anybody, I do largely blame myself. I didn't have to agree to this "Apache FreeMarker" travesty. It was really just a moment of personal weakness. You see, I go around naively thinking that I can be friends with people and I attribute a higher quality to people than should be attributed to them. And I figured that if I blocked the move to ASF, I was maybe setting myself up to be portrayed as a villain or something. But also, I didn't foresee ever wanting to resume work on the thing. I thought that it belonged to some earlier phase of my life. At that point, I hadn't touched a line of code on it in 5 years at least. The reason I ended up resuming work on FreeMarker was because I resumed work on the parser generator that I was working on, that started as a fork of JavaCC. (Now called CongoCC.) I put some significant work into improving FreeMarker to support my work on that. And now it's certainly at a point where the amount of improvement is so great that it really would be a pity if it wasn't available to more people. So that's what all this is about really. But again, there is this whole problem with my naivete. You see, I actually think that, at root, this open source software development, is about doing something useful. And I realize that other people aren't exactly hung up on that concept. Now, I don't say that people shouldn't use open source as a self-promotion platform and all that. But this kind of cynical approach, where you're sitting on something totally obsolete and inferior with no real capacity to do much with it, and then when somebody, like in my case, wants to do something meaningful, you're going to do every passive-aggressive trick in the book to undermine that person. Well, so be it. But I would really like to think that I can make it clear to anybody observing this what is really going on here. -- Jonathan Revusky > - Ben > > > On Fri, 10 Nov 2023, 02:51 Jonathan Revusky, wrote: > > > On Thu, Nov 9, 2023 at 9:00 PM Benjamin Marwell > > wrote: > > > > > I never knew there was an "original" freemarker project. > > > > > > > So you actually thought that FreeMarker was developed at Apache? > > > > Well, no. FreeMarker is a very very old project at this point. > FreeMarker 1 > > was originally written by a guy named Benjamin Geer, in the late 90's. > > Though Ben Geer was, strictly speaking, the original author, I don't > think > > he was really involved in the project for very long. He wasn't involved > > when I showed up in the community in late 2001 anyway. At that point, I > > basically took over, and within a few months, the thing was a complete > > rewrite. And that was when FreeMarker 2.0 came into being. From 2002 to > > 2004/2005 we went through 4 release cycles, 2.0, 2.1, 2.2, and 2.3. Each > > release cycle added quite a bit more functionality. It is kinda sad that > > there is just about no meaningful difference between 2023 "Apache > > FreeMarker" and FreeMarker 2.3 from 2005 (or even late 2004). > > > > But the thing to understand is that this Apache FreeMarker code, the > > continuation of the FreeMarker 2.3 codebase, is really something very > > ancient. Most of the work on this was done in the period from 2002 to > 2005 > > or so, about a decade before there was any "Apache FreeMarker". > Basically, > > the project was very old and stagnant at that point and came to Apache to > > die, I guess. So I've decided to resuscitate it. Or give it my best > shot... > > > > > > > Your web site is down, the documentation on the GitHub project is > sparse. > > > > > > > That is true at the moment but is all quite remediable -- especially if > > some people want to get involved and do some heavy lifting. (I get the > > feeling that's not you!) In any case, I said quite clearly that this is a > > preview. You can't expect something that is a preview to be as polished > as > > something as old as FreeMarker 2.3, which has been pretty stable since > 2004 > &
Re: Long-Awaited FreeMarker 3 Preview Available
#exec myList::add(1, "foo") #-- Look, ma! No brackets! And then your list contains [1, "foo", 2, 3] (Not that I'm even saying that the above is necessarily such a great usage pattern, but my point is that things are simpler because you're just dealing with POJOs finally. If you want to do that, you can because this is just a plain old Java object!) And the same thing applies to maps. The old bugaboo that the map's keys have to be strings and the various workarounds. That's gone. The maps are just Map not Map (WTF is a TemplateModel anyway??!! LOL). So this refactored cleaned up version is much easier to work with really. But, you know, that said, all this overly complicated wrapping/unwrapping was implemented in a (kind of intricate) way that was mostly transparent to most users, so many people might not notice that this whole mess is cleaned up. Because they're unaware of the whole mess! It's a funny situation actually. But if you're a "power user" you'll surely notice that the whole thing is much cleaner now! > 2. What does it brings? > Well, like I said, you can consult the page that I put up recently. There are significant improvements. I think the terse syntax (even though that is actually technically superficial really) is quite an improvement and most anybody who has to spend much time editing templates will appreciate that. (All the more so once I can convince some tool makers to start providing some syntax highlighting at least! That, by the way, could be an easy way into the project because it's quite low-hanging fruit, I think.) > 3. What are the pros and cons of each version? > Well, the 2.3 codebase that is what "Apache FreeMarker" is, that's more "stable", sure. But that's a temporary situation. One thing is that the one activity that took place over the last so many years is that a lot of built-ins were added that never were in the 2.4 codebase. There are dozens of built-ins that are present in Apache FreeMarker that I haven't implemented. (Yet.) The approach I'm going to take, I think, is that I'm not going to make much of an active effort to implement every last missing built-in, but if people show up and say that they really miss a given one, and it's not terribly hard to add, I'll add it. Perhaps, in short order, FreeMarker 3 will have some built-ins that FreeMarker 2.x does not have. And the other thing is that, since the objects on the template layer are now pretty much all POJOs (plain old java objects) it is very very much easier to implement builtins than it ever was before, since you no longer need all this abstruse wrapping/unwrapping, so > 4. etc. > > I guess that's not easy questions to answer to (4 being somehow a joke ;), > but they are fundamental. > Well, they aren't such fundamental questions really, Jacques. The more advanced version is simply more advanced. Python 3 is simply more advanced than Python 2. JDK 8 is simply more advanced than JDK 7. And people will be better off using the more advanced version. You can get into a lot of sophistry trying to make the case that the less advanced version is somehow better and all that, but really, I wouldn't even care to engage much in such a conversation. So, to answer your question, it is dubious that a mature project that uses FreeMarker and has a big investment in macro libraries and so on, would opt to update at this point in time. But I would say that a new project really would be doing themselves a favor using the newer version of FreeMarker. It's just comparatively much more of a pleasure to use. I mean, for example, just take a look at the newer terse syntax. https://github.com/freemarker/freemarker3/wiki/Terse-Syntax Maybe it's not an absolute must-have, but it's clearly better, isn't it? And, in any case, it's optional anyway. The older syntax(es) still work. And the newer #set/#var is simply better than #assign/#local. In fact, that is on the FreeMarker 3 wish list that this community (Daniel, obviously...) put up. So nobody is contesting that #set/#var is better. Maybe you don't know about it, but read here and make your own judgment: https://github.com/freemarker/freemarker3/wiki/Strict-Vars But the other thing is that this is a moving target. The FreeMarker 2.3 codebase (which is what "Apache FreeMarker" is) is basically stagnant. If you commit to that in preference to the actively developed version, you are basically cutting yourself off from all the improvements that are going be coming along. The code has been cleaned up to such an extent that things that were very hard to do with the older FreeMarker code are very easy to implement now. As an actively developed project to get involved in, well, obviously FreeMarker 3 is where it is at. Anyway, that's enough said for now. Look,
Re: Long-Awaited FreeMarker 3 Preview Available
hatever. It would be a bit nicer if we had congocc without the hyphen, but it's hardly a sine qua non either. Well, anyway, look, we're not acquainted, but I find this quite off-putting. You have the possibility of raising whatever technical issue, making suggestions, giving feedback, and instead, you just come up with this flagrant nonsense about not being able to put up things on Maven Central (of course we can! LOL) or how it is so controversial that the more advanced version of the codebase actually is more advanced (Of course it is! LOL) or that some links being broken or the documentation being patchy is somehow a permanent state of affairs... (Of course it's not!) Well, anyway, I felt I had to answer this, but if you spout more nonsense like this, I think I will just refrain from answering. In the past, I have got into these annoying arguments with people because they got under my skin with this kind of stuff, but I suppose it's time to live and learn, eh? Jon > > - Ben > > Am Do., 9. Nov. 2023 um 18:40 Uhr schrieb Taher Alkhateeb > : > > > > > > I'm a little confused. Why aren't we joining efforts on the apache > version? Why make it "a pity if a wider group of > > people never get the benefit of this work"? Am I missing something too > obvious or too old or something? Is this code base completely incompatible? > Is this a technical issue? > > > > Taher Alkhateeb > > > > On Wednesday, November 08, 2023 04:03 +03, Jonathan Revusky < > revu...@gmail.com> wrote: > > Greetings, > > > > I thought to let people know that there is a vastly more advanced version > > of FreeMarker available here: https://github.com/freemarker/freemarker3 > > > > You can build it via: > > > > git clone https://github.com/freemarker/freemarker3.git > > cd freemarker3 > > ant > > > > Or, if you want, there is a prebuilt jarfile you can grab here: > > https://parsers.org/download/freemarker.jar > > > > Though it is actually a rather superficial new feature, I think that one > > thing that people will enjoy is the new terser syntax. Basically, if a > > directive starts a line (aside from whitespace) there is no need for any > > pointy (or square) brackets. So you can just write: > > > > #if foo == bar > > blah blah > > /#if > > > > You can look here for a more complete description: > > https://github.com/freemarker/freemarker3/wiki/Terse-Syntax and here is > an > > example of a template from the old test suite rewritten using the terser > > syntax: > > > https://github.com/freemarker/freemarker3/blob/master/src/freemarker/testcase/template/test-switch.html > > > > In this version of FreeMarker, the #assign and #local directives (though > > they still work in a backward-compatible mode) were replaced with the > newer > > #var and #set. This is (IMHO) a significant improvement and is described > > here: https://github.com/freemarker/freemarker3/wiki/Strict-Vars > > > > Just generally speaking though, the biggest changes are really under the > > hood and would not be so visible to the casual user. This FreeMarker > > codebase has been refactored so that it largely does away with all of > those > > TemplateXXXModel wrappers and mostly just directly uses POJOs. (Plain Old > > Java Objects.) This is described here: > > https://github.com/freemarker/freemarker3/wiki/Under-the-Hood > > > > Various longstanding annoyances, like not being able to directly use a > map > > with non-string keys, have been addressed. > > > > Oh, it suddenly occurs to me that many (perhaps most) people on this > > mailing list do not know who I am. I am effectively the original author > of > > FreeMarker. I say "effectively" because there was a FreeMarker 1.x, which > > was really little more than a weekend hack. The version that 99% of > > FreeMarker users have used, which is 2.x, was a complete rewrite and is > > largely my work. > > > > As for other questions about what is going on with this, for example, > why I > > have put some renewed effort into FreeMarker after all years... well, my > > main open source efforts have been going into my rewrite of that old > JavaCC > > parser generator that FreeMarker 2.x was originally built with. The new > > version of JavaCC was originally called FreeCC, then when I resuscitated > it > > a few years ago, I called it JavaCC 21, but it is now rebranded as > CongoCC. > > So, since FreeMarker is a key part of CongoCC, I found myself adding the > > occasional new feature to FreeMarker (my own version
Re: Long-Awaited FreeMarker 3 Preview Available
nderstand how I perceive this situation, you would do well to read that.). So, if there are people lurking who are sick of all the nothingburger-ism and want to get involved in some real software development, by all means, drop me a note or start a conversation here: https://github.com/freemarker/freemarker3/discussions I hope the foregoing clears up some of your (understandable) confusion about the situation. Best Regards, Jonathan Revusky > > Taher Alkhateeb > > On Wednesday, November 08, 2023 04:03 +03, Jonathan Revusky < > revu...@gmail.com> wrote: > Greetings, > > I thought to let people know that there is a vastly more advanced version > of FreeMarker available here: https://github.com/freemarker/freemarker3 > > You can build it via: > > git clone https://github.com/freemarker/freemarker3.git > cd freemarker3 > ant > > Or, if you want, there is a prebuilt jarfile you can grab here: > https://parsers.org/download/freemarker.jar > > Though it is actually a rather superficial new feature, I think that one > thing that people will enjoy is the new terser syntax. Basically, if a > directive starts a line (aside from whitespace) there is no need for any > pointy (or square) brackets. So you can just write: > > #if foo == bar > blah blah > /#if > > You can look here for a more complete description: > https://github.com/freemarker/freemarker3/wiki/Terse-Syntax and here is an > example of a template from the old test suite rewritten using the terser > syntax: > > https://github.com/freemarker/freemarker3/blob/master/src/freemarker/testcase/template/test-switch.html > > In this version of FreeMarker, the #assign and #local directives (though > they still work in a backward-compatible mode) were replaced with the newer > #var and #set. This is (IMHO) a significant improvement and is described > here: https://github.com/freemarker/freemarker3/wiki/Strict-Vars > > Just generally speaking though, the biggest changes are really under the > hood and would not be so visible to the casual user. This FreeMarker > codebase has been refactored so that it largely does away with all of those > TemplateXXXModel wrappers and mostly just directly uses POJOs. (Plain Old > Java Objects.) This is described here: > https://github.com/freemarker/freemarker3/wiki/Under-the-Hood > > Various longstanding annoyances, like not being able to directly use a map > with non-string keys, have been addressed. > > Oh, it suddenly occurs to me that many (perhaps most) people on this > mailing list do not know who I am. I am effectively the original author of > FreeMarker. I say "effectively" because there was a FreeMarker 1.x, which > was really little more than a weekend hack. The version that 99% of > FreeMarker users have used, which is 2.x, was a complete rewrite and is > largely my work. > > As for other questions about what is going on with this, for example, why I > have put some renewed effort into FreeMarker after all years... well, my > main open source efforts have been going into my rewrite of that old JavaCC > parser generator that FreeMarker 2.x was originally built with. The new > version of JavaCC was originally called FreeCC, then when I resuscitated it > a few years ago, I called it JavaCC 21, but it is now rebranded as CongoCC. > So, since FreeMarker is a key part of CongoCC, I found myself adding the > occasional new feature to FreeMarker (my own version, not Apache > FreeMarker). For example, the feature described here > https://github.com/freemarker/freemarker3/wiki/Macros-as-Functions was > added to support CongoCC development back in 2020, but probably a lot of > FreeMarker users would appreciate this. > > So, at some point, I did rework FreeMarker to use CongoCC instead of the > legacy JavaCC. CongoCC is a much, much more powerful parser generator than > the original JavaCC, so it makes FreeMarker development comparatively a > breeze. For example, I quite recently implemented assertions in FreeMarker > and this is where it is implemented: > > https://github.com/freemarker/freemarker3/blob/master/src/parser/Directives.inc.ccc#L417-L445 > > Or here is where ternary expressions are implemented: > > https://github.com/freemarker/freemarker3/blob/master/src/parser/Expressions.inc.ccc#L98-L118 > You really should compare the FreeMarker grammar expressed with CongoCC to > the one that was written with legacy JavaCC, that is here: > https://github.com/apache/freemarker/blob/2.3-gae/src/main/javacc/FTL.jj > > So I rewrote FreeMarker (it is largely a rewrite at this point) to: (a) > have a better tool for CongoCC development and (b) to provide a showcase > for CongoCC's capabilities. > > As for my plans, well, I do think it would be
Long-Awaited FreeMarker 3 Preview Available
Greetings, I thought to let people know that there is a vastly more advanced version of FreeMarker available here: https://github.com/freemarker/freemarker3 You can build it via: git clone https://github.com/freemarker/freemarker3.git cd freemarker3 ant Or, if you want, there is a prebuilt jarfile you can grab here: https://parsers.org/download/freemarker.jar Though it is actually a rather superficial new feature, I think that one thing that people will enjoy is the new terser syntax. Basically, if a directive starts a line (aside from whitespace) there is no need for any pointy (or square) brackets. So you can just write: #if foo == bar blah blah /#if You can look here for a more complete description: https://github.com/freemarker/freemarker3/wiki/Terse-Syntax and here is an example of a template from the old test suite rewritten using the terser syntax: https://github.com/freemarker/freemarker3/blob/master/src/freemarker/testcase/template/test-switch.html In this version of FreeMarker, the #assign and #local directives (though they still work in a backward-compatible mode) were replaced with the newer #var and #set. This is (IMHO) a significant improvement and is described here: https://github.com/freemarker/freemarker3/wiki/Strict-Vars Just generally speaking though, the biggest changes are really under the hood and would not be so visible to the casual user. This FreeMarker codebase has been refactored so that it largely does away with all of those TemplateXXXModel wrappers and mostly just directly uses POJOs. (Plain Old Java Objects.) This is described here: https://github.com/freemarker/freemarker3/wiki/Under-the-Hood Various longstanding annoyances, like not being able to directly use a map with non-string keys, have been addressed. Oh, it suddenly occurs to me that many (perhaps most) people on this mailing list do not know who I am. I am effectively the original author of FreeMarker. I say "effectively" because there was a FreeMarker 1.x, which was really little more than a weekend hack. The version that 99% of FreeMarker users have used, which is 2.x, was a complete rewrite and is largely my work. As for other questions about what is going on with this, for example, why I have put some renewed effort into FreeMarker after all years... well, my main open source efforts have been going into my rewrite of that old JavaCC parser generator that FreeMarker 2.x was originally built with. The new version of JavaCC was originally called FreeCC, then when I resuscitated it a few years ago, I called it JavaCC 21, but it is now rebranded as CongoCC. So, since FreeMarker is a key part of CongoCC, I found myself adding the occasional new feature to FreeMarker (my own version, not Apache FreeMarker). For example, the feature described here https://github.com/freemarker/freemarker3/wiki/Macros-as-Functions was added to support CongoCC development back in 2020, but probably a lot of FreeMarker users would appreciate this. So, at some point, I did rework FreeMarker to use CongoCC instead of the legacy JavaCC. CongoCC is a much, much more powerful parser generator than the original JavaCC, so it makes FreeMarker development comparatively a breeze. For example, I quite recently implemented assertions in FreeMarker and this is where it is implemented: https://github.com/freemarker/freemarker3/blob/master/src/parser/Directives.inc.ccc#L417-L445 Or here is where ternary expressions are implemented: https://github.com/freemarker/freemarker3/blob/master/src/parser/Expressions.inc.ccc#L98-L118 You really should compare the FreeMarker grammar expressed with CongoCC to the one that was written with legacy JavaCC, that is here: https://github.com/apache/freemarker/blob/2.3-gae/src/main/javacc/FTL.jj So I rewrote FreeMarker (it is largely a rewrite at this point) to: (a) have a better tool for CongoCC development and (b) to provide a showcase for CongoCC's capabilities. As for my plans, well, I do think it would be a pity if a wider group of people never get the benefit of this work. Whether I intend to call this version of FreeMarker "FreeMarker 3" or rename it to "Congo Templates", I still haven't decided about that. I really only put some serious effort into the FreeMarker codebase starting this summer and the work kind of took on a life of its own. In any case, anybody who is interested in getting involved, by all means. Maybe start a discussion here: https://github.com/freemarker/freemarker3/discussions Best Regards and Greetings from Spain, Jonathan Revusky
Blast from the Past, FreeCC Parser Generator
Hi all. I don't know offhand how many of the people receiving this email know who I am. For those of you who don't, I was quite heavily involved with the FreeMarker project from some point in late 2001 to late 2008 or so. About 7 years. I was the original author of the first JavaCC grammar for FreeMarker. Before that, it was a hand-written parser. As a result of that, and the evolution of FreeMarker, I became quite a JavaCC power user and eventually I did a lot of work on JavaCC, which I tried to donate to that project. Well, they basically refused to look at my work, so I ended up forking it and I labeled that as FreeCC. Well, also, recently, I was trying to take a look at what was going on here and I noticed that the whole subject of parser generators came up -- this is a couple of years ago now, and nobody seemed to even know that FreeCC existed. Well, it was kind of abandoned and the only place to find it would have been on its archived Google Code site, which is still there. https://code.google.com/archive/p/freecc/ Of course, Google Code is basically defunct, so the first step to resuscitating the project was to put it on Github, which I did just yesterday. Here: https://github.com/revusky/freecc If you want to get your hands on it and play with it, that is quite easy. It is simply: git clone https://github.com/revusky/freecc.git There are freecc and freecc.bat launchers that run straight out of the box since there is a "bootstrap" freecc.jar file, which is needed to do a build of freecc! To do a build is really easy. After checking it out, it's just cd freecc ant That builds a freecc.jar in the root directory that the launchers use in preference to the one in bin (if it is there, obviously...) You can run the test cases such as they are with: ant test and generate some (rather limited) docs with ant docs In the examples, there is an example grammar for FreeMarker which I had actually intended to be the basis of the grammar in newer versions of FreeMarker. You can also eyeball those files here: https://github.com/revusky/freecc/tree/master/examples/freemarker Note how the FreeMarker grammar is broken into two files, FTL.freecc and FEL.freecc. The first is the grammar for directives while the second file is just for expressions, FEL being FreeMarker Expression Language. In fact, it would be fairly simple to have separate builds in which you swap in and out different FEL.freecc files and have alternative syntax for expressions. (I don't know how useful that is, but it is nifty and it is something that is, to all intents and purposes, not even possible with JavaCC, which is a much more inflexible and cumbersome tool.) I had originally thought that, having abandoned FreeCC for a decade, that the work had no value now, since there would be so much progress over that time, but actually, I look at this, and see that, surprisingly, FreeCC could still be pretty useful, so I thought to try get it to a 1.0 release level. Over the last few days, I've been updating the included Java grammar to handle more modern constructs. It now handles the newer try-catch blocks, the double colon :: operator, but I still haven't implemented the lambda expression syntax. But I intend to. I ran the java parser over the entire freemarker codebase and it fails on 2 files, precisely because those are the two that use lambda expressions. Also, I fixed a couple of bugs that had been in the GoogleCode bug tracker for like 11 years. FreeCC in its very core algorithmically is the same as JavaCC, but since it uses FreeMarker templates to generate the code, it is actually far more configurable and flexible than JavaCC. You can get an idea of the new (actually, not so new features at this point!) from these Wiki posts I wrote about 11 years ago. https://code.google.com/archive/p/freecc/wikis I had the beginnings of a tutorial written about 11 years ago. I put that up right here: https://revusky.com/freecc/docs/ Well, the whole thing has quite a bit of potential, and it is a very good example of how FreeMarker can be used outside the web space, for code generation. It is quite striking to compare FreeCC's code with JavaCC and see how much more tersely and cleanly the whole thing is expressed using FreeMarker templates to generate the code of the parsers rather than the println statements approach used by JavaCC. Well, I write this hoping that some people could really get interested in this. You might or might not, but it is easy to check out the project and play with it. There are some very old examples that are from JavaCC and then some examples I added. In particular, the included FTL.freecc and FEL.freecc are quite worthy of study, in particular, if you are interested in reworking FreeMarker. I'll close the note here. Best Regards, Jonathan Revusky
