Comments (9)
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.
Related Issues (20)
- Switch to self-hosting fonts HOT 1
- The website doesn't explain how to import a package HOT 3
- Site does not show contents on Firefox HOT 2
- Cannot publish a 0.18 package HOT 3
- Can't link to top of module documentation page HOT 1
- Unpublish special-elektronik/elm-autocomplete due to organisation name change HOT 2
- Code highlighting broken when starting with module
- add dark mode HOT 3
- Can't build the backend server with Cabal
- Add documentation on how to build the backend server
- Add a page that lists packages published by a single author HOT 1
- Namespace organization
- Add a maintainer page, listing all packages maintained/owned by someone HOT 2
- package.elm-lang.org uses expired DST Root X3 certificate HOT 5
- Deleted Package HAN-ASD-DT/priority-queue
- Promote jfmengels/elm-review in package search results for "elm-review"
- Request to support query parameter for search query
- how to build?
- Limit for docs.json too low HOT 1
- READMEs only supported as Markdown
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from package.elm-lang.org.