> I know that compiling languages with completely different semantics to JavaScript is possible (I even maintain http://altjs.org/). But they present two problems:
> 1. They output to ugly JavaScript that is hard to interop with and/or people can't reason about
As I am suggesting that you change your metalanguage for Roy's implementation to something with stronger type safety than JavaScript, I am proposing that you increase the ability for both humans and computers to reason about it. Will you commit to implementing Roy in Roy? Will Roy offer a subset or a superset of the type system of the metalanguage (JavaScript)?
I am super-excited about having a thin, HM type system on top of JS. If I could reason about, contribute, and extend the type-checker and compiler, I would adopt Roy in a heartbeat.
> 2. They need a huge runtime
> The resultant JavaScript you linked to was ~300K.
This is not very big for a 3-D game or a compiler. Most of this is runtime and libraries (type-checked JSON, perhaps?) so application code will increase size relatively slowly.
Again, I am not advocating js_of_ocaml as a replacement for Roy. It fulfills a different role. I would love to write type-checked DOM manipulations in Roy natively and produce tiny JS or HTML!
> Roy takes a different approach and tries to stay semantically close to JavaScript when possible. This is to combat both of the above problems. I'd love to see a Roy example of that demo - I imagine the JavaScript would be a lot more readable and smaller.
Do you support persistent objects? Exhaustive case analysis and polymorphic variants? Will you be able to implement the type-checker correctly and safely in JavaScript? Will your users ever be able to compile their pure Roy code into another functional language? Even if Roy is a subset?