{"action":"created","issue":{"url":"https://api.github.com/repos/elm-lang/elm-compiler/issues/900","labels_url":"https://api.github.com/repos/elm-lang/elm-compiler/issues/900/labels{/name}","comments_url":"https://api.github.com/repos/elm-lang/elm-compiler/issues/900/comments","events_url":"https://api.github.com/repos/elm-lang/elm-compiler/issues/900/events","html_url":"https://github.com/elm-lang/elm-compiler/issues/900","id":60771619,"number":900,"title":"Removing Signals","user":{"login":"viclib","id":1719422,"avatar_url":"https://avatars.githubusercontent.com/u/1719422?v=3","gravatar_id":"","url":"https://api.github.com/users/viclib","html_url":"https://github.com/viclib","followers_url":"https://api.github.com/users/viclib/followers","following_url":"https://api.github.com/users/viclib/following{/other_user}","gists_url":"https://api.github.com/users/viclib/gists{/gist_id}","starred_url":"https://api.github.com/users/viclib/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/viclib/subscriptions","organizations_url":"https://api.github.com/users/viclib/orgs","repos_url":"https://api.github.com/users/viclib/repos","events_url":"https://api.github.com/users/viclib/events{/privacy}","received_events_url":"https://api.github.com/users/viclib/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":2,"created_at":"2015-03-12T05:02:34Z","updated_at":"2015-03-12T05:12:08Z","closed_at":null,"body":"That may sound like a terrible idea - maybe it is - but it is puzzling me so I want to hear your opinion on it. Note this is totally uninplementable without giantic refactorings so I'm not asking that at all. Just thoughts, really.\r\n\r\nWe all know Monads are great for keeping stateful computation isolated from the rest of the program in a purely functional language. They work on Haskell for many reasons. I just suspect those reasons don't apply to Elm, and the FRP's approach could work totally independent of Monads: we could just keep everything at the language level **completely pure** and allow values to be changed externally from JS. For example, consider the following program:\r\n\r\n    external time : Double\r\n    time = `Date.now()`\r\n\r\n    ballPosition : Double\r\n    ballPosition = sin time * 40\r\n   \r\n    main : Element\r\n    main = circle 200 ballPosition blue\r\n\r\nHere, `time` is defined externally by a JavaScript computation. Whenever it is changes, any element depending on it is changed too. Now, it sounds like \"time\" is stateful and could cause havoc, but it is actually not. For example, **referential transparency still holds**. Indeed, the language now is actually much more pure than before, since there is no state on the language level at all - not even inside monads. It might help if you think an Elm program as a function which receives its external variables and returns `main`.\r\n\r\nBut why would you do that?\r\n\r\nBecause that keeps our code much simpler and ridiculously easier to newbiews. Since `time`'s type now is just Double, you can use it anywhere without worrying about lifts, fmaps, which I can't overstate how confusing are for newbies. Even for the initiated, that will still make your code much more concise. For example, compare:\r\n\r\n    external currentDate, url, lastTweet : String\r\n\r\n    view : HTML\r\n    view = div [] [div [] [text currentDate], div [] [text url], div [] [text lastTweet]]\r\n\r\nVersus:\r\n\r\n    currentDate, url, lastTweet : Signal String\r\n\r\n    view : HTML\r\n    view = Signal.map3 (\\ currentDate, url, lastTweet →  div [] [div [] [text currentDate], div [] [text url], div [] [text lastTweet]]) currentDate url lastTweet\r\n\r\nI doubt anyone would have trouble understanding the first one. Now, the second... well, good luck explaining lifts, maps. As much as Elm has made things easier, there is still \"monad understanding\" entry wall on the language right now for anyone who wants to use it properly. Trust me - every single time I explain Elm to a friend, I can see him hitting that wall.\r\n\r\nThe only reason I see not to take this approach is that it sounds scary that \"mutable\" values aren't tagged on the type level anymore - but if that is what you are thinking, please, just tell me: what is the \"Signal\" type protecting us from, that this approach would make us vulnerable? Adding a \"pure\" and an \"impure\" value together? But we already do that! Signals are already exactly the same thing; they are already stateful. The only difference is that they are awkward to use.\r\n\r\n    "},"comment":{"url":"https://api.github.com/repos/elm-lang/elm-compiler/issues/comments/78424924","html_url":"https://github.com/elm-lang/elm-compiler/issues/900#issuecomment-78424924","issue_url":"https://api.github.com/repos/elm-lang/elm-compiler/issues/900","id":78424924,"user":{"login":"viclib","id":1719422,"avatar_url":"https://avatars.githubusercontent.com/u/1719422?v=3","gravatar_id":"","url":"https://api.github.com/users/viclib","html_url":"https://github.com/viclib","followers_url":"https://api.github.com/users/viclib/followers","following_url":"https://api.github.com/users/viclib/following{/other_user}","gists_url":"https://api.github.com/users/viclib/gists{/gist_id}","starred_url":"https://api.github.com/users/viclib/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/viclib/subscriptions","organizations_url":"https://api.github.com/users/viclib/orgs","repos_url":"https://api.github.com/users/viclib/repos","events_url":"https://api.github.com/users/viclib/events{/privacy}","received_events_url":"https://api.github.com/users/viclib/received_events","type":"User","site_admin":false},"created_at":"2015-03-12T05:12:08Z","updated_at":"2015-03-12T05:12:08Z","body":"No problems... my bad again :("}}