xo-expression2/xo-reader
2025-11-28 19:32:56 -05:00
..
cmake Add 'xo-reader/' from commit 'c46c0f1cc4' 2025-05-11 01:40:20 -05:00
docs xo-interpreter adds + explict mm arg to ctors (retiring Object::mm) 2025-11-16 20:10:23 -05:00
examples xo-interpreter: plumb initial global symtab so builtins reach parser 2025-11-27 11:50:34 -05:00
include/xo/reader xo-interpreter: apply expressions + llvm builtins working! 2025-11-28 19:32:56 -05:00
src/reader xo-interpreter: apply expressions + llvm builtins working! 2025-11-28 19:32:56 -05:00
utest xo-interpreter: apply expressions + llvm builtins working! 2025-11-28 19:32:56 -05:00
.gitignore Add 'xo-reader/' from commit 'c46c0f1cc4' 2025-05-11 01:40:20 -05:00
CMakeLists.txt nix build: xo-reader: build + install docs+examples + build fix 2025-09-22 12:47:00 -04:00
README tidy: minor doc improvements + String::share() with explicit mm 2025-11-15 14:04:56 -05:00

1. in parser we need.. type unification?
2. or perhaps just need to introduce type variables.

3. we can't resolve type for a recursive pair of functions until we've seen both of them..
   tho we could require letrec

def foo = lambda (n : i64) { let (n == 0) then 1 else n * foo(n - 1); };

strategy:
--------

while parsing def, instead of creating DefineExpr with nullptr TypeDescr:
a. create DefineExpr with TypeVariable.
(We have to do this because can't tell nullptr's apart,..)

- generalize xo::reflect::TypeDescrBase

// compose these into Expressions.
//
struct type_ref {
  bool is_concrete() const { return td_ && td_->is_concrete(); }

  // generated name, so we can map between types.  Don't want to create TypeDescr
  // every time we have a typed location. there'd be a lot of them, and hard to collect
  flatstring<11> id_;
  // if TypeDescr is concrete (fully described), this describes it
  TypeDescr td_;
};

// what we know about a type
//
struct TypeBlueprint : public Refcounted {
  static bool equal(bp<TypeTemplate> lhs, bp<TypeTemplate> rhs);

  type_ref ref_;

  // additional descriptive info...
};

// effectively these are constraints?
//
using TypeSubstitutionMap = map<string, rp<TypeTemplate>>;

will have typeunifier in parserstatemachine

struct TypeUnifier {
   // extend as unification proceeds
   //
   TypeSubstitutionMap substitutions_;
};

alt strategy
-------------