You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
we could automatically generate methods for accessing fields of these types. In this example it would be
method x {self = Vec { x }} = x
method y {self = Vec { y }} = y
There are some design decisions that should be made. First of all, when should we generate such methods? The possible options I see are the following (I prefer option 2 or 4).
Always, for ADT with single constructor (with some limitation related to existential types: see below).
For types explicitly marked as records (e.g., by a special keyword, or when the constructor name is omitted or the same as the name of type).
For each field that is shared between all constructors.
By explicitly marking the fields, e.g., by something like deriving in Haskell.
Moreover, for types that stores existential types, e.g.,
data T = T { X, a : X, b : Int }
it is not possible to generate some methods (method a in this example, but method b is still reasonable). If we follow option 2, then we should forbid existential types in records, or omit some automatically generated methods.
The text was updated successfully, but these errors were encountered:
For record-like types, e.g.,
we could automatically generate methods for accessing fields of these types. In this example it would be
There are some design decisions that should be made. First of all, when should we generate such methods? The possible options I see are the following (I prefer option 2 or 4).
deriving
in Haskell.Moreover, for types that stores existential types, e.g.,
it is not possible to generate some methods (method
a
in this example, but methodb
is still reasonable). If we follow option 2, then we should forbid existential types in records, or omit some automatically generated methods.The text was updated successfully, but these errors were encountered: