hgzimmerman / hlwnpa Goto Github PK

Once conditionals exist, a while loop could be implemented.

accessing arrays is slow partially because the evaluate function returns a clone of the desired object when getting a literal or identifier.

This has kept the language design simple ( I haven't had to think about lifetimes yet).
But when testing over arrays of 1000 elements, the problem manifests itself exponentially, where each object (which is 1000 times as large as the typical object) is cloned 1000 times (It is accessed once for each iteration to get the owned value).

I should attempt to come up with a solution that uses references so the cloning isn't necessary.
If that isn't possible use RC/ARC instead.

Possibly split the LangError type into runtime and compile/parse time errors.

This is probably hard given how fuzzy the compile-time vs runtime logic is right now.

A lot of runtime errors that could be compiletime errors are type checking related. These could be evaluated at compiletime by implementing add, subtract, multiplication, etc... to the TypeInfo class and allowing tracking of types through the AST by converting each datatype into a TypeInfo, and performing the logic on it to determine if the types match.

As an example, consider this function:

fn function(value: Number ) -> Number {
    let x := value + 1.0
    x
}

Under the new typechecking system, it could convert that to something like this:

fn function(value: Number ) -> Number {
    let x := value->Number + Float
    x->Float
}

Because Number + Float is a Float, returning x should not be possible because the return type is a Number. This should throw a compile time error indicating the type mismatch.

Currently, the map that represents all used variables is cloned when the program enters a new scope ( for example, a new function). In a large enough program, this means that it copies around a whole bunch of data fer each function call.

Instead of this, it should be possible to evaluate the AST beforehand, determining which identifiers will be used within a scope, caching those identifiers at the node where the scope is created, and copying only those values out of the primary map.

This precomputation will need to be aware of the needs of the scopes that are nested within the given scope (a function has some set of requirements, and the function within it has other requirements, the total requirements for the outside function will be the sum of its requirements and the requirements of the function contained within itself).

A problem posed by this change is that most of the objects passed around by cloning the map at the topmost level will be the functions themselves, which should be immutable anyways. Does it make sense to have an "append-only" store that is never cloned which should only be used for immutable constructs (functions, struct-types, consts). Does this mean that constants should be hoisted out of their functions if that is where they are declared.

This would allow the first part of program execution to be hoisting these immutable constructs and adding them to the immutable map, then finding main and using the scope maps.

Adding elements to the immutable map could be enforced by checking if the identifier already exists in the map, and error out if it is.

Convert (* 8 5) to (8 * 5)

Once RPN is removed, it should look like: if expression { expressions } else { expressions }

Return an expression from a function early