tadeuzagallo
tadeuzagallo on Hacker News
That's not all, there's the cost of (down)loading the dead code, and startup cost for loading the unoptimised cost. Even more critical when you consider environments where you can't JIT, like React Native on iOS for instance, which was one of the many motivations for Prepack AFAIK.
As usual, for fun and learning, but also to use the language and identify what is more critical to improve.
It was a lot of fun indeed!
> What will Verve do well, that no (major) language does well?
I'm always thinking about that, and I honestly wouldn't write a "proper" language (as in working on it full time, and expecting people to really adopt it) without having an answer for that. Nonetheless, I still see the value in writing things that are not ground-breaking, for the sake of learning. Just reading about compilers and PLT without any practice was really hard for me, and working on this language has been super helpful from a learning perspective.
Have you read the blog post? It explains why I won't use LLVM
and says that the interpreter is written in GAS x86_64.
And I'm not "pitching my software", I'm sharing my side project, with a massive disclaimer that I'm doing it for fun.
I started with colons indicating the return type, but IMO it gets too confusing when you have functions as parameters. e.g. `foo(bar: (int, string): float): float` but that might be just personal preference.
It makes it easier to reason about a functions result, both when reading the code and when type checking.
`extern` means it's implemented in native, but it has to conform to the interface that the VM provides, and register that function with the VM. At runtime, the parser knows when a function is local (i.e. in the bytecode) or extern (i.e. C++). If it's local, it'll jump to the function's offset in the bytecode, if it's extern, the interpreter will use a native call.
You can take a look at some native functions here: https://github.com/tadeuzagallo/verve-lang/blob/master/runti...
And the implementation for the `op_call` opcode here (notice it has 2 branches: op_call_builtin and op_call_closure, the former is for `extern`ed functions): https://github.com/tadeuzagallo/verve-lang/blob/master/runti...
Right now it runs on its own VM. What I meant by "the VM is no longer necessary" was that the language went from being dynamic (when I was just prototyping with lisp) to static (in the current state), so it should be easy to generate machine code ahead of time, instead of having an interpreter (or adding a JIT).
The reason the definitions link to Wikipedia is that this is the first piece of documentation on Verve ever. Hopefully I'll be able to cover most of it in proper docs later, but I thought for now I'd add the link to the definitions in case someone reading through was not familiar with them (I personally hate to stop reading to start googling for acronyms).
That's not a dependency, that's a limitation: the interpreter is only implemented for one platform right now, but there's no reason why it shouldn't be possible to add support for a new platform without changing the existing code.
What I meant by no dependencies is that I don't aim to use any libraries/toolchains to facilitate the job of executing/compiling the language (or providing runtime support).
I meant minimal as in the number of concepts it exposes, basically all you get are functions, (G)ADT + pattern matching and type classes.
Thanks for posting the errors, I'll get ubuntu running and look into it. It seems to be just the __unused annotations and the non-portable pthread call, so should be easy to get it working. :)