Compile LFE to Core Erlang or Erlang AST/
Robert Virding
While the syntax of core is relatively fixed and there is a module, cerl, for building its AST its meaning and how erlang is translated to it sometimes changes. A recent example was how boolean operators in guards were represented in core was changed and suddenly all LFE guard tests suddenly succeeded (it has been fixed).
So what would the effects of compiling LFE to Erlang instead of core?
Pro:
- It would be easier and faster to adapt to newer versions of Erlang and add new features.
- We would always get the latest features in the compiler.
Cons:
- Guards would now become simpler tests like in erlang and not allow things like if and progn.
- Records could now become much more a part of the base language and need some core LFE forms, though this may be fixable.
- Erlang is in some ways a more restricted language than core.
Neither/both:
- We would get a lot of features from the Erlang compiler for free like parse transforms at another level than today. This could be good but could cause some confusion.
Elixir compiler to erlang AST. I have understood that they intend to bypass the first passes in the erlang compiler, call the core generator themselves and call the erlang compiler with core. The erlang compiler is very=y open and allows you to do this.
There is an experimental github branch called `erlang-ast` which generates erlang AST. It would be interesting if people could test there code using this and then report back with the results to get some feel for problems which arise.
mko_io
I understand the maintainability is the main reason for you to consider to compile to erlang ast, but now lfe is 10 years old, mature and has its own elegant and beauty(even compare to the classic erlang, prolog based syntax), I think more and more people would discover it and helping us to maintain the compatibly issue. Since the major version of OTP changes only once a year, we could have plenty of time to adapt to the changes.
BTW, I'm thinking about the using Webassembly, as an alternative backend to core erlang. It's widely available platform(browser, ios, android using webview or javascriptcore). Since Webassembly is a stack machine, it's should be easily generate code from core-erlang, and someone already made a forth version running on it. I think compile core-erlang to forth should be easier than full fledged erlang. And the coming features of webassembly make it even better target for LFE:
among them tailcall and GC support are nice. Using WAForth as complement to the LFE is very similar to write C as NIF for Erlang. I think this could make LFE popular since it cover both server and client side. Although there is already ElixirScript for the same purpose, but it's only compile to JS, not webassembly, and it doesn't even have receive to build basic erlang concurrency.
So I vote for sticking with core-erlang, and find a way to keep it future proof with OTP(Although I'm very keen to help, but I'm not skillful enough to take this task) and propose to compile core-erlang to webassembly to promote LFE/Erlang to front end community
Duncan McGreggor
--
You received this message because you are subscribed to the Google Groups "Lisp Flavoured Erlang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lisp-flavoured-erlang+unsub...@googlegroups.com.
To post to this group, send email to lisp-flavoured-erlang@googlegroups.com.
Visit this group at https://groups.google.com/group/lisp-flavoured-erlang.
For more options, visit https://groups.google.com/d/optout.