Thanks for taking the time to look into it.
Manfred > Am 22.01.2020 um 03:23 schrieb Paul Schoenfelder > <[email protected]>: > > 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 > > On Tue, Jan 21, 2020, at 1:44 PM, 'Manfred Bergmann' via elixir-lang-core > wrote: >> 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 >> >> >> >> > Am 21.01.2020 um 02:16 schrieb Paul Schoenfelder >> > <[email protected]>: >> > >> > 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 >> > >> > On Mon, Jan 20, 2020, at 10:22 AM, 'Manfred Bergmann' via elixir-lang-core >> > wrote: >> >> 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 >> >> >> >> >> >> -- >> >> 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 [email protected]. >> >> To view this discussion on the web visit >> >> https://groups.google.com/d/msgid/elixir-lang-core/44f07f02-8d4c-4488-93af-0a2915f507de%40googlegroups.com. >> > >> > >> > -- >> > 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 [email protected]. >> > 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. >> >> -- >> 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 [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/elixir-lang-core/134D80AA-A556-49DF-A1D3-B14B9CD4A208%40me.com. >> > > > -- > 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 [email protected]. > 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. -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/C13D81D4-09FA-4F37-A5E5-C082CCF8EF2C%40me.com.
