Replies: 1 comment
-
Another approach is using a code-generator -- maybe proc-macro, or even python scripts. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Previously, when @wangrunji0408 and I bootstrapped the
array
module, we thought that GAT might be somehow hard to understand to new contributors (as well as tutorial students), so we get rid of GAT in this version of RisingLight. As Rust community is continuously improving the GAT related compiler internal things, we could write such generics in an easier way. rust-lang/rust#90887From my perspective, GAT might not be a very hard thing to understand. In our system, the GAT is solely used to map reference types with owned types, and we only use GAT on lifetimes (instead of other generic types). This won't impose much burden on new learners.
In particular, the expression framework needs a way to unify expressions. Just take a look at how the current framework implements the arithmetic operations:
risinglight/src/executor/evaluator.rs
Lines 185 to 191 in 141a262
How can we add more expressions like function calls? We can for sure implement the same thing on
BoundFuncCall
, but we need to write vectorization code for a lot of times...Therefore, it seems that we need a generic expression vectorization framework. To implement that for all types (e.g., List, Struct, etc.), we cannot simply go with
type Item: ?Sized = str
-- it's impossible to create an unsized type for those semi-structure types.GAT sounds like the only way to solve all the problem. Therefore, I suggest moving to GAT, waiting for Rust compiler to solve all bugs related to it, and implementing a simplified version of https://github.com/skyzh/type-exercise-in-rust.
Beta Was this translation helpful? Give feedback.
All reactions