Document how to handle fallible tokenizers #18

Closed
opened 2024-07-03 02:50:55 +00:00 by zyxw59 · 1 comment
zyxw59 commented 2024-07-03 02:50:55 +00:00 (Migrated from github.com)

The preferred way to handle a fallible tokenizer is to pass the errors on to the parser, and then have the parser produce an error.

The preferred way to handle a fallible tokenizer is to pass the errors on to the parser, and then have the parser produce an error.
zyxw59 commented 2024-07-04 15:33:03 +00:00 (Migrated from github.com)

On further thought, this is kinda silly. Just because the first tokenizer we implemented was nearly infallible, doesn't mean that all tokenizers will be.

On further thought, this is kinda silly. Just because the first tokenizer we implemented was nearly infallible, doesn't mean that all tokenizers will be.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
mle/selkirk#18
No description provided.