Create a PR for renaming FunctionExpression
#552
Assignees
Labels
Action-Item
Action item assigned by the WG
Comments
gibson042
added a commit
to gibson042/message-format-wg
that referenced
this issue
Dec 5, 2023
…rly when unsupported Fixes unicode-org#552
aphillips
pushed a commit
that referenced
this issue
Dec 8, 2023
…rly when unsupported (#554) * data-model: Align message.json with the documented interfaces * data-model: Better represent annotations in the data model, particularly when unsupported Fixes #552 * data-model: Drop operand from annotation nodes Operands are captured one level up, as expression node `arg` fields. * data-model: Remove inferrable `type` fields * data-model: Restore `annotation` abstraction * grammar: Reduce expression productions * Reference "private-use" before "reserved"
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is an action item from the 2023-12-04 teleconference.
Discussion thread:
See this comment thread for context.
EAO: We currently represent all annotations as “func”, including those that are private-use and reserved. A supported private-use annotation should show up in data model extension, but a reserved annotation or unsupported private-use annotation by definition could not. The names are not especially visible, but they do appear.
APP: We have two kinds of reserved things—statements and annotations. We’re talking here about annotations, which appear in expressions with sigils other than
:. EAO is proposing renaming interfaces in the data model to correspond with the ABNF.EAO: Clarification, this is RGN’s suggestions.
APP: I suggested later adding private-use annotations separately.
STA: What is reserved again?
APP: Anything we’ve reserved. As opposed to private-use, which is open for implementation innovation.
STA: An implementation that advertises support for private-use would need to expose such information in the data model, but error out for unsupported private-use or reserved annotations.
APP: Back on topic, do we want to rename FunctionExpression to AnnotationExpression?
STA: This may be related to markup, but I don’t object to the change now.
EAO: How do change advocates imagine an implementation supporting private-use to represent instances thereof? What we currently expect is extension of the data model, but if you don’t like that then what shape would you imagine?
APP: If we renamed as suggested, that resolves some of the challenge. That is less true with the FunctionExpression name, because a private-use annotation may not be function-like.
STA: To answer EAO, it should be possible to use a discriminated union type. I like renaming to AnnotationExpression. Is there a reason why that would not be a good idea?
EAO: I think the question is whether supported private use goes in what is now called FunctionExpression, or whether it belongs one level up.
STA: I have strong feelings in favor of a discriminated union, one way or the other.
APP: RGN, want to PR this?
RGN: Sure, I can do a PR.
EAO: What you’re describing might already be there, but please take a look.
STA: Is there a specific use case to help me understand?
EAO: An inline comment.
STA: Do we have a design doc on reservations and private use?
APP: We’re sure spending a lot of time on things no one can use. 🙂
The text was updated successfully, but these errors were encountered: