Native review for pchiusano/elm-execute about package.elm-lang.org HOT 9 CLOSED

Does this need to be in the main package repository? Why not use it in your code base for your particular case?

from package.elm-lang.org.

Also, assuming I understand the core issue correctly, this is one of the scenarios we are trying to cover with the promises work, so I'd be hesitant to point people to this when it will have a less dangerous solution so soon.

from package.elm-lang.org.

Also, assuming I understand the core issue correctly, this is one of the scenarios we are trying to cover with the promises work, so I'd be hesitant to point people to this when it will have a less dangerous solution so soon.

I wouldn't necessarily recommend that anyone use the library either. :) It seems a bit hacky to me, and I tried in the README to indicate that it's easy to shoot yourself in the foot. Feel free to open a PR on the README if you want to add some other stuff in there to make it clear this is experimental, DANGER, etc. :)

Does this need to be in the main package repository? Why not use it in your code base for your particular case?

Yes, I am currently using it right now in my own code base, so I'm not blocked or anything. I thought it could be useful to others who are blocked on the same issue. And I think the primitives might be nice for letting people experiment with providing various higher-level looping / feedback functions. Perhaps some of that will influence the design of the promises stuff, whatever form that finally takes.

Also, the last design I looked at for promises didn't have any first-class functions for evaluating promises. I need that. If the promises stuff requires a special top-level block to interpret a Signal (Promise x a), then it's much much less useful and I'd probably update this library to allow executing of promises instead of messages. That's actually why I picked the generic names schedule and complete rather than something more message-specific like send and deliver or something. :)

from package.elm-lang.org.

@johnpmayer re-convinced me that run : Signal (Promise x a) -> Signal (Result x a) is a good idea. What is the thing you are making though? I think it'd help me to know why it needs to be a function in your case, as it sounds different than what I have in mind.

from package.elm-lang.org.

Ah, I'm glad @johnpmayer convinced you. That's great. Now why wasn't I able to before...? :)

I'm not sure what you are asking... are you asking why I want run or why I want the functions in this library? It's the same reason - I need to be able to trigger an update to a Channel through a mechanism other than a user interaction like click or hover. More specifically, in my case, I want to update a channel when an HTTP response comes back.

Also, I am happy to continue this conversation, but is it a prerequisite for the package being published?

I would also be very happy to discontinue this package once the promises stuff comes out, assuming it is expressive enough for what I need. Assuming these functions exist:

send : Channel/Mailbox/whatever a -> a -> Promise x a
run : Signal (Promise x a) -> Signal (Result x a)

I think I'll be good.

from package.elm-lang.org.

Just to clarify a bit more - I need to write to a channel when an HTTP response comes back because I need a cycle in my signal graph. User interacts with UI, which triggers an HTTP request, which affects how subsequent UI interactions are interpreted. There is no way to express this with the current language, aside from using ports to break the cycle up, but that doesn't work for many cases including mine.

I am interested to explore better looping / cycle creation functions that are safer, but I think there needs to be some experimentation on that front. This library should just be considered a building block, and hopefully a temporary one.

from package.elm-lang.org.

Both of those functions are in the current plan.

On the topic of cycles, I think it's best to implement the OCaml style recursive-values idea described in one of the promise documents. The goal would be to allow the apparent cycles and disallow real ones.

Overall, my preference is to not have this in the vetted packages. I'll try to ask for other opinions tomorrow to vet this preference further.

from package.elm-lang.org.

Okay, so based on John's review on the list about introducing unsafe cycles, I'm going to close this for now. Let's revisit this if the 0.15 release does not address all of the use cases in question.

from package.elm-lang.org.

No problem.

Though AFAICT, the 0.15 stuff will have the exact same safety issues, won't it? Unless you have something fancy planned...

Here is how I was thinking of this issue: the 'unguarded feedback loop' possibility is just the signal analogue of the possibility of nontermination in a language with general recursion. Like most languages, Elm already lets you write nonterminating programs (or programs that blow the stack). The current signal functions don't let you write 'nonterminating signal graphs', at the cost of expressiveness---it is impossible to express these 'effectful loops'. And it seems like there is often going to be some tension between expressiveness and safety. Obviously, it would be great to have something which is sufficiently expressive AND completely safe for all possible uses, but that may be hard or impossible to achieve. I'm thinking of total languages like Agda with their termination / productivity checkers. For some code, it's very convenient, for other code, you have to go through contortions to make the checker happy.

I think it's best to implement the OCaml style recursive-values idea described in one of the promise documents. The goal would be to allow the apparent cycles and disallow real ones.

Sounds interesting. Can you dig up a link to that... not sure what you are referring to.

from package.elm-lang.org.