Should negative inputs to `every`, `fps`, `fpsWhen`, `delay` be forbidden?

[jvoigtlaender]

Yes, I think they should. It would be trivial and harmless to make them runtime errors. That would be in the same category like the runtime error one currently gets from calling mergeMany on an empty list. (That is, such runtime errors can only happen immediately at program start. So no sudden surprises.)

In addition to what's in the issue title, probably the value 0 should also be forbidden as argument at least for fps and fpsWhen. (It might effectively already be forbidden for those due to "division by zero".)

[TheSeamau5]

Or, we could clamp them to some logical minimum value (like 0 or 1 depending on the function) and make sure this behavior is clearly stated in the docs. This could eliminate the runtime errors there.

We could even go so far as to change the type of mergeMany to Signal a -> List (Signal a) -> Signal a to further eliminate the runtime errors there.

[TheSeamau5]

Or, we could clamp them to some logical minimum value (like 0 or 1 depending on the function) and make sure this behavior is clearly stated in the docs. This could eliminate the runtime errors there.

We could even go so far as to change the type of mergeMany to Signal a -> List (Signal a) -> Signal a to further eliminate the runtime errors there.

[jvoigtlaender]

I have reconsidered and think it would indeed be best to simply clamp the arguments to every, fps, fpsWhen and delay to some logical minimum value as suggested by @TheSeamau5. Making negative (or maybe even zero) values to them a runtime error could backfire like in https://github.com/elm-lang/core/issues/381#issuecomment-137169302.

[jvoigtlaender]

I have reconsidered and think it would indeed be best to simply clamp the arguments to every, fps, fpsWhen and delay to some logical minimum value as suggested by @TheSeamau5. Making negative (or maybe even zero) values to them a runtime error could backfire like in https://github.com/elm-lang/core/issues/381#issuecomment-137169302.