4 ms·

>Elm isn't FRP What do you mean? http://elm-lang.org/learn/What-is-FRP.elm http://elm-lang.org/learn/What-is-FRP.elm

by davexunit 12y ago

deleted 12y ago
[deleted]
- wheatBread 12y ago
  Whoa, I'm surprised to hear that I "didn't know anything about FRP when I made Elm". A huge part of developing Elm was doing literature review and making new contributions to FRP ( http://people.seas.harvard.edu/~chong/abstracts/CzaplickiC13.html http://people.seas.harvard.edu/~chong/abstracts/CzaplickiC13... ) and "making things up as I went along" was certainly not how we ended up with a nice system. I don't know why you didn't talk to me at BayHac before making statements like this. Conal and I definitely disagree about what is important to emphasize. FRP is a term that is used in many different ways, in the same way that FP is a term that is used in many ways. I see this as a testament to the power of the idea, and it seems like claiming that this and that are not really FRP is limiting the impact of the original work. We definitely need more precise terms though!
  - seanmcdirmid 12y ago
    I've glanced at the PLDI paper and would definitely consider Elm to be FRP, more in Conal's vision than say Flapjax. But I don't get what new contribution Elm makes to push-based FRP beyond being a nice implementation of it?
    - wheatBread 12y ago
      The most novel stuff was about how to handle asynchrony and concurrency without unexpected/unwanted glitches, though I think formulating things in a way that is simple, accessible, and efficient was important too. My thesis ( http://www.testblogpleaseignore.com/wp-content/uploads/2012/04/thesis.pdf http://www.testblogpleaseignore.com/wp-content/uploads/2012/... ) goes through all of the previous literature that I could find at the time. It frames my view on Elm fits into prior work and how I understood things at that time, but that section got cut from the PLDI version unfortunately.
      - seanmcdirmid 12y ago
        Ok, fair enough. I never tried calling my work FRP before since...well, I threw out the functions and embraced glitches. You should have a look at Conal's vertigo work if you haven't already. It will give you cool things to do functionally with your GPU support. http://conal.net/Vertigo/ http://conal.net/Vertigo/
        wheatBread 12y ago
        Ah, cool! I think he told me about this work when we chatted at ICFP last year, but wasn't able to find it. So thanks for the link!
        seanmcdirmid 12y ago
        One thing that this work requires is some from of symbolic differentiation. Basically, given some expression e, you have to compute, via a symbolic analysis on e's structure, a derivative for e, e'. e' can then be used to compute normals used for shading, replacing the need for a hand crafted normal map (you can also approximate normals via sampling, but if you have a functional definition of a surface, why not just use derivatives!). This definitely requires some compiler support, but the purity of Elm should be helpful in that regard.
  - conal 12y ago
    Indeed I misinterpreted your remarks on Sunday about the origin of Elm. I now understand that while you had an independent inspiration about time-varying values, your design of Elm was strongly influenced by FRP papers. I really do like your work (and you personally). Such good taste in design is rare, in my experience. I'm sorry that I missed the deleted remarks that touched off this discussion, though I can try addressing the two snippets you shared. As for "making things up as I went along", it's not a phrase I would use. Besides, I value creativity in the highest esteem. About "didn't know anything about FRP when I made Elm", I did think you'd had your key ideas on your own, and retrospectively related them to the FRP literature. Now I understand that the FRP influence was more substantive than I knew. I've posted a correction on that ReactiveCocoa page (https://github.com/ReactiveCocoa/ReactiveCocoa/pull/1344#issuecomment-43716637 https://github.com/ReactiveCocoa/ReactiveCocoa/pull/1344#iss...): "Correction. I misinterpreted some recent remarks by Evan Czaplicki (@evancz) about the origin of Elm. While his initial idea was independent (to his credit), the design of Elm itself was indeed influenced by the FRP literature. I'm glad you kept the Elm references. I'll apologize to Evan." I also posted (terser) correction to a reply I made on Twitter (https://twitter.com/conal/status/469005649645281280 https://twitter.com/conal/status/469005649645281280): "I mistook @czaplic's remarks on #elmlang origin. Independent inspiration; design quite influenced by FRP lit. Sincere apologies, Evan! :(". If I see my misinformation spreading, I'll do my best to correct it. Again, my sincere apologies, Evan! Regards, - Conal
- davexunit 12y ago
  It seems that nothing qualifies as FRP except for things invented in very special languages that Conal has written.
- jerf 12y ago
  Before I'm willing to concede a particular, very restrictive definition about what "FRP" is, it would be nice to first see a model of it that does not contain fundamental logical contradictions acknowledged by the author. Last I knew nobody had a continuous, perfectly sensible model of FRP in theory. Further, given the lack of extant model, it's very silly to get pedantic over the term, and end up insisting on a meaning which has not been demonstrated to be practical and therefore one must consider the possibility will never turn out to be practical. It is not out of the question there exists some fundamental mathematical problem with the strict definition of FRP and therefore it must inevitably turn into a family of techniques. This strikes me as sort of like insisting that you don't have OO unless you fully support access control via "private", six months before the first release of anything that actually supports "private", and all along it turns out that access control is fairly orthogonal to OO anyhow. If I am out of date and somehow FRP has settled on a consistent model (without this fact being trumpeted on /r/haskell, where I would have heard about it), then it is, at the very least, still awfully young to be getting this pedantic about what is The One True Definition; it could only have been proved to be not immediately impractical, not yet proved practical.
  - edwintorok 12y ago
    Can you expand on the contradictions? Is there a link where I could learn more about them?
    - jerf 12y ago
      No, I've never dug in enough to understand. I'm much more in the "wait and see" camp about FRP... if it works, great, I'm glad someone's thinking about it, but the philosophical spirit in which it is being approached rubs me the wrong way (and after a few tries, I can't seem to write my characterization of that philosophy in way that doesn't sound insulting or sarcastic, so I'm going to have to leave it there, sorry). YMMV.
  - seanmcdirmid 12y ago
    Encapsulation (and it's twin sibling identity) is completely essential to OO, otherwise you are just using objects as poor man modules.
- Dewie 12y ago
  So the contention is what Conal Elliot means by FRP? If that's the case, it might be that most of us might as well be left in the dark about what FRP really means, because it seems that Mr. Elliot can be quite obtuse about giving a simple definition of a term. http://stackoverflow.com/a/1030631/1725151 http://stackoverflow.com/a/1030631/1725151 If you are asked a question about some programming terminology, then I don't think going as deep as talking about denotational semantics is a good idea.
  - klibertp 12y ago
    This is an answer from a scientist (or at least it looks like it, I don't know anything about Conal Elliott, not even if he actually is a scientist). People like these think and speak on a level of abstraction which may be a little higher than what most people are used to. As a response from a scientist, his post is as good as you could hope, I think - you still need a fair share of googling and reading to understand it, but at least there are sources listed and the basic idea is clearly presented: it's about values over time as first-class values and how they combine and compose. Denotational semantics is a tool like many others, and he even provided a very simple explanation of what it is, before saying how it was useful - it was mentioned as a tool, not presented as something essential to FRP. All in all it's rather informative and better than many other scientists would write. So, while I absolutely don't support what was said in deleted comment, I wouldn't hold this particular post against Conal.
    - 3rd3 12y ago
      The deleted comments claimed that Elm would not fit into the usual definition of FRP (giving references to Conal Elliot).
    - Dewie 12y ago
      > This is an answer from a scientist (or at least it looks like it, I don't know anything about Conal Elliott, not even if he actually is a scientist). He is the (or one of the two) inventor of FRP. > People like these think and speak on a level of abstraction which may be a little higher than what most people are used to. I don't care what 'level of abstraction' someone normally works on. When you're supposed to explain things to other people, you're supposed to explain it their level, not the level of someone who already knows FRP or who is also a programming language theorist/implementer. That was StackOverflow, not Lambda the Ultimate. > As a response from a scientist, his post is as good as you could hope, I think A lot of scientists are educators, and so they have to descend from their 'lofty towers of abstractions' to explain what a for-loop is to first year students. I have certainly seen many scientists, by whom I couldn't read and comprehend a single paragraph of their research paper, be able to explain things much more straightforwardly than him. > you still need a fair share of googling and reading to understand it, SO answers should try to be self contained. A general rule, but certainly doable for a question of the type "what does <term> mean?" > Denotational semantics is a tool like many others, A tool for prog. language theory and implementation. A tool for StackOverflow answers? Maybe, if you also consider answering SO questions of the type "what does this Scala program do" by converting it to an intermediate representation in lambda calculus, or answering "why won't this type check" by explaining with a type deduction in some sequent calculus, or by answering the question "what value will this formula give", by manipulating it as some algebra over some arithmetic signature. It might be beneficial to describe a language by some canonical semantic representation. For a SO answer? If you manage to write several paragraphs without even giving one introductory explanation/example/intuition about what it is, and then you catch yourself writing something like " If this description is gibberish to you, consult (a) Denotational design with type class morphisms,"... you should probably admit to yourself that you've become so accustomed to what is being asked for that you can't even imagine or sink down to the level of a person who has never been in touch with it.
myko 12y ago
I'm no FRP expert but Conal Elliot seems to agree with the now deleted comments: https://github.com/ReactiveCocoa/ReactiveCocoa/pull/1344 https://github.com/ReactiveCocoa/ReactiveCocoa/pull/1344 (Conal Elliot is one of the authors of what is, AFAIK, the earliest paper on FRP: http://conal.net/papers/icfp97/ http://conal.net/papers/icfp97/)
- seanmcdirmid 12y ago
  Here is Conal's comment duplicated for prosperity: > All of these changes so far look good to me. They definitely helps reduce confusion! Under "Here are some resources for learning about FRP", I'd drop the "Principles of Reactive Programming on Coursera" and the two Elm references, as they're both quite different from (the original) FRP. Based on the Coursera description, I'm guessing that it is about Rx. Elm is a system conceived independently from (not even "inspired by") FRP, which bears some superficial similarities, but doesn't have either of the two fundamental properties I mention in the StackOverflow posts (precise & explicit denotation and continuous time). I've spoken with Elm's author, and we'll hopefully get that confusion sorted out. He is definitely right about Rx, but Meijer also never claimed as much (since they are also WG 2.8 members, I'm sure they talk a lot). One of the tenants of FRP is continuous time, and you lose that once you update only at discrete events, which IMHO, is a very sane choice to make. This divergence with classical FRP first appears with Cooper et al's FatherTime work and the later Flapjax work by the same authors. Conal has made some effort to combine the pull (sampling) and push (demand-driven) versions of FRP: http://conal.net/papers/push-pull-frp/ http://conal.net/papers/push-pull-frp/ But still, it makes a lot of sense to go full on discrete. Krishnswami provides some good results in this direction: http://www.mpi-sws.org/~neelk/popl074-krishnaswami.pdf http://www.mpi-sws.org/~neelk/popl074-krishnaswami.pdf I'm not sure, however, what Conal thinks of his work.

>Elm isn't FRP What do you mean? http://elm-lang.org/learn/What-is-FRP.elm http://elm-lang.org/learn/What-is-FRP.elm

deleted 12y ago

[deleted]

wheatBread 12y ago
Whoa, I'm surprised to hear that I "didn't know anything about FRP when I made Elm". A huge part of developing Elm was doing literature review and making new contributions to FRP ( http://people.seas.harvard.edu/~chong/abstracts/CzaplickiC13.html http://people.seas.harvard.edu/~chong/abstracts/CzaplickiC13... ) and "making things up as I went along" was certainly not how we ended up with a nice system. I don't know why you didn't talk to me at BayHac before making statements like this. Conal and I definitely disagree about what is important to emphasize. FRP is a term that is used in many different ways, in the same way that FP is a term that is used in many ways. I see this as a testament to the power of the idea, and it seems like claiming that this and that are not really FRP is limiting the impact of the original work. We definitely need more precise terms though!
- seanmcdirmid 12y ago
  I've glanced at the PLDI paper and would definitely consider Elm to be FRP, more in Conal's vision than say Flapjax. But I don't get what new contribution Elm makes to push-based FRP beyond being a nice implementation of it?
  - wheatBread 12y ago
    The most novel stuff was about how to handle asynchrony and concurrency without unexpected/unwanted glitches, though I think formulating things in a way that is simple, accessible, and efficient was important too. My thesis ( http://www.testblogpleaseignore.com/wp-content/uploads/2012/04/thesis.pdf http://www.testblogpleaseignore.com/wp-content/uploads/2012/... ) goes through all of the previous literature that I could find at the time. It frames my view on Elm fits into prior work and how I understood things at that time, but that section got cut from the PLDI version unfortunately.
    - seanmcdirmid 12y ago
      Ok, fair enough. I never tried calling my work FRP before since...well, I threw out the functions and embraced glitches. You should have a look at Conal's vertigo work if you haven't already. It will give you cool things to do functionally with your GPU support. http://conal.net/Vertigo/ http://conal.net/Vertigo/
      - wheatBread 12y ago
        Ah, cool! I think he told me about this work when we chatted at ICFP last year, but wasn't able to find it. So thanks for the link!
        seanmcdirmid 12y ago
        One thing that this work requires is some from of symbolic differentiation. Basically, given some expression e, you have to compute, via a symbolic analysis on e's structure, a derivative for e, e'. e' can then be used to compute normals used for shading, replacing the need for a hand crafted normal map (you can also approximate normals via sampling, but if you have a functional definition of a surface, why not just use derivatives!). This definitely requires some compiler support, but the purity of Elm should be helpful in that regard.
- conal 12y ago
  Indeed I misinterpreted your remarks on Sunday about the origin of Elm. I now understand that while you had an independent inspiration about time-varying values, your design of Elm was strongly influenced by FRP papers. I really do like your work (and you personally). Such good taste in design is rare, in my experience. I'm sorry that I missed the deleted remarks that touched off this discussion, though I can try addressing the two snippets you shared. As for "making things up as I went along", it's not a phrase I would use. Besides, I value creativity in the highest esteem. About "didn't know anything about FRP when I made Elm", I did think you'd had your key ideas on your own, and retrospectively related them to the FRP literature. Now I understand that the FRP influence was more substantive than I knew. I've posted a correction on that ReactiveCocoa page (https://github.com/ReactiveCocoa/ReactiveCocoa/pull/1344#issuecomment-43716637 https://github.com/ReactiveCocoa/ReactiveCocoa/pull/1344#iss...): "Correction. I misinterpreted some recent remarks by Evan Czaplicki (@evancz) about the origin of Elm. While his initial idea was independent (to his credit), the design of Elm itself was indeed influenced by the FRP literature. I'm glad you kept the Elm references. I'll apologize to Evan." I also posted (terser) correction to a reply I made on Twitter (https://twitter.com/conal/status/469005649645281280 https://twitter.com/conal/status/469005649645281280): "I mistook @czaplic's remarks on #elmlang origin. Independent inspiration; design quite influenced by FRP lit. Sincere apologies, Evan! :(". If I see my misinformation spreading, I'll do my best to correct it. Again, my sincere apologies, Evan! Regards, - Conal
davexunit 12y ago
It seems that nothing qualifies as FRP except for things invented in very special languages that Conal has written.
jerf 12y ago
Before I'm willing to concede a particular, very restrictive definition about what "FRP" is, it would be nice to first see a model of it that does not contain fundamental logical contradictions acknowledged by the author. Last I knew nobody had a continuous, perfectly sensible model of FRP in theory. Further, given the lack of extant model, it's very silly to get pedantic over the term, and end up insisting on a meaning which has not been demonstrated to be practical and therefore one must consider the possibility will never turn out to be practical. It is not out of the question there exists some fundamental mathematical problem with the strict definition of FRP and therefore it must inevitably turn into a family of techniques. This strikes me as sort of like insisting that you don't have OO unless you fully support access control via "private", six months before the first release of anything that actually supports "private", and all along it turns out that access control is fairly orthogonal to OO anyhow. If I am out of date and somehow FRP has settled on a consistent model (without this fact being trumpeted on /r/haskell, where I would have heard about it), then it is, at the very least, still awfully young to be getting this pedantic about what is The One True Definition; it could only have been proved to be not immediately impractical, not yet proved practical.
- edwintorok 12y ago
  Can you expand on the contradictions? Is there a link where I could learn more about them?
  - jerf 12y ago
    No, I've never dug in enough to understand. I'm much more in the "wait and see" camp about FRP... if it works, great, I'm glad someone's thinking about it, but the philosophical spirit in which it is being approached rubs me the wrong way (and after a few tries, I can't seem to write my characterization of that philosophy in way that doesn't sound insulting or sarcastic, so I'm going to have to leave it there, sorry). YMMV.
- seanmcdirmid 12y ago
  Encapsulation (and it's twin sibling identity) is completely essential to OO, otherwise you are just using objects as poor man modules.
Dewie 12y ago
So the contention is what Conal Elliot means by FRP? If that's the case, it might be that most of us might as well be left in the dark about what FRP really means, because it seems that Mr. Elliot can be quite obtuse about giving a simple definition of a term. http://stackoverflow.com/a/1030631/1725151 http://stackoverflow.com/a/1030631/1725151 If you are asked a question about some programming terminology, then I don't think going as deep as talking about denotational semantics is a good idea.
- klibertp 12y ago
  This is an answer from a scientist (or at least it looks like it, I don't know anything about Conal Elliott, not even if he actually is a scientist). People like these think and speak on a level of abstraction which may be a little higher than what most people are used to. As a response from a scientist, his post is as good as you could hope, I think - you still need a fair share of googling and reading to understand it, but at least there are sources listed and the basic idea is clearly presented: it's about values over time as first-class values and how they combine and compose. Denotational semantics is a tool like many others, and he even provided a very simple explanation of what it is, before saying how it was useful - it was mentioned as a tool, not presented as something essential to FRP. All in all it's rather informative and better than many other scientists would write. So, while I absolutely don't support what was said in deleted comment, I wouldn't hold this particular post against Conal.
  - 3rd3 12y ago
    The deleted comments claimed that Elm would not fit into the usual definition of FRP (giving references to Conal Elliot).
  - Dewie 12y ago
    > This is an answer from a scientist (or at least it looks like it, I don't know anything about Conal Elliott, not even if he actually is a scientist). He is the (or one of the two) inventor of FRP. > People like these think and speak on a level of abstraction which may be a little higher than what most people are used to. I don't care what 'level of abstraction' someone normally works on. When you're supposed to explain things to other people, you're supposed to explain it their level, not the level of someone who already knows FRP or who is also a programming language theorist/implementer. That was StackOverflow, not Lambda the Ultimate. > As a response from a scientist, his post is as good as you could hope, I think A lot of scientists are educators, and so they have to descend from their 'lofty towers of abstractions' to explain what a for-loop is to first year students. I have certainly seen many scientists, by whom I couldn't read and comprehend a single paragraph of their research paper, be able to explain things much more straightforwardly than him. > you still need a fair share of googling and reading to understand it, SO answers should try to be self contained. A general rule, but certainly doable for a question of the type "what does <term> mean?" > Denotational semantics is a tool like many others, A tool for prog. language theory and implementation. A tool for StackOverflow answers? Maybe, if you also consider answering SO questions of the type "what does this Scala program do" by converting it to an intermediate representation in lambda calculus, or answering "why won't this type check" by explaining with a type deduction in some sequent calculus, or by answering the question "what value will this formula give", by manipulating it as some algebra over some arithmetic signature. It might be beneficial to describe a language by some canonical semantic representation. For a SO answer? If you manage to write several paragraphs without even giving one introductory explanation/example/intuition about what it is, and then you catch yourself writing something like " If this description is gibberish to you, consult (a) Denotational design with type class morphisms,"... you should probably admit to yourself that you've become so accustomed to what is being asked for that you can't even imagine or sink down to the level of a person who has never been in touch with it.

myko 12y ago

I'm no FRP expert but Conal Elliot seems to agree with the now deleted comments: https://github.com/ReactiveCocoa/ReactiveCocoa/pull/1344 https://github.com/ReactiveCocoa/ReactiveCocoa/pull/1344 (Conal Elliot is one of the authors of what is, AFAIK, the earliest paper on FRP: http://conal.net/papers/icfp97/ http://conal.net/papers/icfp97/)

seanmcdirmid 12y ago
Here is Conal's comment duplicated for prosperity: > All of these changes so far look good to me. They definitely helps reduce confusion! Under "Here are some resources for learning about FRP", I'd drop the "Principles of Reactive Programming on Coursera" and the two Elm references, as they're both quite different from (the original) FRP. Based on the Coursera description, I'm guessing that it is about Rx. Elm is a system conceived independently from (not even "inspired by") FRP, which bears some superficial similarities, but doesn't have either of the two fundamental properties I mention in the StackOverflow posts (precise & explicit denotation and continuous time). I've spoken with Elm's author, and we'll hopefully get that confusion sorted out. He is definitely right about Rx, but Meijer also never claimed as much (since they are also WG 2.8 members, I'm sure they talk a lot). One of the tenants of FRP is continuous time, and you lose that once you update only at discrete events, which IMHO, is a very sane choice to make. This divergence with classical FRP first appears with Cooper et al's FatherTime work and the later Flapjax work by the same authors. Conal has made some effort to combine the pull (sampling) and push (demand-driven) versions of FRP: http://conal.net/papers/push-pull-frp/ http://conal.net/papers/push-pull-frp/ But still, it makes a lot of sense to go full on discrete. Krishnswami provides some good results in this direction: http://www.mpi-sws.org/~neelk/popl074-krishnaswami.pdf http://www.mpi-sws.org/~neelk/popl074-krishnaswami.pdf I'm not sure, however, what Conal thinks of his work.