This would be interesting if the meta-language weren't JavaScript. By choosing JS as the ML, you lose static typing and type inference in the compiler and severely restrict the target platforms and future growth and metaprogramming.
I would love to see a formal specification for the language mapping Roy's syntax to a subset of JS. It would also be nice if the primary implementation were written in OCaml or Haskell. Both of these languages now have very reliable ML->JS compilers and support algebraic data types allowing you to precisely model your object language.
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.
>> you lose static typing and type inference in the compiler
It doesn't matter what the target language is if you want to do static typing or type inference. For example, Haskell compiles down to assembly, but still has an extremely robust type system with inference and all.
>> severely restrict the target platforms and future growth
Are you serious? JavaScript is supported on every platform and is experiencing crazy growth.
You have also misunderstood my concerns. I am not making any statement regarding the choice of target or object or source language (JS, JS, Roy). I am am objecting to the choice of metalanguage (JS). Haskell compiles to assembly but is not written in assembly!
I am very serious. JavaScript is terrible for analysis and a huge waste on the server-side or mobile. Choosing JavaScript as the metalanguage for an implementation of an HM type system is strange. Why have an HM type system itself written in a type-unsafe way? Why artificially limit the analyzability of the language implementation which is pure and simply string(Roy) -> string(JS)? Roy looks like it has great potential and one of the reasons for that potential is its nascent type system. I want to take my pure Roy function library to ObjC, OCaml, C--, etc.
I would love to see a formal specification for the language mapping Roy's syntax to a subset of JS. It would also be nice if the primary implementation were written in OCaml or Haskell. Both of these languages now have very reliable ML->JS compilers and support algebraic data types allowing you to precisely model your object language.