The CLI command `lis run` supports a `--debug` flag to insert `//line source.lis:21:5` directives into the generated Go, so stack traces from runtime errors point back to the original Lisette source positions. The LSP handles compile-time errors, which reference `.lis` files by definition.
Calling Lisette from existing Go is not yet supported and is the harder direction, as you noted. This is on my mind, but the more immediate priority is enabling users to import any Go third-party package from Lisette.
Lisette began as an exploration, but I intend to make it production-ready.
I'm asking because your goal is to make it production ready, so what are you doing to assure people this is more than just another vibe coded language (of which there are countless examples by now)?
Like I said, these LLM-driven language projects have proliferated recently, and they follow a common pattern:
- Dump hundreds of thousands of lines of lines into a blank repo with a new repo.
- Throw up a polished-looking LLM generated website (they all look the same).
- Post about the project on a bunch of tech sites like HN.
- Claim it's a real project with deep roots despite there being no evidence.
Here's another one:
https://www.reddit.com/r/ProgrammingLanguages/comments/1sa1a...
These things are so common that r/programminglanguages had to ban them, because they were being posted constantly. So my concern is: what differentiates your project from the sea of others exactly like it, which as I've been following them? Usually the main dev grows bored with it quickly when the agent starts having trouble building features and the project is silently abandoned.
The merits of any project are yours to evaluate.
To me, I see some encouraging thoughtfulness here. However, again, it's true most projects like this don't achieve liftoff.