Add static types

[DylanSp]

Syntax similar to Typescript:

x: number = 3;
function add(m: number, y: number): number {
}

But how to do syntax for higher-order functions?

[DylanSp]

Type check pass should validate, not parse: returns Either<TypeError, Type> where the Right case represents the type of the top-level function. Evaluation still takes an AST from the parser.

[DylanSp]

Roughly following TS, could use

function makeAdder(x: number): (number => number) {
  function adder(y: number): number {
    return x + y;
  }

  return adder;
}

function doubleApply(func: (number => number), x: number): number {
  return func(func(x));
}

[DylanSp]

Do I want to allow (parametric) polymorphism?

[DylanSp]

When adding type syntax, convert existing parser tests to use .toMatchObject(), so existing tests won't break as I add type-related properties.

[DylanSp]

Lack of separate declaration and assignment could cause problems.

x = 1;
x = x + 1;

Should line 2 have a type annotation, even if it's reusing already-declared variable?

[DylanSp]

Instead of adding syntax: type inference everything? Would probably need to drop polymorphism, but I can live with that.

[DylanSp]

If I go the inference route - how to handle ==, /= (and print if I add that)? They're ad-hoc polymorphic.

[DylanSp]

Rather than full Hindley-Milner inference - treat it as a dataflow/DAG, and run the type checks one way. If I require initialization of variables to a value, which sets the variable's type permanently, I should just be able to work forwards through the DAG of statements/expressions.

[DylanSp]

Three options so far.

Option 1: usual C-style typing, explicit type annotations on everything.

• Pros:
  • sticks to usual imperative language convention
  • Relatively simple
  • Works going forward, even if/when I add modules
• Cons:
  • Requires adding more syntax, modifying existing test cases

Option 2: Hindley-Milner inference

• Pros:
  • Doesn't require modifying existing syntax
  • Works going forward, if/when I add modules
  • Good to know in general
• Cons:
  • The most complex of the options
  • Tricky to implement with imperative, mutable style of the language
  • Have to figure out how to handle ad-hoc polymorphic functions

Option 3: Forward-only dataflow analysis

• Pros:
  • Simple
  • Doesn't require modifying existing syntax
• Cons:
  • Kind of a dead end from a theoretical/learning perspective
  • Doesn't really work if I add modules

[DylanSp]

I'm thinking that I'll leave wheel-lang dynamically typed, especially with exploring prototypical inheritance as syntax sugar.