Dot operation by numerical index #2

New issue

Open

opened 2025-10-11 02:15:14 +00:00 by UserCurt · 2 comments

UserCurt commented

2025-10-11 02:15:14 +00:00

(Migrated from codeberg.org)

Structs and tables have ordered fields and variables. This feature request is to add support for indexing these by numerical index.

In its most basic form, it would be a single positive integer following the path separator: /1. During resolve, if out of range, it would throw an error depending on the value of NullField. For multiple indices, there are various points that will have to be considered below. The syntax on these is not final.

Equally spaced indices: Using MATLAB's colon syntax, this would look like /1:3, /1:2:10.

Concatenation: Using MATLAB's colon syntax, this would look like /[1, 3, 10], /[1, 3:4, 9]. Commas would be optional in this case as long as there is whitespace, like in /[1 3 10], /[1 3:4 9]. Alternatively, dot operation with set notation described in #3 can be re-used here without the need for using new syntax, like in /{1, 3, 10}, /{1, 3:4, 9}. Although this deviates from MATLAB's bracket syntax, it matches other syntax in mpath while also avoiding confusion with brackets proposed in a yet-created issue on filtering.

Last element: Using the same end keyword as MATLAB, /{1 end}. Note that /end will not access the last field but rather the field named end. Similarly, if using set notation, /{1, end} would treat end as a field name. Some notation like parenthesis would have to be introduced to make this unambiguous, like in /(end) or /{1, (end)}. When end is used in this manner, it does not look so elegant. A value of 0 or -1 would work if used by itself but would not handle operations described below. A symbol could be used in place of the keyword end: /$, /^, /@, `` -- none of these I am fond of. It could be surrounded or prefixed with $,like in /$end, /{1, $end} or /$end$, /{1, $end$}, which would work well with the $ syntax in the not-yet-created feature request proposing referencing variables from within an mpath expression.

Grouping and operations: In colon syntax, it can be helpful to reference the last element, like in /1:2:end. Also, math is often applied to the last element, which can often require grouping, like in: /(end-1), /(end/2), /((end-1)/2). This can work fine for general arithmetic, but it is unclear if or how to apply operations like floor, ceiling, and round. This could require a general framework of calling functions from within an mpath string. These could be prefixed with $ like before.

This syntax will have much similarity with syntax to be used in paren and brace operations. Usage of [] notation may be preferred over {} for this fact alone as braces wouldn't normally be used within parenthesis or braces in MATLAB indexing. Though the mpath syntax does not have to mirror MATLAB identically, so usage of {} syntax should still be a consideration.

Structs and tables have ordered fields and variables. This feature request is to add support for indexing these by numerical index. In its most basic form, it would be a single positive integer following the path separator: `/1`. During `resolve`, if out of range, it would throw an error depending on the value of `NullField`. For multiple indices, there are various points that will have to be considered below. The syntax on these is not final. **Equally spaced indices:** Using MATLAB's colon syntax, this would look like `/1:3`, `/1:2:10`. **Concatenation:** Using MATLAB's colon syntax, this would look like `/[1, 3, 10]`, `/[1, 3:4, 9]`. Commas would be optional in this case as long as there is whitespace, like in `/[1 3 10]`, `/[1 3:4 9]`. Alternatively, dot operation with set notation described in #3 can be re-used here without the need for using new syntax, like in `/{1, 3, 10}`, `/{1, 3:4, 9}`. Although this deviates from MATLAB's bracket syntax, it matches other syntax in mpath while also avoiding confusion with brackets proposed in a yet-created issue on filtering. **Last element:** Using the same `end` keyword as MATLAB, `/{1 end}`. Note that `/end` will not access the last field but rather the field named `end`. Similarly, if using set notation, `/{1, end}` would treat `end` as a field name. Some notation like parenthesis would have to be introduced to make this unambiguous, like in `/(end)` or `/{1, (end)}`. When `end` is used in this manner, it does not look so elegant. A value of 0 or -1 would work if used by itself but would not handle operations described below. A symbol could be used in place of the keyword `end`: `/$`, `/^`, `/@`, `` -- none of these I am fond of. It could be surrounded or prefixed with `$`,like in `/$end`, `/{1, $end}` or `/$end$`, `/{1, $end$}`, which would work well with the `$` syntax in the not-yet-created feature request proposing referencing variables from within an mpath expression. **Grouping and operations**: In colon syntax, it can be helpful to reference the last element, like in `/1:2:end`. Also, math is often applied to the last element, which can often require grouping, like in: `/(end-1)`, `/(end/2)`, `/((end-1)/2)`. This can work fine for general arithmetic, but it is unclear if or how to apply operations like floor, ceiling, and round. This could require a general framework of calling functions from within an mpath string. These could be prefixed with `$` like before. This syntax will have much similarity with syntax to be used in paren and brace operations. Usage of `[]` notation may be preferred over `{}` for this fact alone as braces wouldn't normally be used within parenthesis or braces in MATLAB indexing. Though the mpath syntax does not have to mirror MATLAB identically, so usage of `{}` syntax should still be a consideration.

UserCurt commented

2025-10-13 23:35:30 +00:00

(Migrated from codeberg.org)

One consideration not discussed so far is the representation of these in a string conversion of an mpath pointer after parsing an mpath expression since representations are not unique. The comment here discusses it in the context of parenthesis operations #5, and they similarly translate to this issue.

One consideration not discussed so far is the representation of these in a string conversion of an mpath pointer after parsing an mpath expression since representations are not unique. The comment [here](https://codeberg.org/UserCurt/mpath/issues/5#issuecomment-7714322) discusses it in the context of parenthesis operations #5, and they similarly translate to this issue.

UserCurt referenced this issue from a commit

2026-08-01 20:33:15 +00:00

Remove unfinished numeric member indexing

UserCurt commented

2026-08-01 20:34:41 +00:00

Owner

An early version of DotIndex was introduced in commit 5c538e6. It was removed in commit 86502e0 during cleanup in preparation for v1 release but can be re-introduced in the future when this issue is being addressed.

An early version of `DotIndex` was introduced in commit `5c538e6`. It was removed in commit `86502e0` during cleanup in preparation for v1 release but can be re-introduced in the future when this issue is being addressed.

UserCurt referenced this issue

2026-08-02 09:52:31 +00:00

Support numeric range syntax for indices #51

UserCurt referenced this issue

2026-08-02 09:59:14 +00:00

Support end and expressions in numeric indices #52

UserCurt referenced this issue

2026-08-04 09:28:23 +00:00

Segments with set notation #19