Charles Oliver Nutter
I have an idea to statically compile mruby applications to native code with hardly any dynamic dispatch. I need to make mruby for JVM, apply my secret trick, and compile to native with GraalVM. Result would be tiny and very, very fast. Need to find a sponsor.
Apr 24 at 8:18amBuffer
Show threadd@nny disc@Apr 24
@headius so nice that graalvm has come so far. was such a difficult approach a while back
Show threadCharles Oliver NutterApr 24
@hipsterelectron Native image is only useful for a closed world but I think I have a way to compile Ruby so it would be fully static. I experimented with it years ago but never took the idea very far.
Show threadd@nny disc@Apr 24
@headius ahhhhhhhh ok i see the vision now!!!
Show threadgkrnoursApr 24
@headius @hipsterelectron from memory, erlang spend a year on "does adding typing make you program less likely to crash" and the answer they found was "I can turn architecture independant bytecode into architecture specific bytecode and get a 20% speed boost". I guess architecture specific bytecode is kinda the same as native?
Show threadd@nny disc@Apr 24
@gkrnours @headius i believe so. charles has a very strong opinion about gradual typing though ;)
Show threadgkrnoursApr 24
@hipsterelectron @headius at least gradual typing involve running a type checker. I've known people who write the typing hint but don't run type checker.
IMO, typing is the job of a type inference machine and it's super nice to have to make sure you don't break you function signatures.
Show threadd@nny disc@Apr 24
@gkrnours @headius i am more of a runtime type checking enthusiast and i think this has several benefits including being user-extensible as well as dovetailing more naturally with JIT approaches (if JIT is available to the process itself—i like very much how elisp exposes libgccjit)
Show threadd@nny disc@Apr 24
@gkrnours @headius type inference in that context is interesting. i'm not sure how to achieve it
Show threadgkrnoursApr 24

@hipsterelectron @headius fine grained static type inference?
Like your codebase define class C with method a, you have a function f taking an object o and call method a on it. A "dumb" type inference could say "function f take an argument of type C". A fine grained one could define an interface I with method a and say "f take an arg of type I".

then if you monkey patch at runtime, you can get warning if you don't respect the interface. As this will break anyway.

I guess.

Show threadd@nny disc@Apr 24
@gkrnours @headius i was definitely thinking this way. that makes sense!
Show threadCharles Oliver NutterApr 24
@hipsterelectron @gkrnours In this case, mruby is a much more restrictive subset of Ruby and does not have runtime monkey patching and only limited reflective capabilities. It should be very easy to statically prove the entire application.