12 ms·

Elm 0.12.3 – Hardware accelerated 3D rendering with WebGL

101 points by wheatBread 12y ago

davexunit 12y ago
The Elm hackers continue to impress me. FRP, the interactive timeline debugger, and now functional 3D graphics. Functional game programming is a big interest of mine, and I've taken a lot of inspiration from Elm in my own personal project to create a 2D game engine for Guile Scheme.
- deleted 12y ago
  [deleted]
  - davexunit 12y ago
    >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.
      - 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.
  - deleted 12y ago
    [deleted]
  - Nekorosu 12y ago
    It purely is ;)
thu 12y ago
This release makes me very happy. I never really took a look at Elm but yesterday I've receive a bug report on a very old library of mine to parse GLSL. The author of Elm told me it was used in their WebGL work and pointed to that Thwomp example. I didn't know that library was actually used by anyone!
- johnpmayer 12y ago
  John here. Having language-glsl available on hackage was a boon for the features in this release. Thank you!
phorese 12y ago
Loading this page insta-kills my Browser. FF 29.0.1 on 3.10.39-1-MANJARO x86_64 with lots of plugins (HTTPSEverywhere, Ghostery, FlashBlock...) It does not recognize the crash and does not offer a crash report on restart.
- TD-Linux 12y ago
  Works for me on 3.14 with the nvidia blob driver. Definitely sounds like a video driver issue. File a bug report?
  - phorese 12y ago
    Will do.
dbbolton 12y ago
>We switched away from Hue-Saturation-Value (HSV) because Value is a bit more confusing than Lightness. That's funny to me because I've always found HSV colors and color choosers to be a lot more intuitive.
kbenson 12y ago
I still think first of a terminal mail program when I read "elm". Same for "pine".
kristianp 12y ago
I'm curious, why isn't type inference used in the examples? For example: http://elm-lang.org/edit/examples/WebGL/Triangle.elm http://elm-lang.org/edit/examples/WebGL/Triangle.elm Edit: ok, the language has full type inference, but not the webgl examples.
- wheatBread 12y ago
  Type inference works on all Elm programs, but it's best practice to add type annotations. In the WebGL examples, I felt it made things a bit clearer since folks are probably not familiar with how WebGL works. Once you get comfortable reading types, it helps you see how things fit together, and they definitely helped me learn John's API when I was new to it :) But if you don't need/want type annotations, you can totally take them all away and they'll be inferred! How did having them effect your experience of looking at the examples?
  - kristianp 12y ago
    The main effect was that I thought "why is this ML-style language not using type inference!". :) But now that you have explained why you've annotated the examples, I can see that it would be educational to see the types when the reader wouldn't have seen the library before.
wereHamster 12y ago
Does it only support Triangles? What about buffers? Rendering individual triangles is not efficient if you have anything more than a simple scene.
- johnpmayer 12y ago
  The API expects triangles, but it is implemented to always use buffers under the hood. Basically, mesh data of 10 triangles with 4 attributes per vertex is converted to 4 buffers, each of length 30.
paulannesley 12y ago
elm was my daily-use email client at work twelve years ago. http://en.wikipedia.org/wiki/Elm_(email_client) http://en.wikipedia.org/wiki/Elm_(email_client)

101 points by wheatBread 12y ago

The Elm hackers continue to impress me. FRP, the interactive timeline debugger, and now functional 3D graphics. Functional game programming is a big interest of mine, and I've taken a lot of inspiration from Elm in my own personal project to create a 2D game engine for Guile Scheme.

deleted 12y ago
[deleted]
- davexunit 12y ago
  >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.
    - 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.
- deleted 12y ago
  [deleted]
- Nekorosu 12y ago
  It purely is ;)

thu 12y ago

This release makes me very happy. I never really took a look at Elm but yesterday I've receive a bug report on a very old library of mine to parse GLSL. The author of Elm told me it was used in their WebGL work and pointed to that Thwomp example. I didn't know that library was actually used by anyone!

johnpmayer 12y ago
John here. Having language-glsl available on hackage was a boon for the features in this release. Thank you!

phorese 12y ago

Loading this page insta-kills my Browser. FF 29.0.1 on 3.10.39-1-MANJARO x86_64 with lots of plugins (HTTPSEverywhere, Ghostery, FlashBlock...) It does not recognize the crash and does not offer a crash report on restart.

TD-Linux 12y ago
Works for me on 3.14 with the nvidia blob driver. Definitely sounds like a video driver issue. File a bug report?
- phorese 12y ago
  Will do.

dbbolton 12y ago

>We switched away from Hue-Saturation-Value (HSV) because Value is a bit more confusing than Lightness. That's funny to me because I've always found HSV colors and color choosers to be a lot more intuitive.

kbenson 12y ago

I still think first of a terminal mail program when I read "elm". Same for "pine".

kristianp 12y ago

I'm curious, why isn't type inference used in the examples? For example: http://elm-lang.org/edit/examples/WebGL/Triangle.elm http://elm-lang.org/edit/examples/WebGL/Triangle.elm Edit: ok, the language has full type inference, but not the webgl examples.

wheatBread 12y ago
Type inference works on all Elm programs, but it's best practice to add type annotations. In the WebGL examples, I felt it made things a bit clearer since folks are probably not familiar with how WebGL works. Once you get comfortable reading types, it helps you see how things fit together, and they definitely helped me learn John's API when I was new to it :) But if you don't need/want type annotations, you can totally take them all away and they'll be inferred! How did having them effect your experience of looking at the examples?
- kristianp 12y ago
  The main effect was that I thought "why is this ML-style language not using type inference!". :) But now that you have explained why you've annotated the examples, I can see that it would be educational to see the types when the reader wouldn't have seen the library before.

wereHamster 12y ago

Does it only support Triangles? What about buffers? Rendering individual triangles is not efficient if you have anything more than a simple scene.

johnpmayer 12y ago
The API expects triangles, but it is implemented to always use buffers under the hood. Basically, mesh data of 10 triangles with 4 attributes per vertex is converted to 4 buffers, each of length 30.

paulannesley 12y ago

elm was my daily-use email client at work twelve years ago. http://en.wikipedia.org/wiki/Elm_(email_client) http://en.wikipedia.org/wiki/Elm_(email_client)