New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

discuss: compiling rawlambda output to javascript #338

Closed
bobzhang opened this Issue Jul 4, 2015 · 11 comments

Comments

Projects
None yet
4 participants
@bobzhang
Contributor

bobzhang commented Jul 4, 2015

This is just for discussion.

We know that there was another backend ocamljs which compiles lambda expression to javascript in 2010. That project was abandoned. However, things have changed a lot since then.

From ocaml side, all ocaml compiler libraries are installed, even driver/main.cmo and driver/optmain.cmo are installed, unlike ocamljs, there is basically no need to patch(or minimal) the compiler to get rawlambda output.

From javascript side, especially with the popularity of nodejs and es6, we can map one ocaml module into one js module. There are other tools like webpack which could bundle all js modules which means we don't even need a js linker, the javascript community is used to having a transpiler in their workflow.

The benefit is obvious, the -drawlambda output preserves most ocaml skeleton, and can be easily mapped into javascript high level constructs, we can generate really readable javascript output with function name preserved.

ocamljs is already a proof of concept that it will work. Since we are doing one module to module mapping, the FFI will be much more friendly. js_of_ocaml is an amazing tool, it can literally make almost any pure ocaml application into javascript, but that still keeps us in a very small community(OCaml is my favoriate language, but I miss javascript community and npm). But if we can generate readable javascript, I think that will be a game changer, it will be attractive to javascript community as well.

Given the similiarity between rawlambda output and javascript ast, I think the required work should be affordable.

@Drup

This comment has been minimized.

Show comment
Hide comment
@Drup

Drup Jul 4, 2015

Member

Do you really think having readable code (and tbh, I doubt you will really have that ...) would make your project more approachable by javascript people ? They still wouldn't be able to modify the sources anyway and they would completely lack the abstractions present on a higher level (lwt code ...).

And anyway, I think it's much more work that you make it sound. It's also more difficult to maintain.

Member

Drup commented Jul 4, 2015

Do you really think having readable code (and tbh, I doubt you will really have that ...) would make your project more approachable by javascript people ? They still wouldn't be able to modify the sources anyway and they would completely lack the abstractions present on a higher level (lwt code ...).

And anyway, I think it's much more work that you make it sound. It's also more difficult to maintain.

@bobzhang

This comment has been minimized.

Show comment
Hide comment
@bobzhang

bobzhang Jul 4, 2015

Contributor

I think having a readable code like coffescript is an approachable goal , especially when you write ocaml code within javascript in mind (such as don't use functors, immutable strings, less exceptions ..)
My point is not to make existing ocaml libraries easily used by javascript which js_of_ocaml already does, is to offer a high quality strongly typed language to javascript community.

Contributor

bobzhang commented Jul 4, 2015

I think having a readable code like coffescript is an approachable goal , especially when you write ocaml code within javascript in mind (such as don't use functors, immutable strings, less exceptions ..)
My point is not to make existing ocaml libraries easily used by javascript which js_of_ocaml already does, is to offer a high quality strongly typed language to javascript community.

@Drup

This comment has been minimized.

Show comment
Hide comment
@Drup

Drup Jul 4, 2015

Member

I don't see the point of a sublanguage of ocaml that doesn't work with half the interesting features of OCaml and with the OCaml libraries. It's not OCaml anymore and you shouldn't try to shoehorn it like that.

There are already numerous good statically typed functional languages that compile to javascript for that, in particular Purescript.

Member

Drup commented Jul 4, 2015

I don't see the point of a sublanguage of ocaml that doesn't work with half the interesting features of OCaml and with the OCaml libraries. It's not OCaml anymore and you shouldn't try to shoehorn it like that.

There are already numerous good statically typed functional languages that compile to javascript for that, in particular Purescript.

@bobzhang

This comment has been minimized.

Show comment
Hide comment
@bobzhang

bobzhang Jul 4, 2015

Contributor

Indeed, purescript is interesting and they did generate readable code and dead simple FFI.

I am not saying that we should only target a subset of ocaml, I mean if you want to generate readable code you should not use some features not available in javascript, this is same with purescript, if you use typeclasses a lot, I don't think they would generate readable js.

Purescript is using eager evaluation strategy which means it will never play nicely with haskell libraries, if purescript generates readable code while play nicely with existing haskell libraries, I would switch to purescript tomorrow. But for OCaml, there is no such problem, this is a big difference in my opinion.

I think generating readable js is a key feature for javascript alternative langauges

Contributor

bobzhang commented Jul 4, 2015

Indeed, purescript is interesting and they did generate readable code and dead simple FFI.

I am not saying that we should only target a subset of ocaml, I mean if you want to generate readable code you should not use some features not available in javascript, this is same with purescript, if you use typeclasses a lot, I don't think they would generate readable js.

Purescript is using eager evaluation strategy which means it will never play nicely with haskell libraries, if purescript generates readable code while play nicely with existing haskell libraries, I would switch to purescript tomorrow. But for OCaml, there is no such problem, this is a big difference in my opinion.

I think generating readable js is a key feature for javascript alternative langauges

@bobzhang

This comment has been minimized.

Show comment
Hide comment
@bobzhang

bobzhang Jul 4, 2015

Contributor

purescript already gains more popularity than ghcjs (63 contributors vs 23 contributors), I think they are doing something right

Contributor

bobzhang commented Jul 4, 2015

purescript already gains more popularity than ghcjs (63 contributors vs 23 contributors), I think they are doing something right

@hhugo hhugo added the question label Jul 8, 2015

@bobzhang

This comment has been minimized.

Show comment
Hide comment
@bobzhang

bobzhang Aug 2, 2015

Contributor

FYI: here is a proof of concept that it is doable
http://zhanghongbo.me/js-demo/
it almost covers the full language (modulo standard library)

Contributor

bobzhang commented Aug 2, 2015

FYI: here is a proof of concept that it is doable
http://zhanghongbo.me/js-demo/
it almost covers the full language (modulo standard library)

@Drup

This comment has been minimized.

Show comment
Hide comment
@Drup

Drup Aug 2, 2015

Member

Partial application is trivially broken.

let f x y = x + y 
let g = f 1
let a = g 2
var f=function(x,y){return x+y;};
var g=f(1);
var a=g(4);
Member

Drup commented Aug 2, 2015

Partial application is trivially broken.

let f x y = x + y 
let g = f 1
let a = g 2
var f=function(x,y){return x+y;};
var g=f(1);
var a=g(4);
@bobzhang

This comment has been minimized.

Show comment
Hide comment
@bobzhang

bobzhang Aug 2, 2015

Contributor

yes, that's easy to fix, the current goal is to get a beautiful output

Contributor

bobzhang commented Aug 2, 2015

yes, that's easy to fix, the current goal is to get a beautiful output

@bobzhang

This comment has been minimized.

Show comment
Hide comment
@bobzhang

bobzhang Aug 2, 2015

Contributor

it does not cover direct tail call either, but I don't think that's a blocking issue

Contributor

bobzhang commented Aug 2, 2015

it does not cover direct tail call either, but I don't think that's a blocking issue

@cornop

This comment has been minimized.

Show comment
Hide comment
@cornop

cornop Sep 12, 2015

@bobzhang I think this project is interesting. Do you have your current progress online?

cornop commented Sep 12, 2015

@bobzhang I think this project is interesting. Do you have your current progress online?

@bobzhang

This comment has been minimized.

Show comment
Hide comment
Contributor

bobzhang commented Sep 12, 2015

@hhugo hhugo closed this Jun 18, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment