
Roy: Small functional language that compiles to JavaScript - DanielRibeiro
https://github.com/pufuwozu/roy
======
overgard
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)

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

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

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

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

~~~
pufuwozu
_> 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.

~~~
silentOpen
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?

~~~
pufuwozu
_> ... 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.

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

------
gerggerg
previous discussion: <http://news.ycombinator.com/item?id=3277027>

not sure how much has changed since then.

~~~
pufuwozu
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>

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

~~~
pufuwozu
Welcome any ideas on how to make the README better. Better yet, I'll very
happily accept pull requests ;)

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

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

------
obilgic
Someone shares this every other month

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

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

