Indeed, Time.delay 0 signal
is not semantically equal to signal
. It’s not documented anywhere I am aware of. And probably it will not be documented anywhere, because it might encourage people to use delay
with 0
, which is bad. I would actually make it a runtime error to call delay
with 0
or a negative number (that runtime error could anyway only happen right at program start, so no surprises later on or after deployment). In practical terms, note that anything below 4
will anyway have indistinguishable effect. The implementation of delay
uses JavaScript’s setTimeout
, and if you google a bit about that method, you will find that even a setTimeout
with argument 0
will actually be performed as a setTimeout
with argument 4
.
--
You received this message because you are subscribed to the Google Groups "Elm Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
About calling delay
twice with the same number on the same signal: the resulting two signals will fire independently. The situation is like for Time.fps
and Time.every
. The first’s documentation has a sentence
Note: Calling
fps 30
twice gives two independently running timers.
The second’s has a sentence
Note: Calling
every 100
twice gives two independently running timers.
A similar sentence would be appropriate (and true) in the documentation of Time.delay
.
Correction: never thought about. Sorry.
delay 1
, i.e., using the least positive number, instead of 0
, which gives the wrong impression that there is no delay.Max, IMHO that shouldn’t be the responsibility of delay
with argument 0
, but with a dedicated async
function like is described in the original thesis on Elm.
--
Yes, I had just forgotten that time is not milliseconds as Int
, but rather as Float
. So with 1
I really meant the smallest positive number. Which of course 1
is not if we are dealing in Float
s.
It is not the case currently. Your s1
, s2
, s3
will be different signals. But the same is already the case for Time.every
and Time.fps
. And there it is noted in the documentation. If you have
s4 = Time.every 1000
s5 = Time.every 1000
then you cannot referentially transparently replace s4
for s5
(or for Time.every 1000
) in your code.
Okay, it's clearer how things are. Is this the way they should be? Will future compiler optimization passes have to take these special cases into account to avoid changing behavior unexpectedly, or should they be made referentially transparent at some point?
Yes, I guess that can be confusing. But it’s just the same as saying that delay
is not referentially transparent, which has already been observed in this thread.
There’s not much more that can be done about this (at the moment) than clearly documenting this.
To “solve” it, reliably and in all cases (for arbitrary expressions, rather than just trying to detect special cases with an explicit constant argument to delay
), something like global value numbering or hash consing might be needed. I would be surprised to see it implemented.
Further changing the implementations of the Time
primitives is not my call to make. :-)
But let me say I’m not convinced all the properties you expect are must-haves, or that not having them “ruins composability”. For example, that Signal.map (uncurry (-)) (timestamp (delay 1000 (every 1000)))
should be constantly 1000
. What is some real code or refactoring that breaks because of not satisfying this? Also concerning your composedSyncAnimation
example, the assertion that you cannot do something desirable there is difficult to judge without knowing more specifically how those animations are supposed to be implemented.
But, that said, I have myself in the past felt the need to improve consistency between timed and timestamped signals. (As you can see by looking at commit history from January, https://github.com/elm-lang/core/commits/master/src/Native/Time.js.) So maybe your ideas could also be implemented and make it into core
.
--
You received this message because you are subscribed to the Google Groups "Elm Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
About the issue of documentation/warnings:
Note that the next release of core
will come with this warning in the documentation of Time.delay
. (And the other functions showing similar non-pureness do already have corresponding warnings attached.)