sco1 / pylox Goto Github PK

• Implement static methods
• Implement getters

https://github.com/sco1/pylox/blob/main/pylox/ast_printer.py hasn't kept up with development of the interpreter. This can probably be caught up now that we're probably not going to make any more major changes.

• Support comma expressions
• Support ternary operator
• Add syntax error for binary operation at the beginning of an expression

• Allow comparisons between types other than numbers
• Concatenation of strings with other types
• How should divison by zero be handled?

Once #13 is done, this can be added with a behavior flag

• Multiple inheritance

• Update REPL so it supports statements and expressions
• Make it a runtime error to access a variable that has not been initialized with a value

• Add support for lambdas

Newlines are being escaped when parsed for some reason:

$ pylox
>>> print len("\n");  // expect: 1
2

Which prevents comparisons between "\n" and newlines from files. e.g.

var sample = read_text("sample_input.txt");

fun split_on(in_str, delimiter) {
    // Split the input string on the specified delimiter & return a LoxArray of strings
    var out = array(0);
    var split_txt = string_array(in_str);
    var substr = "";
    for (var i = 0; i < len(in_str); i = i + 1) {
        if (split_txt.get(i) == delimiter) {
            out.append(substr);
            substr = "";
        }
        else {
            substr = substr + split_txt.get(i);
        }
    }

    out.append(substr);
    return out;
}

print split_on(sample, "\n");

Prints ['1\n2']

I suspect that this originates at the scanner, since we get the following token for "\n":

Token(
    token_type=<TokenType.STRING: 24>, 
    lexeme='"\\n"', 
    literal='\\n', 
    lineno=0, 
    end_lineno=0, 
    col_offset=10, 
    end_col_offset=14
)

Similar behavior exists for e.g. "\t" as well

e.g. .123 and 123. should be valid ways to define floats.

Would be good to have built in array sorting, perhaps with both in-place and new array variants?

Once Mypy is updated to support pattern matching, need to go through and make sure our typing is correct.

Related to #4 and 9ad53de, error reporting can probably be improved a bit more than what we have for our baseline.

While a blanket subtraction of the number of lines inserted gives a helpful offset for issues with the on-disk code, if there's an issue with imported code then we have no idea which one, since the reported line number is going to be <=0 (lol). To clean this up a bit, let's keep track of a bit more metadata on what's been imported & where so we can point to the correct include if there ends up being an issue.

To be ready for this year's Advent of Code, we'll likely need some basic regex capabilities. For the sake of time, add some basic passthrough to Pythons re module rather than implementing a regex engine from scratch.

Let's do a quick check through my existing AoC solutions to see what the most common use cases are; I suspect we won't need much more than re.findall and maybe re.sub.

It would be nice to have a way to be able to write some external lox code and include it without needing to manually copy/paste.

As a quick & dirty start, let's try introducing an include keyword that allows us to specify a path to the file. Before the scanner runs, go through the include statements and (temporarily) replace them with the source from the referenced path.

For now let's make the following assumptions:

• One path per include line
• Source files contain valid code
• Referenced source files do not themselves have any imports
• Source files don't share any identifiers in the global scope

Things to think about for later:

• Should we warn/error about duplicate imports?
• How could we expand to recursive imports if we wanted to in the future?