The instructions for compiling Lunar are a tad vague. Specifically, it doesn’t list LuaFileSystem as a dependency but it appears to be one. That puts a damper on things as I’m not a big fan of LuaRocks.
You may want to update the instructions regardless; they’re not clear on what to do and it took a bit of looking around to figure out what the problem was. I actually had to modify lunarc to even see the error message saying I didn’t have LuaFileSystem available. It would be great if the instructions were more clear beyond “do this” then leaving people to their own devices.
This was a huge oversight. We’re applying a fix to include a more clear message when you don’t have LuaFileSystem for now, and we’re going to work on having lunarc not require LuaFileSystem. Only the compiler uses LuaFileSystem, and the reason this wasn’t very clear to us is because we use busted for unit testing, which has LuaFileSystem as a dependency.
We’ll also be updating our installation steps to reflect LuaFileSystem being a dependency, as well as being more thorough about how to install and use Lunar. This should be very soon.
Sorry about that, and thanks for letting us know about it!
We’ve updated the README to be more thorough and include dependencies, as well as updating lunarc to show a more friendly error message for when you don’t have LuaFileSystem.
We plan on using luastatic to bundle the actual release (so that most users won’t need to use luarocks modules if they don’t want to).
Currently we still do not have a stable release, nor have we bootstrapped, so for now lfs need to be installed.
I agree, luarocks is a really annoying package manager, but lfs is unfortunately necessary in order to make command line tools in lua. So it won’t be a requirement for the user upon release, but certain dependencies will be for contributors.
Lunar now has a language documentation for its syntax as well as semantics! You should be able to learn Lunar easily now that it’s explained to you instead of inferring what was possible or intended. We hope this would allow Lunar to be more widely adopted as we develop Lunar.
We also have bootstrapped the compiler, so now Lunar is written in Lunar! We’re eating our own dogfood now.
We want to know your experience with Lunar so far! So please give us feedback, whether that was porting over a project or creating a Hello World program, etc.
If I were to use Lunar, how would I debug and fix runtime errors? Does the Lua output have the same line numbers as the Lunar source? Are the Lua errors easy to trace back to the Lunar code? Does Lunar provide an easy-to-use way to map a Lua error back to a Lunar file and line number?
The output of your code should look similar enough to what you initially wrote that you should be able to pinpoint where in your code something went wrong. Pure Lua code will always be mirrored. Parts of code using our syntax will look different, but still understandable.
An example would be x += 1 which turns into x = x + 1, which is still very understandable.
One of our primary focuses right now is to ensure you can still read and understand your code after it’s gone through Lunar.
Right now we don’t have any plans of having a way of mapping errors to Lunar itself, or having source mapping. We’re currently focusing on improving the user experience while editing Lunar code so you don’t have issues such as no syntax highlighting, improper indentation due to Lua not recognizing new things such as classes, and we are going to be working on implementing a Language Server for better integration with VSCode. Additionally, we’re going to be doing extra work on the compiler to enable some useful features such as watch mode, and a way to initialize projects without needing to create the files yourself.
We are also in the progress of making a thorough type system which will encompass everything Roblox and Pure Lua implements, such as Instances (Part, Script, etc.), and types (string, number, etc.)
We hope that eventually you’ll find yourself actually having difficulty running into those kinds of bugs by having VSCode tell you if something may be nil, and allow you to add appropriate checks to ensure everything goes right.
Being able to read and understand the code only helps so far if the line number is 100 lines off from the Lunar source. Are errors always within a couple of lines?
You should be able to combine any additional Lunar logic into one line so that Lua and Lunar line numbers match up perfectly! This would greatly ease fixing runtime errors, and could be implemented as an optional mode for when you don’t plan on looking at the Lua source. If I’m writing my game in Lunar, then I don’t plan on ever modifying the Lua output and I’d rather avoid reading it as much as I can. All the changes I need to make are in the Lunar source, so I just want to read where the error is then go check my code!
Runtime errors are unavoidable, especially in such a dynamic language. Fixing some errors at “transpile-time” is no substitute for being able to fix errors that occur at runtime. I love the idea of preventing certain classes of errors with type checking though!
Ultimately, Lunar adds a lot of stuff I like – I’ll probably use it eventually – but it’s still not clear to me what fixing a runtime error with Lunar looks like. Do I have to hunt and guess which Lunar line caused the error? Or does Lunar make sure to maintain the same line numbers? If not, are the line numbers really close together, or can they drift apart across a really long script that makes heavy use of Lunar’s additional syntax?
I’m guessing that the answers to those questions are, “Lunar does not maintain the same line numbers”, and “line numbers can drift apart across a really long script,” but I want to give you a chance to correct me and I want to provide feedback. I don’t think I’ll use Lunar until it’s easy to fix errors that occur during runtime.
Anyway, Lunar looks really cool so far! I’m excited to try it out someday!
For smaller scripts, usually yes. If your script gets lengthy and uses a lot of Lunar’s features, you’ll probably find yourself far off from the line where you declared something in Lunar.
Sadly, I’m not sure we’ll implement a way to congest Lunar’s additional features into one line. Currently, our configuration file is only applicable to the compiler itself, and doesn’t have any say in what to change while reading the Lunar code or what the Lua output is. We’re going to be improving this once we take a closer look at the compiler to add options such as initializing projects, and watch mode.
Absolutely. Right now, we’re focusing on people setting up their projects and actually writing code in Lunar, but we’ll definitely be looking into improving errors and general debugging.
When ran through Roblox, there are lines and stack traces usually, so if you look through what function or block of code an error is, you should be able to find where the error came from. It’s much easier if code is distributed through ModuleScripts, since they can sometimes be relatively small compared to much larger catch-all scripts.
Well, I have an example since we’ve bootstrapped Lunar entirely. Hopefully this can serve as an example of how it looks, and the similarities. Classes are a bit more extended out due to how it is writing them in Lua, sadly.
The lines of code are pretty similar despite a moderately lengthy script, but clearly it is lacking in style-awareness, generally because we ignore certain white-space characters such as new lines. This will be something that we will tackle once we’ve cleared up prioritized things.
Right now, to debug, you will have to look at the compiled code first and infer the corresponding source file code from that.
It’s not an entirely painful process (if you’ve ever used something like TypeScript or Roblox-TS, you’ll have to go through the same experience).
Any plans for making the code better-stylized will be further down the line, and configurable for the user. We may in the future allow the code to maintain comments, spacing, be minified, or maintain line numbers. But right now our focus is on building out the language’s core features and making it stable. We still haven’t made our first full release yet.