Closed daniellga closed 4 months ago
Yeah, I know it's a choice and what the majority of people think the Rusty way. But, on the other hand, it makes it extremely difficult to do static analysis and proc macro, which are the core parts of Savvy. So, I think I will never implement this unless some feature is provided by Rust.
Could you elaborate a little further on this static analysis and proc macro stuff? I am having a hard time understanding how having a static type is advantageous here since you implement for these new types basically the same functions that you already have in Sexp.
Sorry for replying late. I was thinking if I will try implementing this.
The main difficulty is this part. Sexp
means savvy can know nothing about the user's assumption on the type. This doesn't matter much at the moment, but I want to keep the possibility of distinguishing the input types in case I might want to add some type-specific codes (e.g. add some vctrs
function in the R wrapper's side for better validation). So, let me decline your suggestion. Sorry.
fn fff(a: Sexp)
^^^^
I saw you added these 2 types which are structs that hold other Sexp types. This issue is just a suggestion of what I think would be a cleaner and more mantainable code.
So instead of using for example
NumericScalar
struct, I think you could use aScalar
trait.And I think the same could be done for
NumericSexp
.So instead of making the user use these structs as types in the code, they would do the following when needed to retrieve a scalar from R:
This is just a suggestion. Let me know if you like it so I can make a draft to show you.