You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Theres a few things about the current parser which make it not as nice as it could be. Specifically:
It is not very resilient (only best-effort, using the sync helper on the parser to discard tokens in an attempt to return to a potentially good state)
The indentation tracking machinery made it hard to implement semicolons
The error handling mechanism is not great, because there's a distinction between "collect all errors" and "propagate this one error up"
Spans are not associated with their source files/strings. Ideally spans would also be interned, as they currently take up quite a bit of space.
I think the issues are only going to become more exaggerated as we add features (match, do, with, postfix if/for, etc.), so before we start doing that, it's probably a good idea to do an overhaul of the parser while it's still this simple.
I think this post by matklad has excellent has ideas, and we should follow it when writing a new parser.
The text was updated successfully, but these errors were encountered:
Theres a few things about the current parser which make it not as nice as it could be. Specifically:
sync
helper on the parser to discard tokens in an attempt to return to a potentially good state)I think the issues are only going to become more exaggerated as we add features (
match
,do
,with
, postfixif
/for
, etc.), so before we start doing that, it's probably a good idea to do an overhaul of the parser while it's still this simple.I think this post by matklad has excellent has ideas, and we should follow it when writing a new parser.
The text was updated successfully, but these errors were encountered: