5 ms·

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 sever

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.

pufuwozu 15y ago
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: http://roy.brianmckenna.org/ 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.
- DannoHung 15y ago
  Sure you could: Haskell can compile to Javascript :D https://github.com/pedromartins/ghcjs https://github.com/pedromartins/ghcjs
- silentOpen 15y ago
  http://ocsigen.org/js_of_ocaml/ http://ocsigen.org/js_of_ocaml/ http://try.ocamlpro.com/ http://try.ocamlpro.com/ 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. 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.
  - pufuwozu 15y ago
    > 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?
mhansen 15y ago
>> 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.
- silentOpen 15y ago
  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.

pufuwozu 15y ago

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: http://roy.brianmckenna.org/ 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.

DannoHung 15y ago
Sure you could: Haskell can compile to Javascript :D https://github.com/pedromartins/ghcjs https://github.com/pedromartins/ghcjs
silentOpen 15y ago
http://ocsigen.org/js_of_ocaml/ http://ocsigen.org/js_of_ocaml/ http://try.ocamlpro.com/ http://try.ocamlpro.com/ 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. 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.
- pufuwozu 15y ago
  > 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?

mhansen 15y ago

>> 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.

silentOpen 15y ago
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.