Show HN: Solid, a scripting language with a tiny VM(github.com)
github.com
Show HN: Solid, a scripting language with a tiny VM
https://github.com/chameco/Solid
6 comments
Great job! I was looking for a small and simple embeddable language (smaller than Lua) for a long time. Solid looks very promising to me.
Thanks! Quite honestly, my primary reason for making it was that I didn't like the Lua object model and Python/Ruby/Guile are a bit inconvenient to embed.
Are there any performance benchmarks?
EDIT: The language looks pretty cool in general. I'm not a huge fan of the recursion syntax. In particular, the `this` keyword seems to just refer to the current function object, which is confusing since in other languages that usually refers to the object a method belongs to. Further, the choice of immutable lists as the default data structure is odd -- arrays would be much more performant (and are the usual choice for scripting languages anyway).
EDIT: The language looks pretty cool in general. I'm not a huge fan of the recursion syntax. In particular, the `this` keyword seems to just refer to the current function object, which is confusing since in other languages that usually refers to the object a method belongs to. Further, the choice of immutable lists as the default data structure is odd -- arrays would be much more performant (and are the usual choice for scripting languages anyway).
Given that there is no array built in type, and the closest thing (list) is a lisp style linked list, I wouldn't expect it to be speedy in any non-trivial benchmark (or real-world use) that requires random access.
The core seems much more interesting than the Pawn language. I'd like to see more comparisons once this matures.
A few points:
1. I'd like to see the FFI implemented natively (i.e. by declaring in Solid and registering through C code/macro, instead of relying on object file parsing). Then it'll be extremely useful in a bare-metal microcontroller environment.
2. Namespacing is needed -- I don't really want `parse_xxx` or `ast_node` in my global namespace!
A few points:
1. I'd like to see the FFI implemented natively (i.e. by declaring in Solid and registering through C code/macro, instead of relying on object file parsing). Then it'll be extremely useful in a bare-metal microcontroller environment.
2. Namespacing is needed -- I don't really want `parse_xxx` or `ast_node` in my global namespace!
Yeah, the namespacing is somewhat poor, sorry about that. I'll get around to prefixing the names at some point.
Just wanted to say, kudos! I think it is essential for a language to have a good C interface otherwise it will be insulated. However some more example would be nice. Furthermore I think you mean "infix" in your documentation and not "inline".
Very cool. I would love to see immutable, persistent data collections as offered in Clojure.
Awesome work. How big is the executable?
Also, what did you not like about the Lua object model?
Also, what did you not like about the Lua object model?
Without debug symbols (the default Makefile includes them), the executable is 83KB (93KB with -g), less than half the size of Lua. The shared library is a bit larger, at 102KB.
Lua's whole table-metatable system always felt awkward to me, what with the magic names for operators. It's really not so bad, I just didn't see any reason to spend time learning something that felt awkward and archaic to me when I could make something that seemed a bit cleaner.
Lua's whole table-metatable system always felt awkward to me, what with the magic names for operators. It's really not so bad, I just didn't see any reason to spend time learning something that felt awkward and archaic to me when I could make something that seemed a bit cleaner.
It's a nice little language, and I dislike Lua's 1-origin indexing a lot (no real problem with its object system otherwise).
However, despite taking some 200K compiled, Lua does give you a lot of things for that dirtier object system or origin (or other things you'll dislike).
Some of those things are already planned by yourself, some you'll find out that you need only with enough usage, and others may be outside the scope of Solid. A partial list:
0. A reasonably efficient GC
1. Very fast portable interpreter - faster than most other portable interpreters (e.g. Ruby, Python) with comparable dynamic behaviour
2. A crazy fast JIT compiler (LuaJIT2) fully compatible with that interpreter that rivals compiled and optimized static languages, and is available for many common architectures (x86, AMD64, various PPC, various ARM)
3. Useful built in data type like a dictionary/array ("table"), strings and floating point math, C user definable structure.
4. A vast ecosystem, different in nature than Python's or Ruby's (geared towards embedding rather than direct use), but definitely there and definitely useful.
Once you implement the infrastructure required for these, you'll find out that magically, you're not much shorter than Lua after all (if at all), and that some things just cannot be matched (JITting. Unless you're the 10 people or so that have made PyPy happen. Or you are Mike Pall).
Still, it's a nice little language, and seems quite well written (though the choice of vm.regs[255] for a return value is likely to bite you at some point - make a macro for that, at the very least, to guard you against a type of 244 or 266 or 2555 or any other random number).
And if you are looking for inspiration for some features, another interesting and practical little language is Aardappel's Lobster: https://github.com/aardappel/lobster ; I really like the fresh approaches that he takes.
However, despite taking some 200K compiled, Lua does give you a lot of things for that dirtier object system or origin (or other things you'll dislike).
Some of those things are already planned by yourself, some you'll find out that you need only with enough usage, and others may be outside the scope of Solid. A partial list:
0. A reasonably efficient GC
1. Very fast portable interpreter - faster than most other portable interpreters (e.g. Ruby, Python) with comparable dynamic behaviour
2. A crazy fast JIT compiler (LuaJIT2) fully compatible with that interpreter that rivals compiled and optimized static languages, and is available for many common architectures (x86, AMD64, various PPC, various ARM)
3. Useful built in data type like a dictionary/array ("table"), strings and floating point math, C user definable structure.
4. A vast ecosystem, different in nature than Python's or Ruby's (geared towards embedding rather than direct use), but definitely there and definitely useful.
Once you implement the infrastructure required for these, you'll find out that magically, you're not much shorter than Lua after all (if at all), and that some things just cannot be matched (JITting. Unless you're the 10 people or so that have made PyPy happen. Or you are Mike Pall).
Still, it's a nice little language, and seems quite well written (though the choice of vm.regs[255] for a return value is likely to bite you at some point - make a macro for that, at the very least, to guard you against a type of 244 or 266 or 2555 or any other random number).
And if you are looking for inspiration for some features, another interesting and practical little language is Aardappel's Lobster: https://github.com/aardappel/lobster ; I really like the fresh approaches that he takes.
Can VM be built separately from the compiler, so it could be used on small MCUs?
The VM, the AST parser, and the Bison/Flex frontend are built in a layered manner: you could (with the appropriate Makefile) build only the VM, the VM+the AST parser, or all three. I don't currently have Makefile options for this, but it would be pretty trivial to add.
How long did it take to write this once you had all the ideas? I looked at the github history but they only went back 5 months and it looks like there was already a significant amount written so I couldn't tell how far back from there it went.
It's been about 6 months total, I think, but there were significant breaks for school and exams.