You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the PR 3581 discussion, it's noted that before the advent of the end notation supported inside square-bracket indexing, M[...] in the mathjs expression language amounted precisely to syntactic sugar for subset(M, index(...)). The introduction of the end notation broke that equivalence, in that end is now only interpreted inside the square bracket but not otherwise in index(...).
Would it be wise to restore the equivalence by supporting the appearance of end inside the index of a subset() call?
If so, what would be the best approach? Possibilities raised include:
Make both subset and index "raw functions" in the parser: subset would evaluate M, get the extent in each dimension, and then evaluate index in a context in which it could grab those extents, and add the correct value for end into the context for evaluating each one of its arguments.
Like (1) except also parseM[...] into the FunctionNode tree matching subset(M, index(...)), guaranteeing their semantics can't diverge in the future. This also allows the elimination of two entire subclasses of Node, namely IndexNode and AccessorNode, a nice simplification of the expression handling.
Go the other direction as (2): Parse index(blah, blee) into an IndexNode with arguments blah and blee, rather than a FunctionNode with operation index. Similarly, parse subset(M, stuff) into an AccessorNode with M as the object parameter and the result of parsing stuff as the index parameter of the Accessor node. Again, this change would keep the two syntaxes alike in perpetuity, but without the reduction in the number of Node types.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
In the PR 3581 discussion, it's noted that before the advent of the
endnotation supported inside square-bracket indexing,M[...]in the mathjs expression language amounted precisely to syntactic sugar forsubset(M, index(...)). The introduction of theendnotation broke that equivalence, in thatendis now only interpreted inside the square bracket but not otherwise in index(...).endinside the index of a subset() call?Make both subset and index "raw functions" in the parser: subset would evaluate M, get the extent in each dimension, and then evaluate index in a context in which it could grab those extents, and add the correct value for end into the context for evaluating each one of its arguments.
Like (1) except also parse
M[...]into the FunctionNode tree matchingsubset(M, index(...)), guaranteeing their semantics can't diverge in the future. This also allows the elimination of two entire subclasses of Node, namely IndexNode and AccessorNode, a nice simplification of the expression handling.Go the other direction as (2): Parse index(blah, blee) into an IndexNode with arguments blah and blee, rather than a FunctionNode with operation index. Similarly, parse subset(M, stuff) into an AccessorNode with M as the object parameter and the result of parsing stuff as the index parameter of the Accessor node. Again, this change would keep the two syntaxes alike in perpetuity, but without the reduction in the number of Node types.
Beta Was this translation helpful? Give feedback.
All reactions