Type checking, error locations, modules

[umuro]

Error locations
If you were writing a C compiler then you would simply wrap blocks of generated machine code with an exception handler that adds error location.

We will do the same. We will wrap function calls with a location updater.
doSth->onError( err->addLocation(aLocation) )

Only function calls need to have locations.

What about type errors on arguments? Now, that's a different story

Types
Let's say add: float=>float=>float
if we are calling add(1., "a") then we can apply argument types with location the type calculus at the moment is
((float=>float=>float) float string)
We just need to add locations to the apply operator
apply( apply((float=>float=>float)) float locations) string location2)
Which reduces to
apply( (float=>float) string location2)
Which reduces to
"float expected at location 2"

It is really trivial to generate a type checking pass once everything has a strong type. Once library functions has all strong types, user functions will have strong types also because of simple type calculus.

Easy but this does not fit the current implementation

• Those type checks are need to be done once but those heavy type checks will be done over and over during the interpreter implementation
• Current switch statements are doing that kind of thing but without a location. They are functionally redundant. That's the motivation behind type modules: Getting rid of redundant matches in switch statements - Those redundant matches will be performed by the typecheck anyway.
• If we add this simple logic to interpreted expression than it will be heavily loaded with locations and redundant type checks everywhere.
• Practically we will end up adding location info near each and every object in the generated expressions - ugly. I don't want to execute:
  add@location1 1@location2, "2"@location3 which has to produce 3@location1 instead of just 3. This motivates me to keep error locations coarse and have a type checking pass in the future.

Therefore

• First error location will deal with function calls only switch statement generated errors will show up at the function also instead of argument locations
• When there is a separate type checking pass, then it will show type errors at their exact location. And execution will still stay light weight.

Type checking pass
Type checking pass is becoming the core of the module implementation.
Let's say we have rescript calling ability from Squigle and type declarations. Let's define add:
add(a: float, a: float): float = rescriptFFI{ a + b }
Here you have defined add as a function selector and a add_float_float function.
The typechecker replaces add with add_float_float based on the argument types during the type checking pass.

For now, until there is a type checking pass, I will insert this call to function calls (to be removed when there is a type checking pass).
So that function selectors will be replaced by actual function on call for now.

Here I relied on 2 features

• Declaring function selectors with strong type
• RescriptFFI. Ability to call rescript from Squigle

I observe that without the type checking pass, the code is becoming redundant and heavy.

• To reduce that I wont report argument locations until type checking pass.
• Strong type calculus will enable true function selectors. Function selectors will be process at the type checking pass later. For now we will insert selector processing to expressions to enable true type modules.
• Type checking will enable type modules nevertheless. Once all switch statement code is migrated to type models, type checking pass will be possible bringing precise type error locations.

** More on error locations **
Most of the time errors are not happening in current source code executing. Therefore I propose to have a new evaluate interface
evaluate2(<project>, <sourceId>)
Using sourceId@project instead of source code text.
This guarantees that everything imported or continued has an unmistakable location.
You might naively think that evaluate(, sourceCode) would be a smart workaround but I see many disadvantages. It's open to weird errors. And project has other advantages

Project
A project contains s indexed with . It is a simple stupid collection. But in addition we can hang more things to the project to optimize code more.

• parseTree@ . There is no need for multiple parse runs. Once it is generated it is reusable. If you wipe them then it will be reproduced
• bindings@. We simply cached the runtime results. Code will not rerun until wiping bindings.
• expression@. We don't need to keep recompiling to simply rerun
• memoizationTable. Until you wipe the memorization table no function will rerun with the same arguments. Making memorization table a global seems to be a suicede. It should be in a project.

To enable easy wiping out we can define some simple functions

• touchSourceCode: Wipes parse tree, expression, bindings
• touchParseTree: Wipes expression, bindings
• wipeBindings
• wipeMemoizationTable

Once we have the project, we don't have to use an evaluate with bindings. It's there in the project. In fact, I can switch to use a continuation instead of converting bindings from typescript which are converted from rescript all the time. Bindings need to be converted only one way for viewing. Furthermore, there wont be the issue of merging standard library multiple times. When type modules are implemented, to-from-converting them will be massive. And as bindings are for viewing with the project, we don't have to export standard library at all inside them. In fact, we can add export filters to decrease further heavy traffic.

Anyway, this is a roadmap. But for the immediate future:

• Create a simple typescript friendly project. Project is for type script. It is not functional at all and we intend to have a mutable project.
• Have evaluate2(<project>, <sourceId>) and spice it with function call error location.
• Hang the memorization table on to the project.
• And introduce EvVoid and parameterless functions

The project will be an nice agreement point on file imports/includes also. Import a file? Hang it to the project and don't worry about execution.

[umuro]

Standalone type declarations are creating IEvType data on the type namespaces. However it seems that this is only temporary. Cases

• A value. If there is a value then it knows its type. After assignment and conflict resolution there is no need to keep a separate type.
• A function, its runtime type checking should be built in with the current interpreter without type checking pass. So it should bring the type into itself. So there should be a typedLambda just enhanced with a type declaration. Until interleaved function type declaration is available, type namespace only contains forward type declarations to be consumed later by the actual implementations.
• A function selector. A function selector has to contain a collection of types and their related functions. Hence it knows its type. And there is no way of using a forward type declaration like in functions. So typedSelectorLamda should exist. A lambda function that invokes a function jump table. Each module can add to a typedSelectorLambda merging a new function to its jump table.

typedLamda and typedSelectorLamda does not act differently than ordinary lambda in terms of argument application.

So we can say there is a typeOf function on type (identity), value, typedLambda, and typedSelectorLambda. Ordinary lambdas should return error on typeOf. And type namespace for type declarations is just a temporary residence for forward declarations.

Keywords: typeOf, typedLambda, typedSelectorLamda.

Now steps to full typed module declaration becomes only 2 steps

• Completing type unit tests
• Creating typeOf, typedLamda, typedSelectorLambda
• Adding behaviour inheritance. A behaviour is a simple collection of function arities.
  This is the complete module system I guess...

To think for the future. There is a difference in constructors and functions to be selectors. Both in stdLib internal implementation and in the syntax (when we introduce modules to users) there has to be a difference. For example, we should prefix normal functions with constructor/function keyword and leave the selectors as the default. Like:

module Complex
    inherits NumberLike
    constructor complex(a,b) = ....
    add(complex, complex) =....

Of course with the constructor keyword the first thing that comes to my mind is that there might be other normal functions in a module that should not be selectors. Just some utility functions. So what is the right way of expressing them?

module Complex
    inherits NumberLike
    static complex(a,b) = ....
    add(complex, complex) =....

[OAGr]

From what I understand, constructor is just a way of flagging that a regular function returns that type? I was calling this make in our API docs, similar to Belt/Rescript. I don't think I like static.