Closed michallepicki closed 2 years ago
From what I can tell, the typespec generation doesn't use the same parts of the Typedtree as the code generation? I am not sure yet if I can detect there how many arguments a let binding takes immediately vs how many are a part of the returned anonymous function, I know how to do that with the typedtree.str_items
...
I could probably rewrite the exports and function spec generation to do the same thing as code generation, not sure yet if this is the only way...
Or I can revert e584bf4dcb0161508962e8fc68756b7fb14de2f3 for now, since only partial application on top level breaks things, then we can merge this and #91 as well, and I will create separate follow-up issues (specs/arity issues and maybe better internal names generation) edit: reverted, the test was wrong anyway
Not to sound pessimistic but isn't one way to deal with this complexity by just not implementing and providing currying?
Currying, at least imho, is a common source of frustrating and somewhat confusing error messages in OCaml code. I've more often caused a compilation error accidentally currying things than I have intentionally using currying. It's trivial to write a let binding which is a manual curry.
@AeroNotix I agree "disallowing" currying is a way forward. But I think there still would be complexity in the compiler that needs to be introduced, possibly similar to the code present in this PR, in order to detect partial application and show an error. Or is there a way to configure the OCaml compiler to disallow it at the type checking step?
Hi! 👋🏽 since I'm currently not working on and have no plans to continue working on this version of the compiler, I'll close this PR. Thanks a lot for your contribution 🙏🏽
"this version" - implies there is another version. Is that the case?
relates to #44 relates to #90
specs are still wrong