[stringtemplate-interest] whitespace in IF

[Terence Parr]

Hi. well, i'm am wondering if think of it as consistent with empty  
expressions:

<emptyexpression>

on a line by itself gets no newline. so, neither would if, else,  
endif.  Anything that evaluates to nothing on line by itself is a no  
op in terms of whitespace.

I looked at my templates and I NEVER use multiline templates to get a  
single line of output. I can image i would with a long chain of if- 
elseif but my ANTLR templates don't have this trait.  That would be  
lots of logic in the templates.

Technically, we could think of IF clauses not as templates but just  
more TEXT and EXPR chunks.  Only explicit templates like in

t() ::= <<
blort
 >>

would have whitespace removed.

With {x | foo} subtemplates, I'm ignoring whitespace after the pipe so  
you can format like:

{x |
foo
}

But, what about the \n after foo?  does that count?  if it's a  
template the no.  I'm conflicted about this.

In general, I can imagine not throwing out whitespace anymore.  It  
arose from template files that had no surrounding <<...>> or "...".   
That is no longer the case.  ALL templates are formal defs:

mytemplate(args) ::= <<
even if in a file
 >>

That way, a group file is literally the cat of template files in a dir  
(well, minus the group header).

So, we if want no newline we do

mytemplate(args) ::= <<
even if in a file>>

no starting newline:

mytemplate(args) ::= <<even if in a file
 >>

or

mytemplate(args) ::=
<<even if in a file
 >>

no newlines:

mytemplate(args) ::= <<even if in a file>>

Hmm...i might have just convinced myself to not scarf any newlines at  
all!  Only thing to scarf would be a single space char after pipe  
maybe in a subtemplate.

Thoughts?

Ter




On Nov 6, 2009, at 9:42 PM, Zenaan Harkness wrote:

> On Fri, Nov 06, 2009 at 06:11:33PM -0800, Terence Parr wrote:
>> ok, a related problem.   Is
>>
>> <if(x)>
>> foo
>> <else>
>> bar
>> <endif>
>>
>> same as
>>
>> <if(x)>foo<else>bar<endif>
>>
>> It's same in v3. I'm wondering if we want the \n after foo or bar.
>
> What will likely happen is complaints of inconsistency.
>
> Although right now it's not so 'clean' in certain circumstances,
> I have worked around most of that in my projects by subroutining
> my template group file templates, to clean things up visually "as
> much as possible".
>
> So right now we have consistency (first/last \n ignored), but
> sometimes messy template group files, and the proposal would
> mean (as far as I can tell) cleaner template group files, at the
> cost of a reduction in consistency of how templates work.
>
> Which is better?
>
> Already, the ignoring of boundary \n's in templates is a concession
> to readability, so there is certainly the precedent to introduce
> inconsistency in syntax, for the benefit of readbility.
>
> A thought: is it possible to have a slightly different syntax,
> to get clarity at the ST-code level of visual-vs-consistent output
> differences?
>
> Eg:
>
>   <if(x);>
>   foo
>   <else;>
>   bar
>   <endif>
>
> would mean 'sloppy syntax/ layout, to look pretty' and say:
>
>   <if(x):>
>   foo
>   <else:>
>   bar
>   <endif>
>
> would mean 'no, I really want all whitespace (spaces, tabs, \n's)
> inside the template to be part of the output, and of course:
>
>   <if(x)> foo
>   <else>
> bar
> <endif>
>
> would be the backwards-compatible version which is hard to remember,
> 'but generally does the right thing', and of course 'is backwards
> compatible' which I think is a really nice trait.
>
> As to characters and placement, perhaps ":" and ";" would clash with
> existing syntax - it's just examples, and anything that fits would be
> fine of course.
>
> best
> zen
>
> -- 
> Free Australia: www.UPMART.org
> Please respect the confidentiality of this email as sensibly  
> warranted.
> _______________________________________________
> stringtemplate-interest mailing list
> stringtemplate-interest at antlr.org
> http://www.antlr.org/mailman/listinfo/stringtemplate-interest