Hey, this is my project! :) I am surprised it got posted here, but I am also glad to see people are interested.
One note on the title of this post: Elm compiles to HTML, CSS, and JS. Not just JS! I think this actually an extremely important distinction! It differentiates the project from templating libraries which still ultimately have you think and write in HTML. It also distinguishes it from scripting languages (like CoffeeScript) which also only address part of the problem. With Elm, you shouldn't need the mental model imposed by HTML and CSS which I think will be a really great thing.
Very interesting project. I notice the site itself is written in Elm; it would be great if we could see the source code for the site, any chance of adding some of it to the examples section?
Thank you! And yes, that has been a really good way to test the language out. I don't want to add it to the examples because I use some internal-only functions to make it work nicely. It's also not terribly instructive. You can see it at (http://elm-lang.org/edit/Elm.elm) if you really want. Due to some implementation issues with Element sizing and some Element abstractions, there is some suboptimal stuff in there, but I am working on it. It should be shorter and prettier when the language and implementation gets more mature.
For instance, I am really unhappy with padding/margin, so that almost certainly come out. I have a nicer abstraction in mind that should solve HTML's problems with padding/margins/positioning. I can't say it will happen soon, but it's on the way.
P.S. If you want to look at other files, adding 'edit' to an Elm file gives you the source right now. http://elm-lang.org/edit/...
This surprised me: link has type (String -> String -> String), taking URL and label as arguments, and returning HTML code as a string (instead of as an Element).
Then you need to use the text function (String -> Element)
to make that link appear properly on the screen.
This means that the text function (intentionally?) does not HTML-escape strings, even though examples suggest that it is the recommended way to put some unformatted text on the screen.
text seems very poorly named, especially if the goal is for HTML/CSS/Javascript to be treated like assembly. Maybe create a function called html that does what text does now, and let the text function be equivalent to (html . htmlEscape).
Looks nice overall, and I look forward to seeing how it develops. Is Elm available for download?
This is my project. I agree that the type of link is a little weird. This was added pretty early on in the project and I haven't circled back around to rethink it. I'll try to address your questions:
- Why is text necessary?
Elements are all rectangles that have a uniform set of functions that can be applied to them. Strings are definitely not rectangles, and I think it is important that the type of String and Element are not conflated. In that case what does (++) do when given an Element? It just wouldn't work out.
- Why is text unescaped?
That's pretty much an implementation oversight from when I was first starting the project. Strings should be exactly what you intend to display. I have been meaning to go back through and fix up the underlying string representation, but I just don't have time right now. I have been focusing on the theoretical aspects of reactive programming for my thesis which is my main priority at the moment. Nonetheless, this will be fixed eventually!
- Why (link :: String -> String -> String)?
My thought when I designed it this way was that part of what it means to be a string includes styling (bold, italic, etc.). Following this idea, this would have to be true of characters as well, so (head (link "/" "Elm")) would give you a character that is a link. I honestly think that's a little weird. I,ve gotten questions about this before, and I'm not exactly sure what the right answer is. The other option is to include an intermediate type of strings that does include style information, but then you need to lift normal strings up to this type to do concatenation (unpleasant). Doing this right is going to be really hard, and I haven't given it the time to really figure it out. I'll probably include ways to use markdown (or HTML) which will alleviate some of these issues. If you have suggestions on this topic I'd be interested to hear. It's harder than it looks :P
Also, let me stress that this project is VERY young, so there are still many kinks to be worked out. There is no download available now. With upcoming thesis deadlines, I probably won't have one up until spring of next year at the earliest. Thank you for your interest! I'm working as fast as I can!
For an even earlier FRP paper, see http://conal.net/papers/ActiveVRML/, about the first implementation of what came to be called "FRP". Fran was my reimplementation of that system after I found Haskell.
Functional reactive programming makes ui development so much easier. I've seen a lot of people starting to think this way about ui systems (with good reason). Good work!
I'd like to add similar compiled-in reactive optimizations to FaxJs as I'm sure Elm does. I commend you on choosing a static type inference system.
Elm is extremely cool and I hope he expands on it.
Doesn't it seem like Elm could become HyperCard for the WWW, but with more powerful programming concepts?
I had a similar idea, but with a few more variations:
* Syntax more like HyperTalk.
* OOP/FP inspired from Factor.
(Which was inspired by a bunch of different languages.)
* have it also run code on the server-side with
several data-store architectures to choose from.
I'm also working on a senior undergraduate thesis project in a vaguely similar domain (static typechecking of Python, github.com/jruberg/pyty), so I have a couple questions:
- Is the code open source? If not, did you just choose to keep it closed source as your work on it for the thesis?
- The site mentions that it's statically typed with type inference; has your thesis work also involved formally proving such things?
- Is the goal of the thesis to make something academically interesting or practically useful? Personally, I've struggled with balancing time and wish I could focus more on packaging and making my project accessible.
- It isn't open source right now. I think that's best while the language is still developing, but I plan on opening it up once things have settled down. I don't want to have legacy code before I've even started :P
- No, that aspect is fairly tangential. Since my language is heavily based on the lambda calculus, I already have pretty good basis for nice type properties. I don't have a formal semantics right now, so it will be a while before any such proof would even be possible.
- Both hopefully! I totally understand this dilemma. As lots of people here have pointed out, there is a lot of work to be done on the implementation, but the theoretical aspects of the language have to be a higher priority for the next couple months. It's stressful!
I wish you the best on your project! It sounds really ambitious / useful. I imagine such an analysis could help generate much faster code too.
I really like this idea. I took a look at the Javascript output of the compiler, and noticed that effectively every statement of the program would result in a function nested within the function created by the last N statements. Since Javascript doesn't have tail call optimization, the browser will complain at some point when the stack overflows.
Contrived, I know, but it looks like in Firefox 8 that happens at around 39k.
This is an important issue! I'm aware of the problem and have some ideas of how to avoid it. My compiler is not actually doing any optimization at this stage, so this will be addressed when I give this more attention.
1 - You shouldn't re-use a name that already exists. Elm is a long existing mail client. Pick a different name.
2 - Is writing JavaScript really that hard to people that we need so many of these CoffeeScript like languages? JavaScript is really damn easy to write as is. The biggest pain is the DOM and there are various libraries to deal with that if you want.
You realize that this is nothing like CoffeeScript, except in compiling to JavaScript? The point of CoffeeScript is to iron out the kinks in JavaScript--it's basically JavaScript polished up in slightly different clothes.
This language, on the other hand, is completely different from JavaScript. Writing functional, reactive code is entirely dissimilar from writing idiomatic JavaScript. This isn't an attempt to make JavaScript easier to write--it's an attempt to bring an entirely different paradigm to the web.
Not only is the language completely different from JavaScript, but it also brings a new way of interacting with the DOM. Reactive programming can be used to model interfaces very neatly; it is probably a better way to interact with a web page than the DOM.
I suspect people used to OOP languages will (at least at first) find this one harder to use that JavaScript. On the other hand, the sort of people who are already using Haskell and the like will enjoy it. Also, a functional language like this tends to have more concise code and fewer opportunities for error--mutation is at the heart of a large number of bugs; limiting it removes most of these bugs.
Finally, just because JavaScript is already easy doesn't mean it couldn't be improved. In my experience, I tend to solve problems faster in Haskell than JavaScript; bringing that sort of programming to the web could make me a more productive web developer.
This is not supposed to be only a JavaScript replacement. From what I see, JavaScript is just used as a really easy target for experimenting with functional reactive programming.
CoffeeScript is essentially JavaScript with a different syntax, while this is a completely different language that just happens to have JavaScript as it's primary build target (which makes a lot of sense if you think about Functional Reactive Programming).
1 - You shouldn't re-use a name that already exists. Elm is a long existing mail client. Pick a different name.
Doesn't matter. Elm is a unique name for a programming language. That something completely different exists with the same name doesn't make any difference to either project.
Besides, if Google can name a language Go, even though a programming language was already named Go!, then naming a programming language Elm, even though an email client is already called Elm, isn't nearly as confusing.
Point of curiosity here, and I'm genuinely curious and not trying to snark; is it considered "compiling" when it's simply translating one source language to another? I see this term used a lot lately (and almost exclusively in the "... to javascript" context), so wondered if my preconceived notion was incorrect.
Compiling is translating from one language to another. Sometimes the target is machine assembly, sometimes virtual machine bytecode, and sometimes other language.
Flapjax still has you deal with the abstractions provided by HTML and CSS. I generally think these abstractions are pretty problematic, but more subtly, this means you must think imperatively (e.g. modifying the DOM) which doesn't really fit with the FRP paradigm. Flapjax is also based on the classical formulation of FRP which I think is not ideal for this setting (that is a big part of my thesis).
Nonetheless, I think Flapjax is a really cool project, and if you have to work with HTML, CSS, and JS directly, I can imagine it makes many things much more pleasant.
What specifically is your thesis? (I'm well-versed with the various formulations of FRP that have existed over the years.)
P.S. the navigation links at the top of the page don't work in Opera. Why aren't they just links + :hover CSS? (I presume they're written using Elm but that's not good if people for whom Elm doesn't work want to find out more.)
That's a much tougher question. I am still early in the process, so I don't have a clean and clear answer yet. I am trying to approach FRP from the perspective of GUI design. In this context continuous Behaviors and discrete Events are not exactly what a developer would want to deal with. I don't want to go into it too much now, but I will definitely post my thesis once it is done.
Also, thanks for pointing out the Opera mistake. It is on my to-do list!
I wrote a GUI system using FRP in OCaml. I found events + behaviors (and their Cartesian product) to work very well (with the notable exception that syntactic sugar for defining state machines would be a desirable addition), so I'm very curious to see what improvements you suggest.
By "post my thesis" presumably you mean on your website and not HN? (I'll never find it if it's just on HN.)
What was your project called? I remember reading a paper on an ML implementation of FRP (Reactive ML?); I'm curious if that was you. Also, yes, on my website.
I'm working with Stephen Chong. This isn't his primary research focus, but he is a really great adviser. Our PL group is really strong (I think :P), so I have lots of great resources around.
an earlier comment pointed out that there is no similarity between elm and coffeescript except that they compile to JavaScript. coffeescript is just JavaScript in a new syntax. Elm brings a new paradigm to the web.
One note on the title of this post: Elm compiles to HTML, CSS, and JS. Not just JS! I think this actually an extremely important distinction! It differentiates the project from templating libraries which still ultimately have you think and write in HTML. It also distinguishes it from scripting languages (like CoffeeScript) which also only address part of the problem. With Elm, you shouldn't need the mental model imposed by HTML and CSS which I think will be a really great thing.