Roy: Small functional language that compiles to JavaScript(github.com)
github.com
Roy: Small functional language that compiles to JavaScript
https://github.com/pufuwozu/roy
32 comments
I would love to see this. But there's two problems with it:
1. Bytecode formats are never completely language independent - there's always a feature or change that would make language X better
2. Browser vendors will never be able to agree on a bytecode format
So, to solve those problems, I've been thinking the following approach might work:
1. Write a JavaScript interpeter for a fairly language-independent bytecode
2. Write some small languages, targeting that bytecode (something for everyone: Haskell-like, C-like, Lisp-like, Forth-like, etc)
3. Hope people start writing more languages to target the bytecode
4. Hope that it's hard for browser vendors to ignore implementing the bytecode natively - for performance reasons
This way we avoid committees and just get it done. Let me know if you think this is a good or bad idea. I'm very willing to work on it.
1. Bytecode formats are never completely language independent - there's always a feature or change that would make language X better
2. Browser vendors will never be able to agree on a bytecode format
So, to solve those problems, I've been thinking the following approach might work:
1. Write a JavaScript interpeter for a fairly language-independent bytecode
2. Write some small languages, targeting that bytecode (something for everyone: Haskell-like, C-like, Lisp-like, Forth-like, etc)
3. Hope people start writing more languages to target the bytecode
4. Hope that it's hard for browser vendors to ignore implementing the bytecode natively - for performance reasons
This way we avoid committees and just get it done. Let me know if you think this is a good or bad idea. I'm very willing to work on it.
Agreed. This sounds plausible. Feel free to contact me by email if you need another developer—I’ll offer what time I can—or just a sounding board.
count me in!
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.
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.
'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.
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).
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).
In my experience, what matters more than the size of the interface of the standard library, is its organization. For example, I can't really read Clojure code, mainly because I have no idea what the various functions do. On the other hand, Python has a huge standard library, but usually the name of the function, in the context of the module (as in urllib2.urlopen or json.loads) or the name of the method in the context of the class of the object it belongs to (e.g. [1, 3, 2].sort()) is enough to figure out what the functionality is.
Though I wish I didn't have to type `from datetime import datetime` all the time...
Though I wish I didn't have to type `from datetime import datetime` all the time...
It’s relevant because it’d be much easier to get the major browsers to implement a minimalistic language than another JavaScript. Simpler implementation means fewer security concerns and more time to focus on things that are directly relevant to programmer experience, such as that standard library.
In my opinion, it's a little too late. JavaScript is it. If you consider how Chrome runs some JavaScript as machine instructions then it isn't that far off from the situation you describe.
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 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:
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.
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.
Sure you could: Haskell can compile to Javascript :D https://github.com/pedromartins/ghcjs
http://ocsigen.org/js_of_ocaml/
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/ for a rigid body motion model in an OCaml WebGL game compiled to JS.
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/ for a rigid body motion model in an OCaml WebGL game compiled to JS.
> 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/ 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/). 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.
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/ 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/). 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 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 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
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
> 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.
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
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
> 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.
>> 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.
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 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 particularly like the example of Literate Roy: 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/structu....
previous discussion: http://news.ycombinator.com/item?id=3277027
not sure how much has changed since then.
not sure how much has changed since then.
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
The page doesn't work hard to sell me on the idea.
Welcome any ideas on how to make the README better. Better yet, I'll very happily accept pull requests ;)
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/ =D
Why would I use this over coffeescript, that I'm already used to?
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.
CoffeeScript is certainly a pleasure to work with but it lacks a type system and static type checking.
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.
Though I think it takes quite some experience programming in Ocaml/ML/Haskell to fully appreciate its power.
Someone shares this every other month
I wouldn't consider it unless it compiled to coffee script first.
Isn't there a js to coffee script compiler? You could compile from Roy -> js -> coffee script -> js if you really wanted to.
(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)