6 ms·

Roy: Small functional language that compiles to JavaScript

91 points by DanielRibeiro 15y ago

gerggerg 15y ago
previous discussion: http://news.ycombinator.com/item?id=3277027 http://news.ycombinator.com/item?id=3277027 not sure how much has changed since then.
- pufuwozu 15y ago
  The thing that has gotten me the most excited since then has been an initial version of type-safe node.js modules: http://brianmckenna.org/blog/roy_node_modules http://brianmckenna.org/blog/roy_node_modules
bprater 15y ago
The page doesn't work hard to sell me on the idea.
- pufuwozu 15y ago
  Welcome any ideas on how to make the README better. Better yet, I'll very happily accept pull requests ;)
- epidemian 15y ago
  I think the GitHub project page is fine for someone interested in the development and the technical side of the language. The fun is at http://roy.brianmckenna.org/ http://roy.brianmckenna.org/ =D
silentOpen 15y ago
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.
galenward 15y ago
I wouldn't consider it unless it compiled to coffee script first.
- DanWaterworth 15y ago
  Isn't there a js to coffee script compiler? You could compile from Roy -> js -> coffee script -> js if you really wanted to.
obilgic 15y ago
Someone shares this every other month
overgard 15y ago
All these languages compiling to javascript makes me think we really need a more low level language to compile to for the web. A C for the web, if you will (like how a lot of Lisp implementations will generate C to compile). Not necessarily byte-code per se, but something at a low enough level that provides enough guarantees that it can be compiled into something that performs well without the need for exotic jit compilers and so on. Javascript is not that language. (Obviously C can't be that language for the web (NaCl possibly excluded), but when I say C, I mean in the general profile: extremely simple and maps very closely to what the hardware is actually doing)
- evincarofautumn 15y ago
  Absolutely. I think a concatenative language would be great for this. It’d be easy to target for a wide variety of languages, statically typable if you like, amenable to analysis and optimisation, and much less inherently complex than JavaScript to parse and evaluate. Moreover, it’d be trivial for browser authors to implement, so for a very low investment there could be a huge return. You can write a basic runtime for a full-featured concatenative language in a few hundred lines of C, and a compiler for it in a few dozen lines of Haskell.
  - roel_v 15y ago
    'Ease of implementation' is a very low-ranking, I would almost say irrelevant, factor for the utility or uptake of a programming language. So what if there are only a couple of hundred lines of C, you'd still need tens of thousands at the least to provide a useful standard library.
    - loup-vaillant 15y ago
      I tend to think the usefulness of a (standard) library tend to decrease with the size of its interface. Because with more functions, it is harder to learn, harder to find the function you need, and makes programs less accessible because there are so many ways to do the same job. My bet would be a minimal standard library, based on empirically most useful functionality. I very much doubt you'd need more than a thousand lines to implement that (not counting a possibly crap-load of optimizations).
primecommenter 15y ago
I particularly like the example of Literate Roy: https://github.com/pufuwozu/roy/blob/master/examples/sqrt.lroy https://github.com/pufuwozu/roy/blob/master/examples/sqrt.lr.... This example demonstrates some of the language features and syntax: https://github.com/pufuwozu/roy/blob/master/examples/structural.roy https://github.com/pufuwozu/roy/blob/master/examples/structu....
tzaman 15y ago
Why would I use this over coffeescript, that I'm already used to?
- tkahn6 15y ago
  Some programmers value type safety. That is the niche that Roy fills I believe. I'm certainly excited about it. CoffeeScript is certainly a pleasure to work with but it lacks a type system and static type checking.
  - tomp 15y ago
    Also, Roy supports Algebraic DataTypes (ADTs) - i.e. pattern matching. Though I think it takes quite some experience programming in Ocaml/ML/Haskell to fully appreciate its power.

91 points by DanielRibeiro 15y ago

previous discussion: http://news.ycombinator.com/item?id=3277027 http://news.ycombinator.com/item?id=3277027 not sure how much has changed since then.

pufuwozu 15y ago
The thing that has gotten me the most excited since then has been an initial version of type-safe node.js modules: http://brianmckenna.org/blog/roy_node_modules http://brianmckenna.org/blog/roy_node_modules

bprater 15y ago

The page doesn't work hard to sell me on the idea.

pufuwozu 15y ago
Welcome any ideas on how to make the README better. Better yet, I'll very happily accept pull requests ;)
epidemian 15y ago
I think the GitHub project page is fine for someone interested in the development and the technical side of the language. The fun is at http://roy.brianmckenna.org/ http://roy.brianmckenna.org/ =D

silentOpen 15y ago

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.

galenward 15y ago

I wouldn't consider it unless it compiled to coffee script first.

DanWaterworth 15y ago
Isn't there a js to coffee script compiler? You could compile from Roy -> js -> coffee script -> js if you really wanted to.

obilgic 15y ago

Someone shares this every other month

overgard 15y ago

All these languages compiling to javascript makes me think we really need a more low level language to compile to for the web. A C for the web, if you will (like how a lot of Lisp implementations will generate C to compile). Not necessarily byte-code per se, but something at a low enough level that provides enough guarantees that it can be compiled into something that performs well without the need for exotic jit compilers and so on. Javascript is not that language. (Obviously C can't be that language for the web (NaCl possibly excluded), but when I say C, I mean in the general profile: extremely simple and maps very closely to what the hardware is actually doing)

evincarofautumn 15y ago
Absolutely. I think a concatenative language would be great for this. It’d be easy to target for a wide variety of languages, statically typable if you like, amenable to analysis and optimisation, and much less inherently complex than JavaScript to parse and evaluate. Moreover, it’d be trivial for browser authors to implement, so for a very low investment there could be a huge return. You can write a basic runtime for a full-featured concatenative language in a few hundred lines of C, and a compiler for it in a few dozen lines of Haskell.
- roel_v 15y ago
  'Ease of implementation' is a very low-ranking, I would almost say irrelevant, factor for the utility or uptake of a programming language. So what if there are only a couple of hundred lines of C, you'd still need tens of thousands at the least to provide a useful standard library.
  - loup-vaillant 15y ago
    I tend to think the usefulness of a (standard) library tend to decrease with the size of its interface. Because with more functions, it is harder to learn, harder to find the function you need, and makes programs less accessible because there are so many ways to do the same job. My bet would be a minimal standard library, based on empirically most useful functionality. I very much doubt you'd need more than a thousand lines to implement that (not counting a possibly crap-load of optimizations).

primecommenter 15y ago

I particularly like the example of Literate Roy: https://github.com/pufuwozu/roy/blob/master/examples/sqrt.lroy https://github.com/pufuwozu/roy/blob/master/examples/sqrt.lr.... This example demonstrates some of the language features and syntax: https://github.com/pufuwozu/roy/blob/master/examples/structural.roy https://github.com/pufuwozu/roy/blob/master/examples/structu....

tzaman 15y ago

Why would I use this over coffeescript, that I'm already used to?

tkahn6 15y ago
Some programmers value type safety. That is the niche that Roy fills I believe. I'm certainly excited about it. CoffeeScript is certainly a pleasure to work with but it lacks a type system and static type checking.
- tomp 15y ago
  Also, Roy supports Algebraic DataTypes (ADTs) - i.e. pattern matching. Though I think it takes quite some experience programming in Ocaml/ML/Haskell to fully appreciate its power.