4 ms·

> With a proper type system, you can change the world. You don't have to sell me on type systems - they're exactly why I'm working on Roy. > If you have furth

> With a proper type system, you can change the world. You don't have to sell me on type systems - they're exactly why I'm working on Roy. > If you have further doubts about the viability of this approach, see http://ashimagroup.net/demo/game/ooman/tutorial/ http://ashimagroup.net/demo/game/ooman/tutorial/ for a rigid body motion model in an OCaml WebGL game compiled to JS. I know that compiling languages with completely different semantics to JavaScript is possible (I even maintain http://altjs.org/ 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.

silentOpen 15y ago
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/ 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?
- pufuwozu 15y ago
  > ... I am proposing that you increase the ability for both humans and computers to reason about it Ah :) On my TODO list is to create an intermediate representation to more easily reason about Roy's semantics: https://github.com/pufuwozu/roy/issues/41 https://github.com/pufuwozu/roy/issues/41 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. > Will you commit to implementing Roy in Roy? Would really like to - or at least some modules: https://github.com/pufuwozu/roy/issues/1 https://github.com/pufuwozu/roy/issues/1 > Will Roy offer a subset or a superset of the type system of the metalanguage (JavaScript)? Mostly a superset of JavaScript. > Exhaustive case analysis and polymorphic variants? Not yet. > Will you be able to implement the type-checker correctly and safely in JavaScript? With enough tests I'll have some confidence in it. I don't have enough tests. ;) > Will your users ever be able to compile their pure Roy code into another functional language? Probably not - at least not written by me since that's not what I designed it for. But no objections if someone does it. :) Hopefully some core semantics will make it possible for someone to do that.

silentOpen 15y ago

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/ 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?

pufuwozu 15y ago
> ... I am proposing that you increase the ability for both humans and computers to reason about it Ah :) On my TODO list is to create an intermediate representation to more easily reason about Roy's semantics: https://github.com/pufuwozu/roy/issues/41 https://github.com/pufuwozu/roy/issues/41 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. > Will you commit to implementing Roy in Roy? Would really like to - or at least some modules: https://github.com/pufuwozu/roy/issues/1 https://github.com/pufuwozu/roy/issues/1 > Will Roy offer a subset or a superset of the type system of the metalanguage (JavaScript)? Mostly a superset of JavaScript. > Exhaustive case analysis and polymorphic variants? Not yet. > Will you be able to implement the type-checker correctly and safely in JavaScript? With enough tests I'll have some confidence in it. I don't have enough tests. ;) > Will your users ever be able to compile their pure Roy code into another functional language? Probably not - at least not written by me since that's not what I designed it for. But no objections if someone does it. :) Hopefully some core semantics will make it possible for someone to do that.