<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:courier new,monospace">Hello!</div><div class="gmail_default" style="font-family:courier new,monospace"><br></div><div class="gmail_default" style="font-family:courier new,monospace">Calling Elixir from Erlang is similar problem to calling C++ from C. Possible? In certain cases: yes, I've done that, the (mangled) function name looks ugly - but there's no way to instantiate C++ templates from C as the C compiler has no idea about them. Similarly the Erlang compiler has no idea about Elixir macros.<br></div><div class="gmail_default" style="font-family:courier new,monospace"><br></div><div class="gmail_default" style="font-family:courier new,monospace">However, I have an even crazier idea: rebar, mix, hex, etc. know only about (some of the) BEAM-using languages. But we live in multilingual times, so a project might use other languages (especially JavaScript) too. Wouldn't it be cool if a single tool could manage those dependencies, maybe even generate Erlang/Elixir server code and JavaScript client code from the interface description... I feel like reinventing CORBA and its IDL :-)<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Devon Estes <<a href="mailto:devon.c.estes@gmail.com">devon.c.estes@gmail.com</a>> ezt írta (időpont: 2019. márc. 24., V, 19:46):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div dir="auto">What if it was allowed for package maintainers to publish pre-compiled BEAM files to Hex? I would imagine that everyone who is pushing packages to Hex also has the ability to compile those packages on the machine they’re using to publish.</div></div><div dir="auto"><br></div><div dir="auto">There are clearly a whole ton of reasons why that could be a bad idea (and probably wouldn’t even work for a large chunk of macro-heavy Elixir libraries that rely on Mix configuration to be present at compile time), but it would also make for the easiest story for cross-language library sharing.</div><div dir="auto"><br></div><div dir="auto">It pushes the compilation step from the user of a package to the maintainer of that package, but if CLI tools knew where to put these pre-compiled BEAM files so users didn’t have to think about it, then it could make usage of some libraries much easier.</div><div dir="auto"><br></div><div dir="auto">It could be an optional thing for those maintainers who want to go the extra mile to make cross-language use of their packages easier. I know I’d be happy to take that extra step when publishing new versions of Benchee if it meant Erlang/LFE/etc. users could have an easier time using it.</div><div dir="auto"><br></div><div dir="auto">Or it could just make everything worse and more complicated 😇 but it seemed like it was worth bringing up.</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Bryan Paxton <<a href="mailto:starbelly@pobox.com" target="_blank">starbelly@pobox.com</a>> schrieb am So. 24. März 2019 um 17:50:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
On 3/24/19 11:26 AM, Joe Armstrong wrote:<br>
> On Sun, Mar 24, 2019 at 1:54 PM Fred Hebert <<a href="mailto:mononcqc@ferd.ca" target="_blank">mononcqc@ferd.ca</a>> wrote:<br>
>> On 03/24, Joe Armstrong wrote:<br>
>>> I for one welcome all the things the Elixir folks are doing - but I<br>
>>> have noticed the following:<br>
>>><br>
>>> - Elixir folks are re-using Erlang libraries<br>
>>> - Erlang folks are not (it seems to me) reusing Elixir libraries<br>
>>><br>
>>> The "how to call Erlang from Elixir" documentation is great - the<br>
>>> opposite "how to call Elixir from Elixir" is not (or have I missed something)<br>
>>><br>
>>> Things like nerves, scenic, Phoenix etc. look great to me - but seem to be used<br>
>>> almost exclusively by Elixir folks.<br>
>>><br>
>>> Has anybody made, for example, a pure Erlang interface to scenic?<br>
>>><br>
>> Well, there are some limitations there.<br>
>><br>
>> - You can use mix to build your Erlang project and then use Elixir in<br>
>>   there<br>
>> - You can use rebar3 with the rebar_mix plugin (along with an Elixir<br>
>>   install) to build Elixir dependencies (see<br>
>>   <a href="https://github.com/tsloughter/rebar_mix" rel="noreferrer" target="_blank">https://github.com/tsloughter/rebar_mix</a>)<br>
>><br>
>> But in all cases, you will not necessarily be able to use Elixir code<br>
>> when it heavily relies on macros at the call-site rather than<br>
>> internally. So for example, a lot of usage of _plugs_ in Phoenix rely on<br>
>> macros running within the controller compilation step to read the<br>
>> declaration and inline them "somewhere??" with no obvious way to do it<br>
>> without the macros.<br>
>><br>
>> That specific stuff that relies on macros in _your Elixir code_ cannot<br>
>> be ported to work with _your Erlang code_, because, well, we don't have<br>
>> the same macro mechanisms available. Similarly, Erlang parse transforms<br>
>> may not remain fully applicable to Elixir modules in the future.<br>
>><br>
>> This means that Ecto, which is a huge part of a lot of web framework<br>
>> usage, also won't be usable for Erlang users, since it is very<br>
>> macro-dependent.<br>
> Interesting - I'd imagined that after compilation you'd just end up<br>
> with beam code files after which you could call them from Erlang ...<br>
><br>
> Could this be rectified by a "better" macro processor for erlang - more<br>
> in the style of the Elixir macro processor ???<br>
<br>
<br>
 I'd like to add on top of this the smallest part of the problem, but<br>
what I see as a problem none the less...<br>
<br>
'ManyWouldPrefer':'not_to_have_to_do_this?'(Please)<br>
<br>
<br>
As stated, smallest of all the problems, but whether we like it or not<br>
UX matters. This not only applies to using Elixir but LFE, etc.  The<br>
only solutions to that problem that I could think of involve perhaps too<br>
much trickery, not really sure how the community feels about said<br>
trickery though. That is to say, to squash this problem effectively<br>
you'd have to translate/generate modules in other BEAM languages to pure<br>
erlang (or generate pure erlang interfaces), prefix the module names<br>
with 'elixir_' or 'lfe_' and then hack the compiler, shell, etc. to<br>
treat this as special so that in the end we would be using<br>
many_would_prefer:not_to_have_to_do_this(Please). Or instead of said<br>
trickery, elixir_many_would_prefer:not_to_have_to_do_this(Please).<br>
<br>
 This brings me to another point and something I didn't understand until<br>
recently. Yes, with the rebar_mix plugin and so forth you end up using<br>
the artifact (beam file) compiled by the given beam language. As Tristan<br>
said, this requires you to have Elixir installed... it's not that big of<br>
a deal perhaps... but say you would simply like to bring in emj's<br>
Decimal lib as pointed out by Tristan... Do you really want to bring in<br>
all of Elixir just to use said lib? It seems a bit much. This is<br>
precisely why I "ported" Elixir's Version module to pure Erlang. Now,<br>
you don't need to bring in Elixir to use a fully compatible semver<br>
lib... but it's wrong... I felt bad in doing it... there is now more<br>
code in the world and that's the last thing we need.<br>
<br>
 What I want (dreams and wishes):<br>
<br>
  Universal BEAM/Erlang libs. It would be the bees knees and a HUGE win<br>
for the entire community for all to seamlessly be able use erlang,<br>
elixir, lfe, <insert all the other BEAM langs here> without having to<br>
bring in the entire language. If I'm not using the language directly,<br>
why do I need that? How this could be achieved, have no idea, erlang<br>
core perhaps... perhaps it's more complicated than that... <br>
<br>
<br>
--<br>
<br>
Bryan<br>
<br>
<br>
><br>
>> But if you look at other libraries (or frameworks) such as Raxx<br>
>> (<a href="https://github.com/CrowdHailer/raxx" rel="noreferrer" target="_blank">https://github.com/CrowdHailer/raxx</a>), then this is a framework that is<br>
>> fully written in Elixir, yet usable from Erlang (there's a demo at<br>
>> <a href="https://github.com/CrowdHailer/greetings-ace-raxx-erlang-example" rel="noreferrer" target="_blank">https://github.com/CrowdHailer/greetings-ace-raxx-erlang-example</a>).<br>
>> Similarly, a library such as <a href="https://github.com/ericmj/decimal" rel="noreferrer" target="_blank">https://github.com/ericmj/decimal</a> for<br>
>> arbitrary precision arithmetic should be fine to use.<br>
>><br>
>> This stuff has been available to rebar3 users since around late 2018, so<br>
>> I assume it has seen slow adoption due to its being rather new, but we<br>
>> (rebar3 maintainers) are confident that this bigger interplay is worth<br>
>> it and should be seeing adoption over time.<br>
>><br>
>> Finally, the stuff we're setting up with the Erlang Ecosystem Foundation<br>
>> is also aimed at making language interplay easier for all languages of<br>
>> the ecosystem.<br>
> This would be great<br>
><br>
> /Joe<br>
<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div></div>-- <br><div dir="ltr" class="gmail-m_6155195364334524308gmail_signature"><div dir="ltr"><br>_________________<br>Devon Estes<br><a href="http://203.559.0323" target="_blank">203.559.0323</a><br><a href="http://www.devonestes.com" target="_blank">www.devonestes.com</a><br><br></div></div>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div></div>