Skip to content

Define function composition for :string values #798

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 6 commits into from
Oct 21, 2024
Merged

Define function composition for :string values #798

Changes from 3 commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
580b659
Define function composition for :string values
eemeli May 22, 2024
dd11a2c
Update spec/registry.md as suggested by @stasm in #814
eemeli Jul 8, 2024
385d14b
Drop the "only"
eemeli Jul 15, 2024
83289b1
Merge branch 'main' into string-composition
eemeli Oct 10, 2024
ed81ecd
Update text following code review comments
eemeli Oct 10, 2024
3f70608
Merge branch 'main' into string-composition
aphillips Oct 18, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 8 additions & 0 deletions spec/registry.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -359,6 +359,14 @@ the `:string` selector performs as described below.

The `:string` function returns the string value of the resolved value of the _operand_.

#### Composition

When an _operand_ or an _option_ value uses a _variable_ annotated,
directly or indirectly, by a `:string` _annotation_,
its resolved value contains the string value of the _operand_ of the annotated _expression_,
together with its resolved locale and directionality,
and no _option_ values.
Copy link
Member

@aphillips aphillips Jul 15, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about implementation defined namespaced options?

.input {wildebeest :string addison:normalize=nfc}

Copy link
Collaborator Author

@eemeli eemeli Jul 15, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They'd be lost, unless you're using a different :string than the one we define here. If you need options, then you could/should be using :addison:string.

Copy link
Member

@aphillips aphillips Jul 15, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That doesn't make sense to me?

Suppose I'm @mihnita and suppose I'm writing the ICU4J implementation. Now suppose I want to support skeletons for dates. I want that to look like: {$d :datetime icu:skeleton=yMMMdjm}, not {$d icu:datetime icu:skeleton=yMMMdjm}. Make sense so far?

I don't want to namespace the core function, because I want other options to work unchanged. Obviously, my namespaced option won't work in implementations where it isn't recognized. But dropping it on the floor doesn't make sense.

Copy link
Collaborator Author

@eemeli eemeli Jul 16, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a fair point; I filed #829 as a consequence of thinking through some of the implications here.

Technically, we do pass through all :datetime options so your example would be fine. For :string, I'd rather hoped that we could avoid having to deal with any options in composition.

That means that something like your addison:normalize could still work, as long as it changed the resolved string value of the expression, rather than getting passed along separately to the next consumer of the value.

Is that enough?

Copy link
Member

@aphillips aphillips Jul 16, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think :string (or whatever :x we define) only controls the options it owns. It's okay to say that :string passes none of its built-in options.

I think we should say that implementation-defined or user-installed installed options MAY be passed in the resolved value or swallowed by the implementation, while unrecognized (but otherwise valid) options MUST be passed in the resolved value.

This would permit an implementation to "eat" an option so that it has no downstream effect. You'd want this on destructive options:

.local $a = {McGowan :string x:transform=uppercase}
.local $b = {$a :append string=|_foo|}
.match {$b}
MCGOWAN_foo {{Should match because x:transform is not transitive}}
* {{...}}

Copy link
Collaborator Author

@eemeli eemeli Jul 16, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What your example shows is possible with the currently proposed text, including an alternate version where you'd replace the second declaration with

.local $b = {$a :string x:append=|_foo|}

The specific question that I think we should ask here is, "Is there any reasonable custom option for :string that would not modify the input string and get swallowed up?"

If we can think of at least one, then we should change the text here.

Copy link
Member

@aphillips aphillips Sep 9, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't think of one for :string that would behave in that way.

I think we should adopt a formula for dealing with options. I would reword this as:

Suggested change
and no _option_ values.
The _resolved value_ of a `:string` _annotation_ contains
the resolved string value of the _operand_,
the resolved locale of the _operand_,
and the resolved direction of the _operand_.
None of the _options_ defined by `:string` are part of the _resolved value_.

We might want a note to go with this to signal our intention:

Note

Custom or implementation-defined options that modify
the operand result in a modification of the resolved string value
of the operand and aren't included in the resolved value.


## Numeric Value Selection and Formatting

### The `:number` function
Expand Down