New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add programStartTime to Time module #172

Closed
TheSeamau5 opened this Issue Feb 13, 2015 · 10 comments

Comments

Projects
None yet
5 participants
@TheSeamau5
Contributor

TheSeamau5 commented Feb 13, 2015

When working with random numbers, it's often inconvenient to have to go to Signal land because the seed has to be generated from a Signal (say, the current time). While this is certainly a necessary way of doing things, sometimes you don't want a stream of random seeds, you just want one, once, but you want it to be different each time you execute a program anew or refresh a page.

I recall hearing this idea somewhere in the mailing list before but I can't find where but the idea is to add a value called

programStartTime : Time

which is the time when main was called. Since there is only one such value, there is no need for it to be in a signal. This would simplify design by removing some of the needs for signals in programs (and thus further pushing effects to the edge).

(sorry if this idea was already proposed but I couldn't find it in the issue tracker)

@evancz

This comment has been minimized.

Show comment
Hide comment
@evancz

evancz Feb 13, 2015

Member

I've got some changes to Signal percolating that'd make this really easy and theoretically supported. This was a specific case I had in mind, specifically for randomness. So this should be in 0.15 with the promise stuff. Don't let me forget!

Member

evancz commented Feb 13, 2015

I've got some changes to Signal percolating that'd make this really easy and theoretically supported. This was a specific case I had in mind, specifically for randomness. So this should be in 0.15 with the promise stuff. Don't let me forget!

@TheSeamau5

This comment has been minimized.

Show comment
Hide comment
@TheSeamau5

TheSeamau5 Feb 13, 2015

Contributor

Cool! Sure thing, I'll remind you when the release approaches.

Contributor

TheSeamau5 commented Feb 13, 2015

Cool! Sure thing, I'll remind you when the release approaches.

@jvoigtlaender

This comment has been minimized.

Show comment
Hide comment
@jvoigtlaender

jvoigtlaender Feb 13, 2015

Contributor

Just for reference, there is a commit that adding such a constant here. It's in a branch I didn't create a PR from, since I expected it wouldn't be merged anyway.

An important aspect to take care of (and that's why I wrote that branch/commit, to see how a solution could look like) is that this supposed "constant" remains constant even over a hot-swap. Even after a hot-swap, you still want to return the time of the original program start, not the how-swap time. Otherwise, referential transparency is lost.

Contributor

jvoigtlaender commented Feb 13, 2015

Just for reference, there is a commit that adding such a constant here. It's in a branch I didn't create a PR from, since I expected it wouldn't be merged anyway.

An important aspect to take care of (and that's why I wrote that branch/commit, to see how a solution could look like) is that this supposed "constant" remains constant even over a hot-swap. Even after a hot-swap, you still want to return the time of the original program start, not the how-swap time. Otherwise, referential transparency is lost.

@TheSeamau5

This comment has been minimized.

Show comment
Hide comment
@TheSeamau5

TheSeamau5 Feb 13, 2015

Contributor

Yeah, the compiler might want to flag it in some way as "unhotswappable".

Contributor

TheSeamau5 commented Feb 13, 2015

Yeah, the compiler might want to flag it in some way as "unhotswappable".

@jvoigtlaender

This comment has been minimized.

Show comment
Hide comment
@jvoigtlaender

jvoigtlaender Feb 13, 2015

Contributor

Well, the commit I linked to does ensure that the program remains hotswappable. Even after a hotswap, still the original program start time is reported. Which is the semantically correct thing to do. All I was saying is that any way of introducing the requested feature should make sure to consider this issue. Mine does. :)

Contributor

jvoigtlaender commented Feb 13, 2015

Well, the commit I linked to does ensure that the program remains hotswappable. Even after a hotswap, still the original program start time is reported. Which is the semantically correct thing to do. All I was saying is that any way of introducing the requested feature should make sure to consider this issue. Mine does. :)

@TheSeamau5

This comment has been minimized.

Show comment
Hide comment
@TheSeamau5

TheSeamau5 Feb 13, 2015

Contributor

Cool! That's just music to my ears. I can't wait for this to be a thing in Elm.

Contributor

TheSeamau5 commented Feb 13, 2015

Cool! That's just music to my ears. I can't wait for this to be a thing in Elm.

@joshy

This comment has been minimized.

Show comment
Hide comment
@joshy

joshy Dec 17, 2015

Contributor

Any update on this? The documentation on the Random module says that in order to get a unexpected seed is to use the current time.

A good way to get an unexpected seed is to use the current time.
No code example is given how to get the current time with just the core libraries. If there is a easy way, I can make a pull request with an code example.

Contributor

joshy commented Dec 17, 2015

Any update on this? The documentation on the Random module says that in order to get a unexpected seed is to use the current time.

A good way to get an unexpected seed is to use the current time.
No code example is given how to get the current time with just the core libraries. If there is a easy way, I can make a pull request with an code example.

@jvoigtlaender

This comment has been minimized.

Show comment
Hide comment
@jvoigtlaender

jvoigtlaender Dec 17, 2015

Contributor

There's no way currently just using core. To get at the current time, an excurse to JavaScript is needed. Either explicitly by passing the time in through a port, or by using the Task API: http://package.elm-lang.org/packages/evancz/task-tutorial/1.0.3/TaskTutorial#getCurrentTime. (I think the latter is what Evan was referring to above.)

Contributor

jvoigtlaender commented Dec 17, 2015

There's no way currently just using core. To get at the current time, an excurse to JavaScript is needed. Either explicitly by passing the time in through a port, or by using the Task API: http://package.elm-lang.org/packages/evancz/task-tutorial/1.0.3/TaskTutorial#getCurrentTime. (I think the latter is what Evan was referring to above.)

@noahzgordon

This comment has been minimized.

Show comment
Hide comment
@noahzgordon

noahzgordon Jun 9, 2016

Contributor

I believe this is no longer relevant as of 0.17, because Time 4.x exposes now.

Contributor

noahzgordon commented Jun 9, 2016

I believe this is no longer relevant as of 0.17, because Time 4.x exposes now.

@evancz

This comment has been minimized.

Show comment
Hide comment
@evancz

evancz Jul 1, 2016

Member

I like that interpretation. We'll see if this gets requested again!

Member

evancz commented Jul 1, 2016

I like that interpretation. We'll see if this gets requested again!

@evancz evancz closed this Jul 1, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment