roccojiang / traversal-lang Goto Github PK

Error reports should also specify the error type, not just the error message. Perhaps use the logging library?

Due to how a NEWLINE token is used to end a line of input, the parser does not ignore \n characters. This means that any extra newlines will raise an error.

Just in general

As of commit 4239769, certain comparison operator rules may cause some confusing grammar. These rules should be considered and potentially modified in the future.

Due to booleans no longer being treated as integers:

• 1 = 1 = 1 evaluates to false as this becomes true = 1
• However booleans can also no longer be compared using <=, <, >=, or > which makes sense

Due to strings being unable to be compared using <=, <, >=, or >:

• "hello" <= "hello" throws an error even though technically it could be seen as true?

Because the parser can only parse one line of text, main.py takes text line-by-line from test.txt to 'feed' into the parser. This isn't necessarily an issue but I'll leave this here as a reminder in case I want to come back to this in the future.

Due to the parsing grammar of Traversal, certain whitespace characters (sometimes spaces, especially tabs) cause errors when placed at the end of lines. This causes a lot of confusion as the error messages aren't very indicative of the actual error.

As of commit 14689be, comparison operators are completely handled by the Python interpreter. Custom rules should be added to enforce:

1. Nicer error messages
2. Type rules of the EPQ language (e.g. unlike Python, booleans should not be explicitly considered as integers)

If there is one (and only one) newline at the end of test.txt, no errors are thrown. However, if there is a newline anywhere else or more than one at the end of the file, the ValueError: Ran into a $end token where it wasn't expected error is thrown.

Currently the parser takes input from test.txt line-by-line, as written in main.py, because the parser currently cannot take in multi-line input and can only deal with one line. This 'hacky' approach will have to be eventually rewritten to support more complex code.

A weird effect of this implementation is that a newline must be present at the end of test.txt, as every line has to be terminated with a \n character.

Comment tokens have been replaced by using regex to ignore all text following //, thus all old code referring to COMMENT tokens should be removed