Greg Weber writes:

AFAICT this language is less featureful than coffee-script, its only advantage being the syntax is slightly more haskellish.

Of course, it does provides a technique for inserting haskell values into javascript, and having javascript in haskell code. I think it would be better to add these features to the more widely used coffee script using that part of JMacro and/or Yesod's similar template tools.

Hi! Author of JMacro here. You're right that JMacro has a few less features than CoffeeScript. In particular, it lacks pattern matching. Outside of that, however, most CoffeeScript features are to make CoffeeScript more rubylike in syntax. Haskell-style anonymous lambdas coupled with whitespace function application on their own, however, suffice to allow exceedingly Haskell/ML-like code. JMacro can be used as a nicer syntax for JavaScript, but the big win is that it is a better way to *generate* JavaScript -- in particular via hygiene and a shared namespace with surrounding Haskell code. So bear in mind also that JMacro syntax is infinitely-extensible in the sense that you can not only write JavaScript combinators in JMacro, but Haskell combinators which produce JMacro that can be spliced directly back into a block of code. Jeff and I have, for instance, written a tiny set of infix combinators for chaining jQuery selectors. Another feature of JMacro as opposed to CoffeeScript is that almost all valid JavaScript code is *also* valid JMacro. So you can take a code-sample or snippet from the web and place it directly into your application, refactoring it into a more functional style incrementally and at whatever pace you want. CoffeeScript allows for "escaping" into raw javascript, but that's in my opinion a much weaker alternative. JMacro as it now stands is more than sufficient for the paces that Jeff and I put it through -- and we use it all the time for the systems that we build. That said, if there was interest from others who wanted to use it, there are plenty of features that could be further developed. For one, the output could be made more efficient, and hooked into hjsmin as well. Syntax-wise, destructuring bind could be added as well as infix composition and a pleasant sugar for partial application. So if there are more JMacro users, and they want more features, I'll be as responsive as possible within my time constraints. The parser is also pretty straightforward to hack on if you want to add anything yourself. One reason that we haven't needed more out of JMacro is that we're only really using JavaScript for the raw UI, and have managed to push the complicated bits all into Haskell, which we communicate with via lightweight ajax/json RPCs, with autogenerated stubs (a 'la haxr). There's proof-of-concept code that demonstrates how to do this (with a dependency on jQuery) in the package [1]. Attempting to cut dependencies down, this code is written to be generic over backends rather than tied to any particular server/framework. So it'll take a tiny bit of glue to get working on your stack of choice. The really nice new stuff I've been doing isn't in the repo at all yet -- I've been meaning to find time to abstract it out in the right way so that it isn't too specific to one given setup. The RPCs I described above are all served from a given directory. However, there's now a concept of *conversations* which hold state local to a single load of a webpage from a given client. Their RPCs are tied to the webpage itself. This per-page state lets you write rich, stateful, web applications which hold all the important bits in the Haskell server and allow the browser-side client to act as a thin layer for display. If anyone is interested in using JMacro, or, better yet, hacking on it a bit, please let me know. Some users and/or collaborators would be a big incentive for me to do more work on adding features and building up the conversation/session machinery that I've been working with, etc. Cheers, Gershom [1] http://patch-tag.com/r/gershomb/jmacro/snapshot/current/content/pretty/Langu...