unwanted AssertionError; KeySubscript.key type too narrow

[jvasileff]

The ElementOrSubrangeExpression in the line below:

shared void run() {
    Integer? x = 0;
    noop(empty[x else 1]); // <--- this line
}

is represented by the following redhat ast:

|  |  |  |  |  |  |  |  +  [Expression] (3:9-3:23) : Null
|  |  |  |  |  |  |  |  |  + [] [IndexExpression] (3:9-3:23) : Null
|  |  |  |  |  |  |  |  |  |  +  [BaseMemberExpression] (3:9-3:13) : empty : empty : value empty => empty
|  |  |  |  |  |  |  |  |  |  |  + empty [Identifier] (3:9-3:13)
|  |  |  |  |  |  |  |  |  |  |  +  [InferredTypeArguments]
|  |  |  |  |  |  |  |  |  |  +  [Element] (3:15-3:22)
|  |  |  |  |  |  |  |  |  |  |  +  [Expression] (3:15-3:22) : Integer
|  |  |  |  |  |  |  |  |  |  |  |  + else [DefaultOp] (3:15-3:22) : Integer
|  |  |  |  |  |  |  |  |  |  |  |  |  +  [BaseMemberExpression] (3:15-3:15) : Integer? : x : value run.x => Integer?
|  |  |  |  |  |  |  |  |  |  |  |  |  |  + x [Identifier] (3:15-3:15)
|  |  |  |  |  |  |  |  |  |  |  |  |  |  +  [InferredTypeArguments]
|  |  |  |  |  |  |  |  |  |  |  |  |  + 1 [NaturalLiteral] (3:22-3:22) : Integer

but fails to convert to ceylon.ast:

Exception in thread "main" ceylon.language.AssertionError "Assertion failed: Check precedence
    violated is AddingExpression key = expressionToCeylon(keySubscript.expression, update)"
    at ceylon.ast.redhat.keySubscriptToCeylon_.keySubscriptToCeylon(KeySubscript.ceylon:16)
    at ceylon.ast.redhat.subscriptToCeylon_.subscriptToCeylon(Subscript.ceylon:18)
    at ceylon.ast.redhat.elementOrSubrangeExpressionToCeylon_.elementOrSubrangeExpressionToCeylon(ElementOrSubrangeExpression.ceylon:14)
    at ceylon.ast.redhat.primaryToCeylon_.primaryToCeylon(Primary.ceylon:43)

since (I assume) ElseOperation is not assignable to AddingExpression.

[lucaswerkmeister]

Hrm. I think all the RangeSubscript subtypes have AddingExpression children because they’re equivalent to SpanOperation and friends, where this is defined by the spec (SpanningExpression is right above AddingExpression, so this follows directly from table 6.1). And KeySubscript… not sure. There’s certainly some ambiguity if you allow any expression there (empty[0..1] could just mean empty[(0..1)], because Correspondence doesn’t put any restriction on the Key type), perhaps that’s why. But it’s not in the spec, and the parser allows any functionOrExpression there, which is the highest expression rule iirc.

@gavinking is it correct to say that empty[x else 1] is legal, and the ambiguity is always resolved in favor of the more specific subscripts (span, measure~~, span from/to~~)?

[gavinking]

§6.8.7 says:

Operands within brackets in any subrange operator are parsed as if they were operands of the .. or : operators.

[gavinking]

Oh, I see. You're saying that strictly speaking this restriction should also apply to the lookup operator. You're right, it should, if we wanted to be really pedantic about this, but I'm not terribly motivated to add such a restriction. As you say, it's easy and harmless to resolve the ambiguity in favor of the interpretation as a subrange operator, rather than as a lookup operator applied to a range.

[lucaswerkmeister]

Thanks, then I’ll change KeySubscript to allow this.

[jvasileff]

Thanks!