Re: Ideal tag syntax; what's your take on it?

Thursday, June 9, 2011, 8:36:24 PM, Michael Cervenak Ahern wrote:

> Hi Daniel,
>
> Still nicer than JSP though ...    What follows is a bit of a stream of consciousnesses  but...
>
> I guess thought-wise I'd take one of two approaches - make it more
> SGML friendly and maybe end up with GXP or align it to work more like a programming language.
>
> I'd prefer the latter option

(Me too, BTW. Especially as I have always found SGML/XML horribly
verbose for anything but describing documents. Maybe even for that...
Anyway, due to its popularity, a Java-ish/Groovy-ish syntax is
certainly a good bet.)

> (and here is where I'd have to sketch
> it out on paper and get back to you).  Syntax wise I'd probably shoot for something LISP like?
>
> [#if {condition} [
>    ...  
> ]]
>
> And for a directive:
>
> [@my-directive [= a b] [= x y] {arg} [
>
> ]]

Out of curiosity, do you have LISP background? Personally, I like to
avoid all kind of parentheses ((), [], {}) nested into each-other,
especially the same kind of parentheses nested into each-other
([[][]]). They confuse my eyes... But in a template languages you
possibly can't avoid them for separating the static text from the
"tags". They are quite nice for that actually. But that's just a
reason to avoid them even more *inside* the tags. For me, that is. In
principle I should do some kind of survey to know what's easy to read
for people...

> I am certain this syntax is broken in many trivial examples.  One
> nice feature though, is that nested statements look good (if you like lots of brackets):
>
> [@if [@directive {arg}, [@directive2], {arg}] [
>
> ]]

That's one aspect of LISP that I embrace... unify all the
function-like concepts. FreeMarker has directives VS functions. Or
technically, macros VS functions VS methods VS TemlpateDirectoveModel
VS transforms... horrible historical baggage.

However, using the same call syntax both inside and outside the tags
turns out to be problematic. Technically it's possible, even nice. But
the syntax of the top-level function calls (or directive calls, tags,
whatever) is optimized visually to stand out in the middle of the
messy static text. That's why an outer [...] is good there; it
visually cuts out the dynamic part from the rest. But inside the tag,
for me at least, it doesn't work very well, because it makes harder to
see where the outer tag ends. I mean, if you want to see where tags
start and where the end, you just hunt for "["-s and then for the
closest "]" after it. But if there tend to be [...]-s inside and hence
"]"-s... I still manage to find the matching "]", but it's somehow
more exhausting, slower. But maybe it's just my brain.

<OT>You can guess from there that LISP syntax is not for me. For me,
it's like a strange game where the computer repeatedly proves that it
can match parentheses better than me. Not only that... it also forces
me to satisfy its fetish for properly paired parentheses. Really, I
don't see difference between the correct and the wrong version, so
only the compiler needs this... :) With other words, I have found that
if something is very much generalized, while it's theoretically
powerful, it becomes kind of monoton and hard to digest for the human
brain.<OT>

> Just a crazy thought if you could fix the broken handling of that text block...
>
> -Mike
>
> On Tue, Jun 7, 2011 at 6:46 PM, Daniel Dekany <[email protected]> wrote:
> Ignore backward compatibility for a moment. What would *you* prefer?
> Or if you have no idea, what aspects of the current syntax bothers you
> the most in every day work?
>
>
> A bit of mussing from me (if you care)... The most modern form of
> FreeMarker syntax is like this:
>
>  [#assign x = 1]
>  [#if something]...[/#if]
>  [@myDirective]...[/@myDirective]
>  [@myOtherDirective /]
>
> Despite that the documentation doesn't push thins syntax at all, it
> has become very popular. That tells something.
>
> My personal(?) problem with the current situation is that while FTL
> (FreeMarker Template Language) has lost a lot from its SGML-ishness
> (HTML-isness) during its history, it kept some of the not-so-good
> things from it. So I'm afraid we have ended up with a mix that's too
> far from the ideal. Let's see:
>
> How FTL is not SGML:
>
> - For starters, the attribute syntax was never like in SGML or XML.
>  This is the cause of the most frequent mistake, where people try to
>  write <@foo x="${x}" /> instead of <@foo x=x />
>
> - 2.3 introduced those odd prefixes, "#" and "@" (instead of using
>  XML-ish name-space prefixes). I don't mind this in itself, not at
>  all. It's just not SGML-ish.
>
> - And now it doesn't even use <...>, but [...].
>
> How FTL is still similar to SGML:
>
> - You have to add a "/" to each empty-directive tag ([@foo /]), but
>  you don't have to add anything if nested content follows
>  ([@foo]...). Isn't that anti-intuitive and often inconvenient?
>  Nothing but SGML has this strange upside-down logic (I think).
>
>  Also, to complicate things... there are those who are more equal
>  than others. For a built-in directive you can write something like
>  [#assign x = 1] instead of [#assign x = 1 /], since FreeMarker knows
>  if they can have nested content or not.
>
> - You don't have to put comma between named arguments. In SGML you
>  have to quote non-trivial attribute values, so it isn't an issue
>  there, but I don't think any sane modern *programming* language
>  would do this with named arguments. [@foo x = a + 1 y = b + 1] is
>  just horrible. Luckily, you can write [@foo x = a + 1, y = b + 1] in
>  FTL, but you don't have to. (As a side note, we also have
>  ambiguities because of this: <@foo x = a! y = 2> will be parsed as
>  <@foo x = a!(y == 2)>. Yeah, part of this is that FTL allows "="
>  instead of "==". That was a mistake too...)
>
> --
> Best regards,
>  Daniel Dekany
>
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> FreeMarker-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/freemarker-user
>

-- 
Best regards,
 Daniel Dekany


------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev