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
<https://github.com/typelift/Valence/blob/master/Tests/SystemF.swift#L111>.
~Robert Widmann
> On Jul 31, 2017, at 5:43 PM, Ahmad Alhashemi via swift-evolution
> <[email protected]> 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:
>
>> scanToken() -> Token
>>
>> indirect enum Expr {
>> case binary(op: BinaryOperator, lhs: Expr, rhs: Expr)
>> }
>
> 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.
>
> Interested to read your thoughts.
>
> -Ahmad
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
