Design notes

What is the issue?

Suppose we have a Result and an alias for it:

type StachuResult<'a> = Result<'a, StachuError>
type StachuResult2<'a> = | Ok of 'a | Error of StachuError

We need to ensure that the names sync up during equality

let randomStachuErr(): StachuResult<Int> =
  PACKAGE.Darklang.Stdlib.Result.OK 1

let random(): Result<Int, StachuError> =
  StachuResult.Ok 1

random() == randomStachuError() // true

let randomStachuErr2(): StachuResult2<Int> =
  PACKAGE.Darklang.Stdlib.Result.OK 1 // type error - also runtime error when we typecheck the return type

let randomStachuErr'(): StachuResult2<Int> =
  StachuResult2.Ok

randomStachuErr'() == random() // false (type error)

StachuResult2.Ok is not a Result, but StachuResult.Ok is.

Our EEnum needs to reflect what is typed - i.e. we wrote StachuResult.OK, not just Result.Ok. But then we later need to do the alias resolution to know that StachuResult.Ok is equal to Result.Ok

Proposal: parser does that resolution

• parser is where we should be doing error-resolution and warnings
• we could also do it during PT2RT
  • we shouldn't have to do alias lookups during conversation from program types to runtime types
    • we don't want to introduce errors in PT2RT
    • note: actually this is fine, we can add EErrors safely
    • even when there's an error in the code you've typed in PTs, we only want to cause an error at runtime when you execute that code
  • let's say someone uses FakeTypeLOL, we don't want that to be dynamically resolved later when that type is created
    • (if someone defines a type/fn/constnat after it's been referenced, that doesn't change how things run)
    • one option is to reference fns/etc by IDs
    • the parser (and internal stuff maybe?) need to be able reference things by name, but users can't really
• ProgramType.EEnum would need to store both the alias definition and the resolved alias type