I would love to write Roy in a language with static typing (I'm definitely up for writing Roy in Roy).
But I think CoffeeScript has shown that in-browser compilation and execution is very useful. For example, if I wrote Roy in Haskell, I wouldn't have been able to easily write this demo site:
I will actively contribute to your language implementation and use of these tools should you adopt them. With a proper type system, you can change the world. Without a proper type system, we will all suffer and kill ourselves by a thousand cuts.
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
2. They need a huge runtime
The resultant JavaScript you linked to was ~300K.
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.
Please excuse me, perhaps I was not clear in my language objection. I am very excited about Roy! I am concerned about the language that you have chosen to define it in and what it means for the future of the Roy community.
> 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?
I think this would satisfy your objections: hopefully the core semantics are so small that writing a JavaScript version from them wouldn't be so scary.
I should try that as soon as possible. Simon Peyton-Jones has said multiple times that defining a core intermediate-language for Haskell was very important as it meant they wouldn't add things that didn't make complete sense. Working on Roy doesn't give such a strong sense.
My worry about separating the semantics out into an IR is that we might lose information that makes outputting readable JavaScript possible. But we'll never know until I try.
But I think CoffeeScript has shown that in-browser compilation and execution is very useful. For example, if I wrote Roy in Haskell, I wouldn't have been able to easily write this demo site:
http://roy.brianmckenna.org/
It means you can play with Roy just by hitting a URL - low barrier to entry.
Another benefit is that you can include the Roy compiler in a page and use that to compile your Roy code - no pre-compilation necessary.