Sealing up primitives #94
umazalakain
started this conversation in
RFC
Replies: 1 comment 1 reply
-
On aspect that I dislike about these implementations is that we have to wrap the The new Scala 3 Union Types allow to avoid this:
Do you see a way to achieve the same in Scala 2 without the union typ? |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
This is an early draft for a proposal that aims to clarify and consolidate the existing type hierarchy. Big disclaimer: I have little to no experience with Scala's type system. Comments and input are really appreciated ^_^
The existing structure mixes OOP and FP styles in that it
Mixing both styles can certainly be a good idea sometimes, but in this case adding a new primitive still requires adding the relevant pattern match cases in the relevant translation points, and at the same time we do not get exhaustiveness checks out of Scala. There are places where not adding a primitive to a pattern match clause causes the translation to crash, and while this is not bad by itself we do not get any warnings at compile time.
One could take the OOP approach and delegate all translation steps to the primitives. While certainly possible this might become a bit of a mess: translation steps deal with callbacks and need to keep track of environments and would need to pass them down to the primitive classes.
The other option is to go the FP way, seal the set of primitives, and do each of the translation steps in one single place. What we get out of it is exhaustiveness checking. If we want to add a primitive, we can do so, and the compiler will tell us about where we need to add pattern matching clauses. Furthermore, we can use traits to restrict the set of primitives that will be available in each of the translation steps.
Two naive examples, one without steps and one with steps:
Beta Was this translation helpful? Give feedback.
All reactions