@tristanC That's an option! There's often cases where you know what the user wanted though, so you can provide a sensible AST that the toolchain can handle.
For example, a malformed string literal can still be parsed a string so type checking etc can be helpful.
Related Posts
I've been using "Expected Int, but got String" for my type error messages, but I've been wondering if I could do better.
"Expected Int here, but this value has type String" or "This expression requires Int, but the value is String".
Do you have a favourite?
LLMs are a really accessible machine learning technique. I dabbled with text classifiers a few years ago and the APIs were way more involved.
(system_prompt: String, input: String) -> String
I can prototype with this much more easily!
I'm having fun writing a simple type checker, but I'm learning firsthand why syntax-directed checking doesn't work. It prevents inference.
My checker catches real bugs, but it can't handle cases like this:
[1, 2].map(fun(x) { x + 1; })
I think I need bidirectional checking.