Sugaring: Reflexive -Ish aliases?

[lucaswerkmeister]

At the moment, we define the -Ish aliases like this:

shared alias BodyIsh => Body|{Declaration|Statement*};

I. e., BodyIsh includes Body. The rationale behind this is that if you already have a Body object from somewhere, you should be able to use it in the create functions.

However, that prevents the use of the following syntax:

block {
    Statement(…),
    Statement(…),
    …
}

Because this is only supported “if the parameter list has an unassigned parameter of type exactly Iterable<T,N> for some types T and N”, i. e., if BodyIsh was just {Declaration|Statement*}.

Should we make the aliases “non-reflexive”? I think the named arguments syntax would be a pretty big advantage…

[lucaswerkmeister]

Okay, I think I’ve got a good solution. I’ll explain it on the example of CaseTypes:

• Non-reflexive alias.
• Shared caseTypes function which takes only CaseTypesIsh.If you already have a caseTypes object, just use it directly. And I don’t think users should ever have values of type CaseTypes|CaseTypesIsh.
• Unshared function which takes CaseTypes|CaseTypesIsh, used by the other functions.
• In other functions, where the caseTypes aren’t the last parameter, declare parameter type CaseTypes|CaseTypesIsh, and use the internal function.

This allows

value cd = classDefinition {
    // ...
    caseTypes = { "true", "false" };
    // ...
}

as well as

value cd = classDefinition {
    // ...
    caseTypes = selfCaseTypes;
    // ...
}

and

value ct = caseTypes {
    for (i in 1:nStates)
        "S``i``"
}

In general, however, it must be noted that in ceylon.ast.create, the idea of “one pattern fits all” must be abandoned, and other kinds of nodes will require different treatment.

[lucaswerkmeister]

Actually… let’s make the caseTypes etc. functions variadic.

[lucaswerkmeister]

…that will require us to remove the Absent trick, at least from the shared function. Which is okay – it’s more used for internals, I think.