Lift decls js backend

[rbarreiro]

I have made a new js backend based on the liftDecls.

It is passing all the tests. And works much better with foreign functions that take functions as arguments,
This test https:/rbarreiro/idrisjs/blob/master/tests/t8.idr is not working as expected with the current backend.

I also prefer the javascript generated directly from lifstDecls to the one produced by the current backend.

Can you please review it?

[david-christiansen]

Nifty! A couple of questions, as I don't have time to dig into code just right now:

0. Are you planning on maintaining this on an ongoing basis?
1. What do you see as the major design trade-offs where this backend differs from the current one?
2. How do you handle tail call elimination?
3. Is this backwards-compatible with e.g. FFI code written in the previous backend?

[melted]

Thanks for the PR!

I will start a review, it's going to take a while. Others shouldn't hesitate to take a look too :-)

[rbarreiro]

0. Yes
1. The only thing worst I can think of is that width this backend we can have stackoverflows for mutual recursive tail calls. It generates the code faster, less awfull javascript generated(subjective), smaller after closure compiler, working with ffi involving lambdas and I did not benchmark it, but I believe it runs faster.
2. Replace self tail calls width loop
3. I tried and I believe i succeed.

[melted]

Can you add a commit that updates the CHANGELOG?

[melted]

I looked at the Travis outcomes:

• Stylize failed. I ran stylize.sh and it rearranged the imports a bit. So just install stylish-haskell and run that and commit.
• A bigger deal is that GHC 7.6 and 7.8 builds failed because they don't support DeriveAnyClass.
• The javascript tests failed, as far as I can see just because node screamed about 'Use of const in strict mode'. Likely Travis comes with an old node.

[melted]

Change to camelcase, here and the other underscored names in the file

[melted]

Change these names to camelcase

[melted]

change to camelcase

[rbarreiro]

I have pushed some changes to address these problems. Regarding the CHANGELOG, I need to create a new Header "New in ...", right? What version?

[melted]

Just put it on the top under a Tool Updates header and edwin will fill in version when he releases.

…

17 maj 2017 kl. 10:38 skrev Rui Barreiro ***@***.***>: I have pushed some changes to address these problems. Regarding the CHANGELOG, I need to create a new Header "New in ...", right? What version? — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub, or mute the thread.

[melted]

I'll merge this tomorrow unless there are objections.

@edwinb any comments?

[melted]

Thanks for the contribution!

[ahmadsalim]

This is great!

@be5invis I think I remember you may have had some custom optimizations for a version of this backend. Could you please consider backporting the improvements here?

[be5invis]

@ahmadsalim There are some, like uncurrying, data type specialization, custom rewriting rules, etc.
→ https:/be5invis/idris-codegen-es

[be5invis]

@ahmadsalim The differences are:

• Idris-codegen-es has data type specialization, that maps Idris’ data types into JavaScript equivalent.
• Idris-codegen-es uses If tree to generate Cases, while @rbarreiro’s uses Switch statement. Using Switch would be problematic when you want to specialize data types (like turning Idris True/False into JavaScript true/false)
• Idris-codegen-es has special rewriting rules to eliminate silly overheads caused by data types.
• Idris-codegen-es targets ES6...

[ahmadsalim]

@be5invis That sounds great!
Would it be possible for you to try and synchronize these changes with the new backend proposed here? (E.g. by making a new PR that adds your changes?). I think it would be very useful to have these optimizations!

[be5invis]

@ahmadsalim I'd like to open another PR.

[ahmadsalim]

@be5invis Yeah, that is what I meant :). But I think there has been some updates to this backend that fixes some issues, and it would be nice if your work incorporated the changes.

[be5invis]

@ahmadsalim The compiler part and the FFI/primitive part are, well, pretty separated.
My modifications are mainly on the compiler part -- making the code faster, more beautiful, etc.

[ahmadsalim]

@be5invis I see, in any case you are welcome to submit a new PR.

[be5invis]

@ahmadsalim I'd like to add the ES codegen entirely into Idris first and move the FFI/primitive thing into ES...
Idris-codegen-ES changed A LOT. REALLY, A LOT.

[ahmadsalim]

@be5invis I see, I was not aware on the degree things changed.

I think a suggestion could be that you fork the latest version of Idris, add your changes there, move the FFI/primitives and then make the PR if possible. Do you agree?

[be5invis]

@ahmadsalim I'll do that.

[be5invis]

@ahmadsalim The current version already has uncurry (though... looks not beautiful 😞)
I'd like to do those:

• Separate JsAST into JsExpr and JsStmt
• Data type specialization
• Rewriting

[comonoid]

Idris-codegen-es targets ES6...

Good news?... Maybe...
Sorry for my dumb question, but...
Would you please tell me where can i find something
about browser compatibility with this ES6 subset?

[be5invis]

@comonoid
https://kangax.github.io/compat-table/es6/

[rbarreiro]

Regarding ES6 in practice, depending on the features the closure compiler can convert ES6 to ES5. But you might have some trouble with the CI. I was using "const" and it failed the tests.

[ahmadsalim]

@be5invis I think the optimizations sound good.
Perhaps, you can coordinate with @rbarreiro about the changes in code organization (refactoring), since I am not completely into the details.

[comonoid]

Also, i was remembered about babel.
So, as i can see now, generally, ES6 is not a problem now ;-)
Thanks!

[rbarreiro]

@be5invis I gave a quick look to repo and I liked what you did in JsAST.hs, JsName.hs

Regarding the rewriting, do you think you can do it creating less complexity on the cgBody function, maybe using uniplate and some replace rule with LForeign, what do you think? If it is not possible we can discuss further.

I would not like to make cgBody more complex, it is already a bit hard to read. What do you think?

[rbarreiro]

I also prefer your solution to uncurry.

[rbarreiro]

Just one question, I moved the lambdas to the partial application functions, because in-line it raised problems with the tail call optim, I was creating new lambdas using the variables in the loop, so I was changing the lambdas by changing the variable in the loop. How did you addressed this?

[rbarreiro]

@be5invis One more question, you changed the all uses of javascript switch statement to if?
Why?

[be5invis]

@rbarreiro For data type specialization.
In idris-codegen-es, nullary data construction would be specialized into a number, and built-in types like True and False would be mapped into JavaScript true and false. So, yes, it need to be changed into if.

[rbarreiro]

But you changed it for constructors identified by integers also? Em 23/05/2017 13:55, "Belleve Invis" <[email protected]> escreveu:

…

@rbarreiro <https:/rbarreiro> For data type specialization. In idris-codegen-es, nullary data construction would be specialized into a *number*, and built-in types like True and False would be mapped into JavaScript true and false. So, yes, it need to be changed into if. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3821 (comment)>, or mute the thread <https:/notifications/unsubscribe-auth/AAM9NsHA8jdEJApwqRV2aPLtrVZgdm_Sks5r8tcjgaJpZM4Nc1y0> .