Constrain use of 'delay' with zero delay time

[henrikt-ma]

This is a new take on #3245, picking up where it was left with the comment #3245 (comment). (I am revisiting this now because of my ongoing test implementation of delay with event generation.)

I think this solves the issue with an acceptable tradeoff between backwards compatibility and feasibility of actually implementing according to specification:

• As @MarkusOlssonModelon seems to have suggested in phone meeting, delayTime = 0 is forbidden for time-varying delayTime.
• In the two argument form delay(u, delayTime), the "new" evaluable variability is used to constrain delayTime, making it possible for tools to determine at translation time whether delayTime has been set to zero, but not forcing tools to evaluate.
• By allowing delayTime = 0 in the two argument form, we avoid the need to give complicated rules for when it is an error to have delayTime = 0 in guarded expressions such as if tau > 0 then delay(u, tau) else u.
• In principle, the funky technique of only evaluating delayTime when the value would be zero can be avoided by generating different equation systems for the two cases, and make an initialization time decision of which case to use. (Not expecting any tool to actually do it this way.)

[HansOlsson]

Hans:

• Should add QoI for run-time check.
• Would prefer that if parameter delayTime is non-evaluable it is still valid, but does not support delayTime=0.

[henrikt-ma]

Hans:

• Should add QoI for run-time check.
• Would prefer that if parameter delayTime is non-evaluable it is still valid, but does not support delayTime=0.

I have updated the text accordingly.

I think it would be good, though, to have a migration path for avoiding semantics depending on whether an expression is evaluable. It could be achieved with two deprecations:

• Deprecate the two argument form with non-evaluable delayTime.
• Deprecate allowing delayTime = 0 with the three argument form.

[HansOlsson]

Language meeting:
Seems an improvement to current work-around: if dt>0 then delay(x, dt) else x.

Has an implication for whether delay breaks algebraic loops; so decision must be made early (slightly complicated to not evaluate it if non-zero).

(Some people strongly want delay to be able to handle delay-time=0.)

[HansOlsson]

(Some people strongly want delay to be able to handle delay-time=0.)

I realized something: I only have second-hand reports that some people really want delay-time=0 and understand that it will not break algebraic loops (but instead be treated as if they delay wasn't present).

It would be good to have a confirmation of that, @casella

[HansOlsson]

I realized something: I only have second-hand reports that some people really want delay-time=0 and understand that it will not break algebraic loops (but instead be treated as if they delay wasn't present).

It would be good to have a confirmation of that, @casella

Pinging @casella (and others) in order to confirm the above, i.e., wanting delay-time=0 and not breaking algebraic loops.

[HansOlsson]

I realized something: I only have second-hand reports that some people really want delay-time=0 and understand that it will not break algebraic loops (but instead be treated as if they delay wasn't present).
It would be good to have a confirmation of that, @casella

Pinging @casella (and others) in order to confirm the above, i.e., wanting delay-time=0 and not breaking algebraic loops.

To me it is important to get confirmation for this; and not only 2nd hand reports.

The reason for stressing "not breaking algebraic loops" is that various forms of loop-breakers are common, and if the intent were to break algebraic loops, it doesn't make sense to add (somewhat complicated) semantics that doesn't handle that.

[HansOlsson]

Language group: the request is currently unclear - waiting for more information.