fix(compiler): disable automatic uncurrying

[nicobao]

Closes #44 I am not sure exactly what is expected. This is what I am working on at the moment.

[michallepicki]

I think (I may be wrong) because function body code generation and typespec generation are currently separate, the next thing that will be needed here, is returning an anonymous function in function application translation when there are less arguments provided than the function expects. To see how many arguments a function expects I think we already have arity in that clause in the Erlang AST here so we don't need to call Uncurry.uncurry_tarrow, but read the arity from there and compare with the length of args

[michallepicki]

So I think what I'm proposing is to keep the uncurrying, but do a little bit of work detecting when additional anonymous function wrapper is needed instead. What do you think about it @nicobao @ostera ? Do you think it could work?

[nicobao]

Hi, I look at it this evening or tomorrow evening and let you know. I have a problem with my computer I need to reinstall it... I read your previous message and I think it makes sense, however I'd need to continue diving into the source code to really understand it. I was starting adding print here and there to understand what's going on, because atm I'm a little lost, and I haven't put enough time and energy to get it through as of now. That being said - if you feel like doing it yourself right now, feel free to edit that branch directly (if you can) or send another PR. I have no problem with it!

To be clear, as of now my patch doesn't solve anything... :/ Could you provide examples as to what you expect the Erlang compilation to look like?

Le mar. 30 mars 2021 à 18:55, Michał Łępicki @.***> a écrit :

So I think what I'm proposing is to keep the uncurrying, but do a little bit of work detecting when a single anonymous function wrapper is needed instead. What do you think about it @nicobao https://github.com/nicobao @ostera https://github.com/ostera ? Do you think it could work?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/AbstractMachinesLab/caramel/pull/90#issuecomment-810421098, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALBYMIYLYBFIWWVL36MM3RTTGH7AJANCNFSM4Z6CUGVQ .

[michallepicki]

I looked into this angle, it might work because the information we would need is in the typedtree, but with the current data structures we lose the arity information for function references that are just local identifiers here, so we don't have it available here. It would be nice to carry over additional type information (in this situation, the arity) for those identifiers. I am not sure if this is something that would live in the Erlang AST or it would be an additional accumulator in mk_expression

[michallepicki]

And in addition to that we would need to know when other expressions are actually functions as well, and know their arity, e.g. we would know how many arguments a partially applied Expr_apply needs as well when resolving the next application... It would be messy and almost begs for an intermediate format between the typedtree and the erlang AST (typederltree? :D) but I think it's possible

[michallepicki]

@nicobao I think I got it working in #92 , just need to fix specs :)

[leostera]

Hi! 👋🏽 since I'm currently not working on and have no plans to continue working on this version of the compiler, I'll close this PR. Thanks a lot for your contribution 🙏🏽