search

a-recknagel / stenotype

Support for shorthand type annotations.
MIT License
3 stars 2 forks source link

[ENHANCEMENT]: Grouping/Precedence #34

Open maxfischer2781 opened 4 years ago

maxfischer2781 commented 4 years ago

Is your feature request related to a problem? Please describe. The infix Union stenotype grammar has ambiguous precedence with regards to prefix shorthands: await A or B can mean both Awaitable[Union[A, B]] or Union[Awaitable[A], B].

The meaning of this expression is currently implicitly defined by grammar structure: UNION is parsed before SHORTHANDS. It produces Union[Awaitable[A], B].

Describe the solution you'd like Decide on, clearly define and document precedence of expressions. Decide whether grouping is needed.

I'm in favour of prefix shorthands taking precedence: Shorthands signify protocols, which require entirely different code structure when optional. E.g. a Union[Iterable[A], B] is used either as c: B = ... or as for c: A in .... While having used such a type, I assume it is extremely rare.

Iff we want to be able to express both cases, grouping is needed. Parentheses are the canonical grouping symbol in Python, and I do not see any alternative. This would complicate tuple grammar similar to Python:

There is no need to define precedence of infix or and prefix ?. Semantically, they both define a Union.

Describe alternatives you've considered We could disallow ambiguous notation, and require grouping. For example, await A or B would be an error. It would have to be either (await A) or B or await (A or B).

This is a tradeoff between terseness of the common case and unambiguity in any case. Since type annotations are about correctness, favouring unambiguity over minor terseness would be a valid goal as well.

a-recknagel commented 4 years ago

One other alternative would be to default to mixed steno/standard typing, e.g. await Union[A, B] in order to avoid introducing round parentheses as a grouping construct. Would that be an option, or just a workaround?

maxfischer2781 commented 4 years ago

I'd rate it as a workaround for the time being. After some thought, unambiguous type hints seem preferable - so until we decide on what prefix TYPE infix TYPE means, only allowing prefix and infix separately makes sense.

Long-term, I find it preferable if stenotype does not come with edge cases -- it removes a lot of the appeal of having an easy typing syntax if you need to remember where it applies.