I’ve been writing an interpreter in Swift and have been finding enums incredibly useful. One feature thought that I thought would make life easier is the ability to create a super-enum that contains as its cases all the cases of its constituent enums:
For example, a number of functions in the recursive descent parser can only return a subset of all possible expressions.
Of course it’s already possible to represent the same data structure like this:
enum Token {
case binaryOperator(BinaryOperator)
case unaryOperator(UnaryOperator)
case booleanLiteral(BooleanLiteral)
}
Perhaps what I’m suggesting could just be syntactic sugar, but it’d make it much easier to switch over `Token` without worrying about all of the nested enums. The feature becomes even more useful if you think about a deeper hierarchy of enums. It would bring some of the power of protocols/POP to enums.
This raises a few questions such as:
- Case name collisions
- Associated types
- Raw values
But I can’t think of anything that cannot be addressed with sensible rules and conditions.
Not a response to the core of this, but to the motivating example: Sectioned (or multi-sorted in other cases) ASTs can also be represented by a singly-sorted AST and views over top
enum UnaryOperatorView {
case not
}
enum BinaryOperatorView {
case and
case or
}
enum BooleanLiteralView {
case `true`
case `false`
}
enum Token {
case not
case and, or
case `true`, `false`
var asUnaryOperator: UnaryOperatorView? {
switch self {
case .not: return .not
default: return nil
}
}
On Jul 31, 2017, at 5:43 PM, Ahmad Alhashemi via swift-evolution <swift-evolution@swift.org> wrote:
I’ve been writing an interpreter in Swift and have been finding enums incredibly useful. One feature thought that I thought would make life easier is the ability to create a super-enum that contains as its cases all the cases of its constituent enums:
For example, a number of functions in the recursive descent parser can only return a subset of all possible expressions.
Of course it’s already possible to represent the same data structure like this:
enum Token {
case binaryOperator(BinaryOperator)
case unaryOperator(UnaryOperator)
case booleanLiteral(BooleanLiteral)
}
Perhaps what I’m suggesting could just be syntactic sugar, but it’d make it much easier to switch over `Token` without worrying about all of the nested enums. The feature becomes even more useful if you think about a deeper hierarchy of enums. It would bring some of the power of protocols/POP to enums.
This raises a few questions such as:
- Case name collisions
- Associated types
- Raw values
But I can’t think of anything that cannot be addressed with sensible rules and conditions.
I think what you're asking for here is essentially some sort of (or special
case of) value subtyping, a topic near and dear to many.
···
On Mon, Jul 31, 2017 at 7:43 PM, Ahmad Alhashemi via swift-evolution < swift-evolution@swift.org> wrote:
I’ve been writing an interpreter in Swift and have been finding enums
incredibly useful. One feature thought that I thought would make life
easier is the ability to create a super-enum that contains as its cases all
the cases of its constituent enums:
> enum UnaryOperator {
> case not
> }
>
> enum BinaryOperator {
> case and
> case or
> }
>
> case BooleanLiteral {
> case `true`
> case `false`
> }
>
> typealias Token = UnaryOperator | BinaryOperator | BooleanLiteral
It would then be possible to do something like this:
For example, a number of functions in the recursive descent parser can
only return a subset of all possible expressions.
Of course it’s already possible to represent the same data structure like
this:
> enum Token {
> case binaryOperator(BinaryOperator)
> case unaryOperator(UnaryOperator)
> case booleanLiteral(BooleanLiteral)
> }
Perhaps what I’m suggesting could just be syntactic sugar, but it’d make
it much easier to switch over `Token` without worrying about all of the
nested enums. The feature becomes even more useful if you think about a
deeper hierarchy of enums. It would bring some of the power of
protocols/POP to enums.
This raises a few questions such as:
- Case name collisions
- Associated types
- Raw values
But I can’t think of anything that cannot be addressed with sensible rules
and conditions.
That solution seems way too verbose, and also not exactly type safe because you must handle optionals in addition to any new cases that arise, which are silently handled by the default case.
To Xiaodi: is this really just value subtyping? Seems like it would also require multiple inheritance for it to work as suggested. To me this seems more like sugar for an Either type containing an arbitrary number of types (actually a special case of that because it’s restricted to enums).
Either way it gets a big +1 from me.
···
On Jul 31, 2017, at 10:04 PM, Robert Widmann via swift-evolution <swift-evolution@swift.org> wrote:
Not a response to the core of this, but to the motivating example: Sectioned (or multi-sorted in other cases) ASTs can also be represented by a singly-sorted AST and views over top
enum UnaryOperatorView {
case not
}
enum BinaryOperatorView {
case and
case or
}
enum BooleanLiteralView {
case `true`
case `false`
}
enum Token {
case not
case and, or
case `true`, `false`
var asUnaryOperator: UnaryOperatorView? {
switch self {
case .not: return .not
default: return nil
}
}
/*etc.*/
}
The Valence library uses this to great effect.
~Robert Widmann
On Jul 31, 2017, at 5:43 PM, Ahmad Alhashemi via swift-evolution <swift-evolution@swift.org> wrote:
I’ve been writing an interpreter in Swift and have been finding enums incredibly useful. One feature thought that I thought would make life easier is the ability to create a super-enum that contains as its cases all the cases of its constituent enums:
For example, a number of functions in the recursive descent parser can only return a subset of all possible expressions.
Of course it’s already possible to represent the same data structure like this:
enum Token {
case binaryOperator(BinaryOperator)
case unaryOperator(UnaryOperator)
case booleanLiteral(BooleanLiteral)
}
Perhaps what I’m suggesting could just be syntactic sugar, but it’d make it much easier to switch over `Token` without worrying about all of the nested enums. The feature becomes even more useful if you think about a deeper hierarchy of enums. It would bring some of the power of protocols/POP to enums.
This raises a few questions such as:
- Case name collisions
- Associated types
- Raw values
But I can’t think of anything that cannot be addressed with sensible rules and conditions.