Move and/or rename `Process.sleep`?

[jvoigtlaender]

In a thread on the mailing list a user wanted this functionality but could not find it in core. After being pointed to it, two concerns were raised:

• It didn't occur to them to look for this in the Process module (would have expected it in Time).
• The name sleep does not feel right to them, given what sleep functions traditionally do (in other languages).

A concrete suggestion was Time.after instead of Process.sleep.

Maybe reasonable to add to meta issue https://github.com/elm-lang/core/issues/322?

[process-bot]

Thanks for the issue! Make sure it satisfies this checklist. My human colleagues will appreciate it!

Here is what to expect next, and if anyone wants to comment, keep these things in mind.

[process-bot]

Thanks for the issue! Make sure it satisfies this checklist. My human colleagues will appreciate it!

Here is what to expect next, and if anyone wants to comment, keep these things in mind.

[evancz]

In your opinion, or the opinion of the mailing list person, what does sleep traditionally do in other languages? Doesn't it make a thread sleep for a certain amount of time? If so, that's literally what it's doing here as well.

[evancz]

In your opinion, or the opinion of the mailing list person, what does sleep traditionally do in other languages? Doesn't it make a thread sleep for a certain amount of time? If so, that's literally what it's doing here as well.

[jvoigtlaender]

@nikoudel, you are probably in a better position to answer the above question.

[jvoigtlaender]

@nikoudel, you are probably in a better position to answer the above question.

[OvermindDL1]

Considering sleep waits an amount of time on a Process, then Process.sleep makes the most sense to me. If anything I would consider a Time.wait to return a task after a certain period of time or so, but as-is Process.sleep makes sense.

[OvermindDL1]

Considering sleep waits an amount of time on a Process, then Process.sleep makes the most sense to me. If anything I would consider a Time.wait to return a task after a certain period of time or so, but as-is Process.sleep makes sense.

[nikoudel]

As an Elm newcomer arriving from .NET world I was familiar with tasks so I was looking for something like Task.Delay. It was surprising to find Process.sleep in Elm because (coming also from Javascript world) I knew it's impossible to actually "sleep" (i.e. block a thread) in a browser. Process.sleep returns a task immediately, it doesn't really block a thread so it's not sleeping in a traditional meaning.

The word "sleep" in programming is quite a strong concept. It's a big red hammer, a real boogeyman to be afraid of because normally you're on the main thread and sleep stops the world for a while.

[nikoudel]

As an Elm newcomer arriving from .NET world I was familiar with tasks so I was looking for something like Task.Delay. It was surprising to find Process.sleep in Elm because (coming also from Javascript world) I knew it's impossible to actually "sleep" (i.e. block a thread) in a browser. Process.sleep returns a task immediately, it doesn't really block a thread so it's not sleeping in a traditional meaning.

The word "sleep" in programming is quite a strong concept. It's a big red hammer, a real boogeyman to be afraid of because normally you're on the main thread and sleep stops the world for a while.

[jvoigtlaender]

@OvermindDL1, but what is that "process" that is sent to sleep? If the user hasn't created any new process with Process.spawn, it must be the "main process". But there @nikoudel's uncomfortability with "sleep" as a "big red hammer" kicks in. The "main process" is probably the app that is running in the browser, right? But actually that app does not go into sleep, it will still react to events etc. What instead will have happened is that the task in which sleep occurs has become its own little process, running concurrently to the app's other event handling. And that little side process sleeps. @evancz, is this an accurate description of what happens? If so, I fear the current documentation does not convey it. Specifically, it seems to be said nowhere that when a Task is performed it becomes a little process (that can be influenced by Process.sleep). In fact, neither the documentation page for Task, nor the guide's page on tasks linked from there contain the word "process" even once. So how could one guess that the Process module is relevant?

@nikoudel, about this part:

Process.sleep returns a task immediately, it doesn't really block a thread so it's not sleeping in a traditional meaning.

That's actually the situation for all Task creating functions. Whenever there is a function doSomething : inputs -> Task ..., then the "something" is not "being done" at all when that function is called. Instead, a task is always returned immediately, and the "something" is only "being done" when the created task is later performed. In that sense, the behavior here is consistent: When sleep is called, that does not mean that someone has to sleep right now, it only means that a task was created which, when later performed, will make some sleeping happen.

But even so, from all the above I now also think that Process.sleep is hard to reconciliate with the rest of the current documentation. How about putting it into Task, as Task.sleep? That would better alude to the fact that some task is sent to sleep, not potentially the "main process" à la "the web app itself".

Given the .NET link provided by @nikoudel, Task.delay also seems nice to me.

Maybe as a last question to @nikoudel: You originally indicated you sought this functionality in Time, didn't find it, gave up and were prepared to reach for doing it via a port. Did you maybe also consider looking in Task, given that you knew you wanted some function that returns a Task? In other words, if the function lived in the Task module, would you have found it, or would you still have failed to find it as happened with it being in Process?

[jvoigtlaender]

@OvermindDL1, but what is that "process" that is sent to sleep? If the user hasn't created any new process with Process.spawn, it must be the "main process". But there @nikoudel's uncomfortability with "sleep" as a "big red hammer" kicks in. The "main process" is probably the app that is running in the browser, right? But actually that app does not go into sleep, it will still react to events etc. What instead will have happened is that the task in which sleep occurs has become its own little process, running concurrently to the app's other event handling. And that little side process sleeps. @evancz, is this an accurate description of what happens? If so, I fear the current documentation does not convey it. Specifically, it seems to be said nowhere that when a Task is performed it becomes a little process (that can be influenced by Process.sleep). In fact, neither the documentation page for Task, nor the guide's page on tasks linked from there contain the word "process" even once. So how could one guess that the Process module is relevant?

@nikoudel, about this part:

Process.sleep returns a task immediately, it doesn't really block a thread so it's not sleeping in a traditional meaning.

That's actually the situation for all Task creating functions. Whenever there is a function doSomething : inputs -> Task ..., then the "something" is not "being done" at all when that function is called. Instead, a task is always returned immediately, and the "something" is only "being done" when the created task is later performed. In that sense, the behavior here is consistent: When sleep is called, that does not mean that someone has to sleep right now, it only means that a task was created which, when later performed, will make some sleeping happen.

But even so, from all the above I now also think that Process.sleep is hard to reconciliate with the rest of the current documentation. How about putting it into Task, as Task.sleep? That would better alude to the fact that some task is sent to sleep, not potentially the "main process" à la "the web app itself".

Given the .NET link provided by @nikoudel, Task.delay also seems nice to me.

Maybe as a last question to @nikoudel: You originally indicated you sought this functionality in Time, didn't find it, gave up and were prepared to reach for doing it via a port. Did you maybe also consider looking in Task, given that you knew you wanted some function that returns a Task? In other words, if the function lived in the Task module, would you have found it, or would you still have failed to find it as happened with it being in Process?

[nikoudel]

Time module was the first place I searched for the function mainly because the guide mentions Time.every which is close in terms of behavior. But right after that I clicked Task which is right before Time in package list. So, yes, I would definitely have found it if it was there.

[nikoudel]

Time module was the first place I searched for the function mainly because the guide mentions Time.every which is close in terms of behavior. But right after that I clicked Task which is right before Time in package list. So, yes, I would definitely have found it if it was there.

[OvermindDL1]

@jvoigtlaender Actually the main 'elm process' is 34 different processes in my current application. An elm process is more like an erlang process than a system process, it is a synchronous unit of calculation, not a running program.

[OvermindDL1]

@jvoigtlaender Actually the main 'elm process' is 34 different processes in my current application. An elm process is more like an erlang process than a system process, it is a synchronous unit of calculation, not a running program.

[jvoigtlaender]

@OvermindDL1, I was talking about the impression that an Elm user (who has not consciously Process.spawned something) gets from the documentation. What you mention now is not relevant to that, I think. Or where is that:

An elm process is more like an erlang process than a system process, it is a synchronous unit of calculation, not a running program.

reflected in the documentation that an aspiring Elm user encounters?

Maybe you didn't notice that my question

The "main process" is probably the app that is running in the browser, right?

was rhetorical. I do know (what you try to explain to me now) that it's not the whole app, but instead some task in its own mini-process. But that I know that is not the point. The point is whether one gets that knowledge from the documentation, and if not, what one may incorrectly think the "current process, when one hasn't spawned one" is, and in which way this may make it a bad idea to have sleep live in Process.

[jvoigtlaender]

@OvermindDL1, I was talking about the impression that an Elm user (who has not consciously Process.spawned something) gets from the documentation. What you mention now is not relevant to that, I think. Or where is that:

An elm process is more like an erlang process than a system process, it is a synchronous unit of calculation, not a running program.

reflected in the documentation that an aspiring Elm user encounters?

Maybe you didn't notice that my question

The "main process" is probably the app that is running in the browser, right?

was rhetorical. I do know (what you try to explain to me now) that it's not the whole app, but instead some task in its own mini-process. But that I know that is not the point. The point is whether one gets that knowledge from the documentation, and if not, what one may incorrectly think the "current process, when one hasn't spawned one" is, and in which way this may make it a bad idea to have sleep live in Process.

[OvermindDL1]

It could use a documentation fix, but consider that Elm does not have generic types, and since 'sleep' is operating on the Process it also seems like it should belong in Process. You could also make other sleeps that work on other types, but the Process type sleeping makes sense to have sleep on it? That might make for better documentation (make it more generic of course ^.^).

[OvermindDL1]

It could use a documentation fix, but consider that Elm does not have generic types, and since 'sleep' is operating on the Process it also seems like it should belong in Process. You could also make other sleeps that work on other types, but the Process type sleeping makes sense to have sleep on it? That might make for better documentation (make it more generic of course ^.^).

[jvoigtlaender]

@OvermindDL1, what is the "Process type" you keep talking about? In the whole of core, there is no type Process. There is a type alias Id to an opaque type ProcessId, but note that sleep has no relation to one of them. Let's take a look at the functions currently in the Process module:

spawn : Task x a -> Task y ProcessId

kill : ProcessId -> Task x ()

sleep : Time -> Task x ()

In what sense does sleep "operate on" the "Process type"?

[jvoigtlaender]

@OvermindDL1, what is the "Process type" you keep talking about? In the whole of core, there is no type Process. There is a type alias Id to an opaque type ProcessId, but note that sleep has no relation to one of them. Let's take a look at the functions currently in the Process module:

spawn : Task x a -> Task y ProcessId

kill : ProcessId -> Task x ()

sleep : Time -> Task x ()

In what sense does sleep "operate on" the "Process type"?

[OvermindDL1]

Eh, I mean the back-end Process type, the javascript calls it Process so it might be a javascript-only type that is not implemented in Elm (I've looked more at the javascript back-end of elm... >.>).

[OvermindDL1]

Eh, I mean the back-end Process type, the javascript calls it Process so it might be a javascript-only type that is not implemented in Elm (I've looked more at the javascript back-end of elm... >.>).

[jvoigtlaender]

So, in other words, your argument seems not to be relevant when considering the "aspiring Elm user" I was talking about above. The one who tries to get stuff done in Elm.

[jvoigtlaender]

So, in other words, your argument seems not to be relevant when considering the "aspiring Elm user" I was talking about above. The one who tries to get stuff done in Elm.

[OvermindDL1]

I had no issue finding Process.sleep and I use Elm at work for work with almost 4000 LOC so far? So it fit my view as-it-is?

[OvermindDL1]

I had no issue finding Process.sleep and I use Elm at work for work with almost 4000 LOC so far? So it fit my view as-it-is?

[jvoigtlaender]

But that's a different argument now.

You found the function in Process. Another user did not.

From these two observations alone we cannot determine which is the "right" place for the function.

[jvoigtlaender]

But that's a different argument now.

You found the function in Process. Another user did not.

From these two observations alone we cannot determine which is the "right" place for the function.

[OvermindDL1]

Why not both? Time.sleep could just call Process.sleep, or vice-versa. Duplication sucks, but delegation is not bad...

[OvermindDL1]

Why not both? Time.sleep could just call Process.sleep, or vice-versa. Duplication sucks, but delegation is not bad...

[jvoigtlaender]

Also, sorry @evancz that this is going on as a discussion on GitHub now. Probably should have happened on the mailing list. The thing was that what I saw on the mailing list was:

• A user could not find the function.
• ... was told where to find it.
• ... was thankful for the help, and explained why they could not find it by themselves.
• ... was ignored after that.

I still had that mailing thread open, but did not have anything myself to say there. Then saw the other day that a renaming suggestion (for toString) was added to #322, so assumed that this here would be a candidate for such procedure as well, rather than the user's concern getting lost as an incomplete thread on the mailing list.

Had I known it would lead to a long discussion, I would have written on the mailing list. But at that point, the only thing I could have written on the mailing list would have been to ask: "Why is this being ignored?"

[jvoigtlaender]

Also, sorry @evancz that this is going on as a discussion on GitHub now. Probably should have happened on the mailing list. The thing was that what I saw on the mailing list was:

• A user could not find the function.
• ... was told where to find it.
• ... was thankful for the help, and explained why they could not find it by themselves.
• ... was ignored after that.

I still had that mailing thread open, but did not have anything myself to say there. Then saw the other day that a renaming suggestion (for toString) was added to #322, so assumed that this here would be a candidate for such procedure as well, rather than the user's concern getting lost as an incomplete thread on the mailing list.

Had I known it would lead to a long discussion, I would have written on the mailing list. But at that point, the only thing I could have written on the mailing list would have been to ask: "Why is this being ignored?"

[OvermindDL1]

Ah yes, I apologize as well, I'm so used to using github issues as conversation over the past ~6 years as a standard, I keep forgetting that Elm is different. I can delete all my posts if wished.

[OvermindDL1]

Ah yes, I apologize as well, I'm so used to using github issues as conversation over the past ~6 years as a standard, I keep forgetting that Elm is different. I can delete all my posts if wished.

[evancz]

Process when an issue gets too long is:

1. Close the issue.
2. Create a new issue with a refined recommendation.

In this cases maybe that is "add Time.sleep = Process.sleep" Keep it focused. Don't make people read tons of stuff that's not necessary to the final understanding.

Let's see how it goes!

[evancz]

Process when an issue gets too long is:

1. Close the issue.
2. Create a new issue with a refined recommendation.

In this cases maybe that is "add Time.sleep = Process.sleep" Keep it focused. Don't make people read tons of stuff that's not necessary to the final understanding.

Let's see how it goes!