-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
type alias is too hacky #4
Comments
cf o1-labs/proof-systems#206 as well |
I've implemented a short-term solution, but it'll probably have some issues with aliases on different generics: t1 := alias of Thing<T1>
t2 := alias of Thing<T2> I think this will crash, although it might be worse and silently do something bad. The solution is probably to do what the previous comment is saying: calculte the unique id based on the XOR of the instantiated type parameters unique id + that generic type unique id |
it will crash if you do this, but there's another problem which is dangerous at the moment. If you do this:
and you have a function that returns a |
I think in general this type alias thing is a BAD IDEA, but we use it in Mina so I'll keep it around until we don't need it anymore |
How do we generate type aliases?
We have a
decl_type_alias!
that can be used like this:it will then generate code like this:
The problem
as you can see, the return type of the function
thing
was not rewritten to simply point tot
Although it might work, this is probably not doing what you think it should do. Worse, it sometimes won't work.
Imagine that you are declaring the following:
it will then generate code like this:
This is obviously wrong, we have a type collision (talked about in o1-labs/proof-systems#176 as well).
Solution?
What we want here is simple:
SomeType<SomeConcreteType>
when we declare the type aliasSomeType<SomeConcreteType>
is used, and fallback on the location ofSomeType<T1>
(the generic type) otherwiseThe problem is that we are tracking types and their location based on the generic type only (regardless of if the type parameters are concrete or not).
I don't see how we could have our trait implementation be dependent on the type parameters:
actually... since every type must implement this, we could just use the ocaml_desc to return the full string name of a type instead of using the
unique_id
. I think this could work, but we lose the benefit of having a unique_id.We could always use the unique_id as a fallback though...
It'd be good to document what the unique_id really solves first. The idea was that we wanted to differentiate different types, even if they were named the same in Rust.
I found out here that using a mix of
unique_id
to distinguish between different instantiations of the same type wouldn't work: o1-labs/proof-systems#172 but I'm not convinced anymore that this is true...working on this in https://github.com/o1-labs/proof-systems/tree/mimoo/ocaml_custom
The text was updated successfully, but these errors were encountered: