Access optimizations from Hissssst's compiler

Come on mate. You can’t tell people to “just” use your experimental compiler instead of vanilla Elixir. That is not the “right way” to deal with a code base where the dots are used.

I think we’re safer just to pattern match ourselves or borrow some code from Membrane.

Why do you think so?

Risk. Given the choice between a) a minor performance penalty; b) writing code using pattern matchine style; or c) replacing the language compiler with one written by one bloke whose claims about the Elixir compiler and their own replacement are at times disproven and is not battled hardened, you’d be hard pressed to find many people advising option c. The time investment and risk is unlikely to be worth the cost.

Which makes key access 2-3 times slower

That’s cool, but it would require refactoring a lot of existing code, which sometimes is not that obvious.

I’d like to hear some real examples about my claims about compilation which were disproven.

That’s true, but it is true for every new technology.

Why is that? I mean, compiler is not 100% ready yet, but is in the state which shows that my ideas around performance optimization are working. It just requires some polishing. As soon as it will be ready, there will be no risks, my aim is to provide as-much-as-possible compatibility with existing compiler.

And I think that it is totally fine to advertise not-yet-ready solution, because it will provide some battle-testing by early adopters (one of whom is a member of already mentioned Membrane project), some useful feedback, and might even help me get some money for my work

I guess since it’s a compiler so long as it compiles there is no risk, or does it produce code that could hit runtime exceptions?

That’s an interesting point, I never thought about that! I do feel you would almost have to be trying to write code that would ever hit this scenario, but it sure would be a subtle bug: You happened to pass in an atom instead of a map that also happened to be an erlang module that also happens to have a zero-arity function with the same name as the key you’re trying to access.

And here I am, never using map[:key] or map.key at all…

Every compiler does.

Sorry, terribly worded. I guess I’m asking how different it is from Elixir aside from the optimizations listed. I can always just look at the code.

There are several types of things that can be different

1. Unexpected. I am human, I make mistakes, so I tried to invest a lot of time into making debugging of the compiler as simple as possible.

   • I have made different verbosity levels
   • I made compiler tracing, per-function or per-feature
   • I made automatic github issue submission
   • I’ve made a way for a regular user to peek at what code is generated, but in regular Elixir

2. Expected. And I’ve divided those into four parts:
   2.1 Compatible. And I am trying to make most of the optimizations compatible as much as possible. So that is compatibility in terms of side-effects ordering, in terms of exceptions, and of course in terms of results returned by functions
   2.2 Incompatible, but invisible. This means that my compiler generates different code from what vanilla compiler does, but nobody actually relies on this behaviour or this behaviour changes in Elixir from time to time. For example, my compiler slightly changes module compilation order, but it doesn’t affect anything, unless the user is relying on unspecified compiler behaviour (like reading .beam files during compilation to affect the result).
   2.3 Incompatible, but with workarounds. This is runtime recompilation with appup or relup (recompile in iex is compatible). I will provide a different interface to these problems, in case anybody will ever be using runtime recompilation in prod with Elixir.
   2.4 Incompatible, but which require Elixir patching. And there’s the only one of them, it is exception formatting. Tria regroups functions into modules, but not in a way a developer originally wrote. So function Module.function/2 can actually become TriaGenerated.Module__function/2. And stacktrace would have this ugly signature instead of the original one. I am just going to introduce the patch to the Elixir and make sure that it is accepted in the upstream, which will allow exceptions formatting.

Plus, there is also this tiny case of Incompatible, but useful when my compiler detects errors that regular Elixir compiler wouldn’t. This is extremely rare and can be found only in cases like

x = %{1 => 2}
case x do
  %{^y => ^y} -> :ok # This clause will never match
  _ -> :error
end

Hey folks I moved these posts out of the other thread because we’re now squarely into a discussion about the readiness or not of @hst337’s compiler.

Thanks!