[Proposal] IEx - add command to change module context, like in-module

[Manfred Bergmann]

This is along the lines of what Common Lisp or Clojure can do with (in-package) or (in-ns).

This tremendously helps prototyping code in the repl.

Currently IEx doesn't allow that and a module definition always has to be re-evaluated fully.

With something like 'in-module' I could change into a module context and add functions, macros dynamically.

Manfred

[Paul Schoenfelder]

I think the problem here is in how modules are compiled. Elixir modules are required to be defined in a single translation unit (i.e. a file, or an expression in the REPL). CL/Clojure modules on the other hand, can be defined in more than one translation unit.

To support what you are asking for, the Elixir compiler would have to be modified to support multiple translation units per module. That's non-trivial to put it mildly. One obstacle at least is that Elixir uses Erlang to compile modules internally, and Erlang doesn't support multiple translation units either. Another obstacle is that it breaks dependency tracking, since a module can never be fully "closed" until the whole program has been compiled. There is also the question of what to do when attached to a running application - can those modules be extended from the REPL? If so, that carries its own set of problems. Perhaps it would be enough to support it just for modules defined in-memory, in the REPL - but if the use case is that narrow, you'd be better off just writing the module in your text editor and reloading it any time you make a change, rather than editing in the REPL.

It's theoretically possible I think, but given the amount of effort it would take, it doesn't seem like the potential benefits are worth it. My own take: I don't think it is a good thing generally to allow defining a module in multiple translation units, aside from the complexity it introduces to the compiler, it also imposes burdens on the reader of some code - you never know if you have the whole thing in front of you. I don't think it would be possible to add support just in the REPL, without it bleeding into the language generally.

Paul

--

You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.

To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/44f07f02-8d4c-4488-93af-0a2915f507de%40googlegroups.com.

[Manfred Bergmann]

Fair enough.
This feature shouldn’t bleed into the language.
And from your description it seems to be quite an effort to implement this.

Elixir has enough other things to offer.
Regarding Erlang VM, I know that Clojerl (the Clojure port for Erlang VM) can do this as well. I’m not certain how this was tackled, but it works.


Manfred

> To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/831f6aa0-e234-4137-a0c1-ba9666728109%40www.fastmail.com.

[Paul Schoenfelder]

I took a look, and it seems like Clojerl maintains its own modules in memory, only compiling them to BEAM files when necessary. It extends modules by extending it’s in-memory representation, which gets compiled to an anonymous Core Erlang module, and allows extending already compiled modules without overriding the original on disk (if one is present).

The downside is that I’m not sure the approach is extendable to Elixir, since the way Clojerl handles it is deeply intertwined with its compiler.

Paul

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/134D80AA-A556-49DF-A1D3-B14B9CD4A208%40me.com.

[Manfred Bergmann]

Thanks for taking the time to look into it.


Manfred

> To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/11d628bd-9019-48b9-999c-62e6f59f65f0%40www.fastmail.com.