cda-group / arc

Programming Language for Continuous Deep Analytics
https://cda-group.github.io/arc/
44 stars 6 forks source link

Support for generic abstract data types #335

Closed segeljakt closed 2 years ago

segeljakt commented 2 years ago

A small issue regarding ADTs in MLIR. In Arc-Script you can write:

extern type Array[T];
extern def new[T](): Array[T];
extern def push[T](Array[T], T);

def test() {
    val foo = new();
    push(foo, 1);

    val bar = new();
    push(bar, 1.0);
}

On the Rust-side, we got definitions for new and push:

struct Array<T> { ... }
fn new<T>() -> Array<T> { ... }
fn push<T>(array: Array<T>, elem: T) { ... }

All code that goes to MLIR must be monomorphised and name mangled (including extern definitions). We therefore get something like:

extern type Array_i32;
extern def new_i32(): Array_i32;
extern def push_i32(Array_i32, i32);

extern type Array_f32;
extern def new_f32(): Vec_f32;
extern def push_f32(Vec_f32, f32);

The problem is that there is no monomorphised definitions on the Rust side (e.g., fn new_i32(), fn new_f32()). There is only generic definitions (e.g., fn new<T>(). We need some way in MLIR to keep the original name of the extern def around so we can call it in the generated code.

It's not very urgent, so I suggest we do this after finishing the FSM transform :)

frej commented 2 years ago

We could probably slap on one or more attributes on the external def to make the rust code generator produce the new<T>()-call.

segeljakt commented 2 years ago

I think this is now solved