Re: Jinja2 syntax for conditionals

[Tristan Van Berkom <tristan vanberkom codethink co uk>]

Warning: This email may be straying a bit off topic...

On Tue, 2017-09-19 at 13:52 +0100, Sam Thursfield wrote:
> Thanks for the response here.
[...]

> That said the jury is still out on the general direction of this; you
> > seem to be after the exact opposite of what I'm looking for and I'm
> > trying to understand / balance the reasoning behind this:
> >
> >    Do we want something fully specified and very cute, with a rigid
> >    non-extensible syntax that other programmers may recognize because
> >    they might have used that syntax before ?
> >
> > Or
> >
> >    Do we only want a data serialization format that is a bit more
> >    practical than YAML is for the purpose of serializing optionally
> >    quoted strings and numbers ?
> > >    The exact same thing can be done with JSON or YAML, it just happens
> >
> >    to be practical to use S expressions for these one liners.
>
> I don't see this as the question at all. Either way we're adding logical 
> expressions to what was previously a serialization format, and making 
> something that is (a) a serialization format with syntax sugar for 
> variants, or (b) something else.

Probably late to reply this, and probably veering off topic, but I re-
read this while replying to Sander and feel that the above is an
inaccurate assessment.

We already stray from pure YAML in a couple of places for our
serialization, for instance we parse out urls expressed as aliases and
split on the ':' character. I dont think this causes the format to no
longer be a serialization format.

The existing 'arches' and 'variants' are logical expressions as much as
they would be if expressed a bit differently for the user's
convenience.

I think you are making a deep association of S-Expressions themselves
with the lisp programming language, while I on the other hand see them
as an merely an easy to parse, more structured and defined approach to
CSV (it sits somewhere in between CSV and JSON) - sending S-Expressions 
over a wire for instance is quite typical and I feel is akin to restful
JSON apis, these are just simple data serialization mechanisms, one of
which just happens to be used as a vehicle for some simple but turing
complete programming languages.

> Sure you can represent the syntax tree of the S-Expressions as a YAML 
> data structure, the same is true of the syntax tree of the Jinja2 
> expressions.

I find it curious that you choose the term "syntax tree" here to refer
to S-Expressions.

There is clearly an issue with perception here, but what I cannot put
my finger on, is whether or not this matter of perception bears any
relevance to the more practical discussion at hand.

Cheers,
    -Tristan