[stringtemplate-interest] "Or" and "And" operators in conditionnal always evaluate both operands ?

[Udo Borkowski]

> The point is this is entirely an implementation detail. There's no benefit
> to documenting the semantics in a short circuit manner ...

Right. I was talking about the implementation. I don't care, if this is externally documented. I was just surprised to read the current implementation does not use a short circuit implementation. 

Udo

On 15.09.2011, at 18:33, Sam Harwell wrote:

> The point is this is entirely an implementation detail. There's no benefit
> to documenting the semantics in a short circuit manner because that behavior
> is only semantically relevant in a language where expression evaluation can
> have side effects and/or null references can occur, neither of which applies
> to StringTemplate.
> 
> Sam
> 
> -----Original Message-----
> From: stringtemplate-interest-bounces at antlr.org
> [mailto:stringtemplate-interest-bounces at antlr.org] On Behalf Of Udo
> Borkowski
> Sent: Thursday, September 15, 2011 10:02 AM
> To: Sam Barnett-Cormack
> Cc: stringtemplate-interest List; Damien Urruty
> Subject: Re: [stringtemplate-interest] "Or" and "And" operators in
> conditionnal always evaluate both operands ?
> 
>> The usual pattern in most languages I've experiences is to 'short 
>> circuit' conditionals in this way - for &&, don't bother with the 
>> second if the first is false, for ||, don't bother if it's true. This 
>> has great behavioural effects widely used in languages like perl, but 
>> those don't really apply to ST that I can see.
> 
> Because ST has no side effects I would argue it is very reasonable to assume
> && and || are implemented in the "short circuit" way. Why should ST execute
> code that does not have any effect? 
> 
> If there is no strong argument against an "short circuit" implementation I
> suggest to change it to the "lazy" style. 
> 
> This will have no effect on the output but just run (a little bit) faster in
> some cases. So it should be a safe and compatible change.
> 
> Udo
> 
> 
> On 15.09.2011, at 16:01, Sam Barnett-Cormack wrote:
> 
>> The usual pattern in most languages I've experiences is to 'short 
>> circuit' conditionals in this way - for &&, don't bother with the 
>> second if the first is false, for ||, don't bother if it's true. This 
>> has great behavioural effects widely used in languages like perl, but 
>> those don't really apply to ST that I can see.
>> 
>> However, the specific case you identify is a good one. If you're in a 
>> situation where it's not a 'bad usage' of your template to have 'a'
>> unset, you definitely want to be able to test members of a for truth 
>> or existence at the very least, without syntactic merry-go-rounds or 
>> risking very strange errors.
>> 
>> Then again, maybe short-circuit isn't the way to deal with this case. 
>> Maybe there's some better way of handling cases that would seem to 
>> lead to such functionality being disireable. Who knows?
>> 
>> Sam (not the usual Sam)
>> 
>> On 15/09/2011 14:54, Damien Urruty wrote:
>>> Hi,
>>> 
>>> The problem I am facing is that my conditional is something like :
>>> 
>>> <if(a && a.b)>
>>> 
>>> Which raises an error in the case a is null (a.b is still evaluated).
>>> 
>>> By the way, the error is not very explicit : "templateName : no such 
>>> property or can't access: null attribute". I spent some time finding 
>>> where the error came from.
>>> 
>>> It is not a question of performance, I was just wondering if this 
>>> behaviour was normal, I mean if this is by design, or if it was a bug.
>>> 
>>> In my case, I can easily break the if in two separate ifs, so it 
>>> doesn't really matter. But as in Java the && does not evaluate all 
>>> the operands if not necessary (the & operator do evaluate each 
>>> operand), i wanted to know if this behaviour was wanted or not.
>>> 
>>> Maybe this should be discussed, I know it is not very important, or 
>>> at least it should be mentionned somewhere in the doc ?
>>> 
>>> Thanks for your response Sam, have a nice day
>>> 
>>> ---------------------------------------------------------------------
>>> ---
>>> From: sharwell at pixelminegames.com
>>> To: lepilache at hotmail.com; stringtemplate-interest at antlr.org
>>> Subject: RE: [stringtemplate-interest] "Or" and "And" operators in 
>>> conditionnal always evaluate both operands ?
>>> Date: Thu, 15 Sep 2011 08:43:29 -0500
>>> 
>>> Hi Damien,
>>> 
>>> Since the attributes referenced from a StringTemplate should always 
>>> be pure (no side effects), then there is no semantic difference 
>>> between evaluating or not evaluating the second argument. Are you 
>>> facing a significant performance problem due to the second evaluation?
>>> 
>>> Sam
>>> 
>>> *From:*stringtemplate-interest-bounces at antlr.org
>>> [mailto:stringtemplate-interest-bounces at antlr.org] *On Behalf Of 
>>> *Damien Urruty
>>> *Sent:* Thursday, September 15, 2011 8:01 AM
>>> *To:* stringtemplate-interest at antlr.org
>>> *Subject:* [stringtemplate-interest] "Or" and "And" operators in 
>>> conditionnal always evaluate both operands ?
>>> 
>>> Hello,
>>> 
>>> I can see that if we use && and || operands in conditionnals, both 
>>> operands are always evaluated, even if not necessary. For exemple, I have
> :
>>> 
>>> <if(a && b)>
>>> 
>>> ...
>>> 
>>> <endif>
>>> 
>>> In my case, a is null, so it is not necessary to evaluate the second 
>>> argument, right ? Shouldn't the evaluation stop when such a case is 
>>> encountered ? It is the same for <if(a || b)> with a not null.
>>> 
>>> Maybe I miss something, thanks for your help.
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> stringtemplate-interest mailing list
>>> stringtemplate-interest at antlr.org
>>> http://www.antlr.org/mailman/listinfo/stringtemplate-interest
>> 
>> _______________________________________________
>> stringtemplate-interest mailing list
>> stringtemplate-interest at antlr.org
>> http://www.antlr.org/mailman/listinfo/stringtemplate-interest
> 
> _______________________________________________
> stringtemplate-interest mailing list
> stringtemplate-interest at antlr.org
> http://www.antlr.org/mailman/listinfo/stringtemplate-interest
>