Support for Rust enums?

[VarLad]

Julia has libraries like Expronicon or MLStyle which provide Rust-like enums.
Is it possible to somehow use these libraries to map Rust's enums to these types? (in the case of porting Rust libraries to Julia)

[Taaitaaiger]

I don't think so. There might be some cases where you can hack something together which works, but I expect that the layout of a Julia enum will typically be incompatible with a Rust enum. Rust implementations of Julia types can already be generated by using JlrsCore.Reflect as long as the Julia type contains no unions that depend on type parameters and no atomic fields. Types generated with the packages you've mentioned should be compatible if those requirements are met. Op wo 9 aug. 2023 21:30 schreef Chetan Vardhan ***@***.***>:

…

Julia has libraries like Expronicon <https://expronicon.rogerluo.dev/intro/adts/defining> or MLStyle <https://thautwarm.github.io/MLStyle.jl/latest/syntax/adt.html> which provide Rust-like enums. Is it possible to somehow use these libraries to map Rust's enums to these types? (in the case of porting Rust libraries to Julia) — Reply to this email directly, view it on GitHub <#103>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOQBHHYWIRY3QFSDNBVVQALXUPQOVANCNFSM6AAAAAA3KOYFTY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[lenianiva]

I don't think so. There might be some cases where you can hack something
together which works, but I expect that the layout of a Julia enum will
typically be incompatible with a Rust enum.

Rust implementations of Julia types can already be generated by using
JlrsCore.Reflect as long as the Julia type contains no unions that depend
on type parameters and no atomic fields. Types generated with the packages
you've mentioned should be compatible if those requirements are met.

Op wo 9 aug. 2023 21:30 schreef Chetan Vardhan @.***>:
…

Is it possible to mimic the behaviour of such enumerations using type markers? For example, we can export some functions:

pub struct Expr {
    /* wrapped Rust enum type */
}
pub struct ExprTypeConstructor<X> {
    _x: ::std::marker::PhantomData<X>,
}
pub type ExprConst = ExprTypeConstructor</* ??? */>;
pub type ExprAdd = ...;


julia_module! {
  fn expr_const(x: f64) -> TypedLayout<Expr, ExprConst>;
  fn expr_add(lhs: TypedLayout<Expr, ExprConst>, rhs: TypedLayout<Expr, ExprConst>) -> TypedLayout<Expr, ExprConst>;
}

and to mimic the behaviour of match statements, we need to attach functions to ExprConst to access its "fields" which I don't know how to write in this case.

An alternative solution is to have separate ConstructTypes for each case of the expression that all derive from a common base type, but in this case, we need to override super_type in OpaqueType to indicate that all the individual cases of an expression derive from the same parent, and the type of each variant of this enum would have to show up as different types in Julia, which I don't know whether it is possible or not.

Edit: There might be some issues with the type name being Expr, but we can override this with #[jlrs(...)].

[Taaitaaiger]

Only immutable types can be passed as a TypedLayout, and exported types are necessarily mutable.

The main reason TypedLayout exists, is to deal with type parameters that are elided in jlrs; any type parameter that doesn't affect the layout of the type is elided, this is typically only relevant when you're working with bindings to Julia types generated with JlrsCore.Reflect. This has the nasty property that we can't get the Julia type from the Rust type, which prevents us from generating a ccall invocation that passes the data by value. By using TypedLayout we can provide the actual Julia type that should be used in the signature.

As I've said in another comment, I think it's best to model this from the Rust side by treating each variant as a separate type and export functions with the same name. In general, you should aim to write code whose return type only depends on its input types (type stability), if this in unavoidable you can return a ValueRet for now