4 ms·

I would love an erlang implementation where there can be many versions of the code in memory, where you could re-order the message pattern matching at runtime,

I would love an erlang implementation where there can be many versions of the code in memory, where you could re-order the message pattern matching at runtime, where you can specify arguments to functions in terms of a map, specify the args and the types of that map specification, and have it compile into numbered argument, that way you don't have to add update many many functions to add another argument.

yetihehe 6y ago
You could do that already. You can compile code at runtime from binary (self modifying code) if you need or you could extract that into several dynamically compiled modules and call them based on argument. BUT Different versions of code in memory - that sounds like nightmare to debug. Erlang already stores two versions of newly compile code, old one for processes currently actively using that code and new one for all others. Once all processes jump to new code (by exiting from old function module or calling into new version with module:function call) old code is purged.
toast0 6y ago
> many versions of the code in memory, You can model that today if you script compilation/loading. When loading a module, you could first load it as {?MODULE, ?VERSION} or ?MODULE_?VERSION if we can't stuff a tuple there, and then also load it as ?MODULE, to use when you don't specify a version. The hard part is deciding what version to call when, and passing that through to the call sites. And also, to figure out how to signal a process that you want it to update its version. > where you could re-order the message pattern matching at runtime, Pattern matching order is part of your code, and hot loading is the way to make changes to your code. > where you can specify arguments to functions in terms of a map, specify the args and the types of that map specification, and have it compile into numbered argument, that way you don't have to add update many many functions to add another argument You could do this yourself today as well; a function could check if its argument is a Map and demapify the arguments, or you could make a utility call_function(Module, Function, Arity, Map) that demapifies and calls erlang:apply on the function. Or, you could have your rapidly changing functions all just take Maps; I did that in the past with Proplists.
- JimmyRuska 6y ago
  Thanks for these suggestions! Shouldn't there be a way for the compiler to know enough to convert the map to positional arguments, so long as the map params could be put into a spec? Something like that would be super nice, because I think tail calls in Erlang cost nothing so long as you keep the same arg positions. Having a map is always a convenient way of starting a function and evolving it, but having it with a few more constraints and with equal performance would be better. If I'm not mistaken I remember dart made a similar optimization.
  - toast0 6y ago
    If the functions are exported, the compiler wouldn't be able to optimize calls. Dynamic modules and hotloading means there's no expectation that what you had when compiling is what you're running against in production. If they're in the same compilation unit, the newer SSA based optimizer might do some cool stuff for you; it's always interesting to look at the optimized code that comes out of compiling/loading. In general though, I would tend not to worry about efficiency of passing a map instead of traditional arguments. Most likely there's other, bigger, things to worry about; usually finding the right communications patterns and algorithms makes a bigger difference.

yetihehe 6y ago

You could do that already. You can compile code at runtime from binary (self modifying code) if you need or you could extract that into several dynamically compiled modules and call them based on argument. BUT Different versions of code in memory - that sounds like nightmare to debug. Erlang already stores two versions of newly compile code, old one for processes currently actively using that code and new one for all others. Once all processes jump to new code (by exiting from old function module or calling into new version with module:function call) old code is purged.

toast0 6y ago

> many versions of the code in memory, You can model that today if you script compilation/loading. When loading a module, you could first load it as {?MODULE, ?VERSION} or ?MODULE_?VERSION if we can't stuff a tuple there, and then also load it as ?MODULE, to use when you don't specify a version. The hard part is deciding what version to call when, and passing that through to the call sites. And also, to figure out how to signal a process that you want it to update its version. > where you could re-order the message pattern matching at runtime, Pattern matching order is part of your code, and hot loading is the way to make changes to your code. > where you can specify arguments to functions in terms of a map, specify the args and the types of that map specification, and have it compile into numbered argument, that way you don't have to add update many many functions to add another argument You could do this yourself today as well; a function could check if its argument is a Map and demapify the arguments, or you could make a utility call_function(Module, Function, Arity, Map) that demapifies and calls erlang:apply on the function. Or, you could have your rapidly changing functions all just take Maps; I did that in the past with Proplists.

JimmyRuska 6y ago
Thanks for these suggestions! Shouldn't there be a way for the compiler to know enough to convert the map to positional arguments, so long as the map params could be put into a spec? Something like that would be super nice, because I think tail calls in Erlang cost nothing so long as you keep the same arg positions. Having a map is always a convenient way of starting a function and evolving it, but having it with a few more constraints and with equal performance would be better. If I'm not mistaken I remember dart made a similar optimization.
- toast0 6y ago
  If the functions are exported, the compiler wouldn't be able to optimize calls. Dynamic modules and hotloading means there's no expectation that what you had when compiling is what you're running against in production. If they're in the same compilation unit, the newer SSA based optimizer might do some cool stuff for you; it's always interesting to look at the optimized code that comes out of compiling/loading. In general though, I would tend not to worry about efficiency of passing a map instead of traditional arguments. Most likely there's other, bigger, things to worry about; usually finding the right communications patterns and algorithms makes a bigger difference.