Segments with set notation #19

New issue

Open

opened 2025-10-12 09:42:33 +00:00 by UserCurt · 0 comments

UserCurt commented

2025-10-12 09:42:33 +00:00

(Migrated from codeberg.org)

/A{/X/, /Y/Z/}B -- Beginning and ending with the dot operator segment delimiter /
/A{/X, /Y/Z}/B -- Only beginning with the dot operator segment delimiter /
/A/{X/, Y/Z/}B -- Only ending with the dot operator segment delimiter /
/A/{X, Y/Z}/B -- Neither beginning nor ending with the dot operator segment delimiter /

All options would resolve to [/A/X/B; /A/Y/Z/B] in the above examples, but there can be use different cases for some of these options and different issues for some of these options.

Option 4 is a direct extension of the syntax proposed in #3 in so far that the syntax described in that issue is the edge case of the syntax of option 4. In this case, each element of the set contains just one field and no additional segments.

All options can mix other operations like parenthesis and brace indexing described in #5 or filtering (no issue created yet) between segments. Using the syntax of option 1, the example /A{/X(2)/Y/, /U(3)/V/}B would show this. Options 1 and 2 could even allow for using different operations to happen first before applying any segment dot operations. For example, using the syntax of option 1, /A{(1)/X/, (2)/Y/}B would resolve to [/A(1)/X/B; /A(2)/Y/B]. Options 2 and 4 would similarly allow for using different operations to happen last. For example, using the syntax of option 2, /A{/X(1), /Y(2)}/B would resolve to [/A/X(1)/B; /A/Y(2)/B]. Option 4 would not support either starting or ending with other operations. Only option 2 would include both features, like in /A{(1)/X(3), (2)/Y(4)}/B which would resolve to [/A(1)/X(3)/B; /A(2)/Y(4)/B].

Options 2 and 3 could be taken to the extreme with a degenerate case of containing no segments (dot operations) and solely other operations like parenthesis or brace indexing. For example, using syntax of option 2, /A{/X(2), (3)}/B would resolve to [/A/X(2)/B; /A(3)/B]. However, this can result in ambiguity in the extreme case where all elements are degenerate. In the example /A{(2),(3)}/B, there are two interpretations of {(2),(3)} by the parser:

The parser could interpret the parenthesis (2) and (3) as grouping syntax described in #2. Each parenthesis would be numerically evaluated to their contents in this example, so {(2),(3)} would be equivalent to {2,3}, which normally accesses the particular element within the cell array using brace notation described in #5. The mpath expression would be equivalent to /A{2,3}/B.
The parser could interpret this is as a set of parenthesis operators accessing the second and third element of A, resolving to [/A(2)/B; /A(3)/B]. Though in this example, this is equivalent to /A(2:3)/B.

Is there a use case where all individual elements in the set are degenerate while not having an equivalently simple or concise syntax? I cannot think of any, but perhaps one exists. If the answer is no, these ambiguous degenerate cases could be chosen to be interpreted as brace operations. However, this could still be confusing to the user. One work-around is to use detection of arithmetic within set notation as a flag for whether it is brace notation or segment set notation. This could be difficult to implement, likely will result in unforeseen buggy behavior, and would also be confusing to the user. Neither of thees are ideal, though the former seems somewhat reasonable despite the possible source of confusion.
Options 2 and 3 could allow for usage of the identity operator (no-operation) for entries in the set. There is currently no dedicated notation for the identity element, but that could handled by an empty element in the set, like in /A{/X,}/B or /A{, /Y/Z}/B. Commas would have to be required here. Option 3

Options 1 and 2 partially conflict with brace notation proposed in #5 since the open brace { directly proceeds after a field name, A in these instances. To allow these notations, the parser would have to consider context and contents of the brace. Following syntax option 2, the example /A{/X, /Y/Z}/B clearly cannot be a brace operation.

Option 4 could be easily confused in the degenerate case with each element containing only a single field while using solely numerical indexing described in #2. The mpath expression /A/{1,2}/B could be easily misread as /A{1,2}/B while having two different meanings. This is a relatively minor issue.

Options 1 and 3 will require each element of the set to end in / and for a field to directly proceed after the end brace } and effectively requiring another segment. Option 2 and 4 seems like strictly better choices over option 1 and 3 in this regard as they do not have this requirement.

All options would support nested sets. For example, using the syntax of option 2, /X{/A/B, /C{/Q/R, /S}/D}/Y would resolve to [/X/A/B/Y, <missing>; /X/C/Q/R/D/Y, /X/C/S/D/Y]. Automatic dimension assignment would have to now consider how not all branches are necessarily the same length. In addition, automatic dimension assignment should allow assignment of dimensions used in other parallel branches. For example, /X/{ A/{U/V, S/T}/B, C/{G/H, M/N}/D }/Y would resolve to [/X/A/U/V/B/Y, /X/A/S/T/B/Y; /X/C/G/H/D/Y, /X/C/M/N/D/Y] where the two inner-sets are both automatically assigned dimension 2.

Option 2 syntax can be simplified when used at the root level when there are no segments or operations directly preceding or proceeding it. For example, /X, /Y/Z would unambiguously be equivalent to {/X, /Y/Z}.

In my opinion, options 2 and 4 seem the most reasonable choices out of the four. Option 4 is nice because it directly expands the syntax described in #3 without any major anticipated issues. Option 2 is enticing due to supporting starting and ending in other kinds of operations. Implementation of both options would be redundant as option 2 would enable anything option 4 would offer.

This is an extension of feature request #3, dot operation with set notation. This issue proposes allowing not only fields but also segments within set notation. Elements within the set need to be consistent in types, but there are four possible types to consider: 1. `/A{/X/, /Y/Z/}B` -- Beginning and ending with the dot operator segment delimiter `/` 2. `/A{/X, /Y/Z}/B` -- Only beginning with the dot operator segment delimiter `/` 3. `/A/{X/, Y/Z/}B` -- Only ending with the dot operator segment delimiter `/` 4. `/A/{X, Y/Z}/B` -- Neither beginning nor ending with the dot operator segment delimiter `/` All options would resolve to `[/A/X/B; /A/Y/Z/B]` in the above examples, but there can be use different cases for some of these options and different issues for some of these options. **Option 4** is a direct extension of the syntax proposed in #3 in so far that the syntax described in that issue is the edge case of the syntax of option 4. In this case, each element of the set contains just one field and no additional segments. **All options** can mix other operations like parenthesis and brace indexing described in #5 or filtering (no issue created yet) between segments. Using the syntax of option 1, the example `/A{/X(2)/Y/, /U(3)/V/}B` would show this. **Options 1 and 2** could even allow for using different operations to happen first before applying any segment dot operations. For example, using the syntax of option 1, `/A{(1)/X/, (2)/Y/}B` would resolve to `[/A(1)/X/B; /A(2)/Y/B]`. **Options 2 and 4** would similarly allow for using different operations to happen last. For example, using the syntax of option 2, `/A{/X(1), /Y(2)}/B` would resolve to `[/A/X(1)/B; /A/Y(2)/B]`. **Option 4** would not support either starting or ending with other operations. Only **option 2** would include both features, like in `/A{(1)/X(3), (2)/Y(4)}/B` which would resolve to `[/A(1)/X(3)/B; /A(2)/Y(4)/B]`. **Options 2 and 3** could be taken to the extreme with a degenerate case of containing no segments (dot operations) and solely other operations like parenthesis or brace indexing. For example, using syntax of option 2, `/A{/X(2), (3)}/B` would resolve to `[/A/X(2)/B; /A(3)/B]`. However, this can result in ambiguity in the extreme case where all elements are degenerate. In the example `/A{(2),(3)}/B`, there are two interpretations of `{(2),(3)}` by the parser: - The parser could interpret the parenthesis `(2)` and `(3)` as grouping syntax described in #2. Each parenthesis would be numerically evaluated to their contents in this example, so `{(2),(3)}` would be equivalent to `{2,3}`, which normally accesses the particular element within the cell array using brace notation described in #5. The mpath expression would be equivalent to `/A{2,3}/B`. - The parser could interpret this is as a set of parenthesis operators accessing the second and third element of `A`, resolving to `[/A(2)/B; /A(3)/B]`. Though in this example, this is equivalent to `/A(2:3)/B`. Is there a use case where all individual elements in the set are degenerate while not having an equivalently simple or concise syntax? I cannot think of any, but perhaps one exists. If the answer is no, these ambiguous degenerate cases could be chosen to be interpreted as brace operations. However, this could still be confusing to the user. One work-around is to use detection of arithmetic within set notation as a flag for whether it is brace notation or segment set notation. This could be difficult to implement, likely will result in unforeseen buggy behavior, and would also be confusing to the user. Neither of thees are ideal, though the former seems somewhat reasonable despite the possible source of confusion. **Options 2 and 3** could allow for usage of the identity operator (no-operation) for entries in the set. There is currently no dedicated notation for the identity element, but that could handled by an empty element in the set, like in `/A{/X,}/B` or `/A{, /Y/Z}/B`. Commas would have to be required here. **Option 3** **Options 1 and 2** partially conflict with brace notation proposed in #5 since the open brace `{` directly proceeds after a field name, `A` in these instances. To allow these notations, the parser would have to consider context and contents of the brace. Following syntax option 2, the example `/A{/X, /Y/Z}/B` clearly cannot be a brace operation. **Option 4** could be easily confused in the degenerate case with each element containing only a single field while using solely numerical indexing described in #2. The mpath expression `/A/{1,2}/B` could be easily misread as `/A{1,2}/B` while having two different meanings. This is a relatively minor issue. **Options 1 and 3** will require each element of the set to end in `/` and for a field to directly proceed after the end brace `}` and effectively requiring another segment. Option 2 and 4 seems like strictly better choices over option 1 and 3 in this regard as they do not have this requirement. **All options** would support nested sets. For example, using the syntax of option 2, `/X{/A/B, /C{/Q/R, /S}/D}/Y` would resolve to `[/X/A/B/Y, <missing>; /X/C/Q/R/D/Y, /X/C/S/D/Y]`. Automatic dimension assignment would have to now consider how not all branches are necessarily the same length. In addition, automatic dimension assignment should allow assignment of dimensions used in other parallel branches. For example, `/X/{ A/{U/V, S/T}/B, C/{G/H, M/N}/D }/Y` would resolve to `[/X/A/U/V/B/Y, /X/A/S/T/B/Y; /X/C/G/H/D/Y, /X/C/M/N/D/Y]` where the two inner-sets are both automatically assigned dimension 2. **Option 2** syntax can be simplified when used at the root level when there are no segments or operations directly preceding or proceeding it. For example, `/X, /Y/Z` would unambiguously be equivalent to `{/X, /Y/Z}`. In my opinion, options 2 and 4 seem the most reasonable choices out of the four. Option 4 is nice because it directly expands the syntax described in #3 without any major anticipated issues. Option 2 is enticing due to supporting starting and ending in other kinds of operations. Implementation of both options would be redundant as option 2 would enable anything option 4 would offer.