botffy / xplang Goto Github PK

Currently the interpreter uses the Type of a variable to determine how to initialize it, types having an InitializationMethod enum value.

It'd be more flexible, and better for the separation of concerns, if the Grammar could define a SpecialName.TYPE_CONSTRUCTOR nullary function for types, and the Interpreter would call that on initialization. These would be implemented as instructions, at least initially.

Probably we add one to the original values twice.

    ha i ! 3 akkor
      ki: i
    ha_vége

We would expect this to generate a single error, for failing to tokenize the exclamation mark, then the parser should resume parsing, correctly consuming ki: i. But it skips that line, jumping to the ha_vége, which generates an unexpected token error, because it expects a statement.

It's not just a matter of skipping a single line. If there are two statements in the if branch, both are skipped.

Hook into the interpreter and refresh it after every step.

It's important to watch out for the memory load. For example if we have a large array filled in sequentially, storing the whole array at every step may consume a very large amount of memory.

A solution may be to store the memory sparsely, in a TreeSet: and if a value does not change, the unchanged value should not be stored. This does not, however, solve the array problem, unless the array elements themselves are stored in a TreeSet, in a recursive structure. Somehow.

Somehow.

Currently multiline strings are allowed by the parser:

ki: "oh
you
handsome devil"

Do not allow this.

Currently we maintain a LeBlanc-Cook symbol table to keep track of lexical scoping. However, the language will actually only have two scopes: local and global. Only functions and procedures will have their own lexical scope. Also, it was decided that name shadowing shall not be allowed.

Accordingly, the current implementation is overly complex, and should be simplified. Greatly.

Throw the LeBlanc-Cook symbol table away entirely, and maintain only two maps: one for the global scope, and one for the currently active local scope, if there is one. When declaring a name, Context should check availabilty in the global scope, then in the local scope. If the name is still free, the name is declared in local scope, if there is one, otherwise in the global scope. All other cases shall result in errors.

This is also a good possibility to clean up Context a bit, especially wrt the declaration functions which are in general inconsistent.

Since parentheses are optional for functions with a single parameter, it would make sense to make the () optional when calling nullary functions, like in Pascal: a := f. This is a nice syntax. But that's unparseable, because

x := f
y := x

Since there's no opening parentheses, the parser assumes an argument will follow. Pascal tackles this by using mandatory statement separators. We don't, however, know when a statement ends. A x := f() syntax has no such problems, but it's kinda ugly.

Do we need nullary functions, though? The traditional answer is no, a nullary function is a constant. But functions can manipulate the global scope by using I/O mechanisms. A valid use case is a function that reads input into an array and returns it.

The same applies to procedures too:

f
y := x

would be similarly unparseable.

The exception handling in the parsing phase should be based on error codes. Exceptions should contain an error code, and a (possibly empty) list of parameters. Translation should happen in the outermost level, taking the (language dependent) error message belonging to the error code, and substituting the actual parameters into that.

That way the parser can be independent of the localization, and we won't need that static translator.

When called from the command line, interpreter errors are never caught: the program just crashes and outputs the stack trace.

The errors should be handled more gracefully: caught at the command line and presented somehow nicely. Other runtime errors may be caught and handled differently.

We should also consider making InterpreterError a checked exception. The downside of this would be having to register InterpreterError at the ASTVisitor level.

Alternatively, the Interpreter's entry point might catch its own unchecked exceptions, itself throwing a checked exception. Or something along these lines.

It's possible to store the actual tokens in the Expression trees, or maybe we could take another route and display the expression only at the UI level

The original language specification allows the use of the comma as a statement separator. Since the language has a nice LL(1) grammar unaffected by line breaks, the statement separator is not neccessary, and its use should be discouraged. When encountering a statement separator comma, the compiler should emit a deprecation warning.

Maybe also "Save with encoding" menu item.

Currently it's really ugly. We need a better error message.

Assignment of arrays in PLanG is by value, that is, they are recursively cloned during assignments. Passing an array as an argument to a function or procedure would follow the same behaviour.

The problem is, this makes procedures kinda useless. Traditionally, in Pascal, procedures are used to alter passed arrays, and that'd be a good usecase for Plang too. But that's impossible with these pass-by-value semantics, unless we introduce out parameters. Without it, the only possible usecase for procedures is to output things. Which is underwhelming.