A VM for crystal about charly HOT 6 OPEN

Hey,

It would be definitely possible. The tricky parts would be C-interoperability and basically all the parts which use some form of assembly.

Anyway, are slow compilation times really a problem with Crystal? Recompiling Charly takes about 1.3 seconds for me (unoptimized build), which is extremely fast in my opinion.

I don't really see a need for an interpreted version of Crystal, but if there is a strong desire from the community for such a project to be developed, I'd love to help out wherever I can!

Are there other people who want this, maybe even from the core-team?

from charly.

Hello!

I'm basically in full agreement with what RX14 has said. I really don't know enough about the internals of the Crystal compiler to know what is and isn't possible (e.g., with templating, open types, etc.), but the idea of using the same front-end and just swapping the codegen for an interpreter sounds like the right direction.

I have a lot of questions I'd have to work through to really get an idea of what's possible here, but I'd definitely be willing to help out/continue discussions/etc.

from charly.

Also we don't have to rewrite all, we can reuse the current lexer, parser and std-lib, just replacing the code-gen by a custom VM (I have no idea how to do it 😅 )

from charly.

It would be definitely possible.

Oh, great! 🎉

The tricky parts would be C-interoperability and basically all the parts which use some form of assembly.

Maybe we can add some warning for this, saying something like: if you want to use this feature you should use crystal build instead or maybe using JIT compiling or similar for this. (I guess Julia lang does something similar)

@KCreate I had the idea because I was asking for a true REPL for crystal, and I got a very interesting response from @RX14 :

the problem was never being compiled
nobody ever said that
the problem has and has always been the type system

Then he wrote some nice comments:

Since you can reuse the existing compiler
What you'd do is pass the whole program through most of the existing crystal compiler
And instead of Codegen use the existing AST in a vm
It'd be slow as shit but who cares
Every time you make an update youd reconstruct the AST for the whole program again
Making an interpreter with no checking (its already been done by the compiler) is far easier than making one from scratch

So, the problem is not because crystal slow compilation (sometimes is very slow, though), but because the type system.

my observation is that the compiler isn't actually that slow
and the compiler being slow isn't the problem
you just run "half" the compiler
even for a moderately sized application
you should be able to do hot reload with this
icr is uselss to me
what I want is the ability to use it as an in-program debugger
and possibly for hot-reload

Ref: https://gitter.im/crystal-lang/crystal?at=5ab00ef5f3f6d24c689220d7

from charly.

Also, There is Myst a nice dynamic, interpreted, functional language made with crystal by @faultyserver

Maybe he can share his opinions about a VM for crystal as well

from charly.

Interesting post here: https://www.reddit.com/r/crystal_programming/comments/91r8im/crystal_has_a_compilation_issue/

from charly.