Support for Rules and Patterns

[LukeLongworth]

The set of functions for rules and patterns looks like it would be useful for manipulation of certain symbolic expressions. Should some or all of these functions be unbanned?

Some use case examples in the documentation are:

• Selectively applying trigonometric identity substitutions, such as ( let(sin(a)^2, 1 - cos(a)^2), letsimp (sin(x)^4) ) to give cos(x)^4 - 2*cos(x)^2 + 1
• Automatically simplifying some expressions involving factorials

My own use case that inspired me to look into this (may or may not be possible, I'm not sure):

• Declaring I and O to be multiplicative and additive identities respectively for symbolic matrix expression simplification

[sangwinc]

@LukeLongworth, this looks very reasonable to add. Can you please provide examples of exactly what you do need?

[sangwinc]

@LukeLongworth we may have a snag here. If you try just let(sin(a)^2, 1 - cos(a)^2) in Maxima then the return value is a new kind of operator -> which we've not accommodated. Indeed, using ?print you get

((MTEXT SIMP) ((MEXPT SIMP) ((%SIN SIMP) $A) 2) | --> |
 ((MPLUS SIMP) 1 ((MTIMES SIMP) -1 ((MEXPT SIMP) ((%COS SIMP) $A) 2)))) 

To fully support this feature we need to expand the parser (comments @aharjula?), or we insist on a workaround as shown here https://github.com/maths/moodle-qtype_stack/commit/cfd0887d71f5ca97e6df49275b4792d70dc95f3e#diff-aad04ae351ba675f6ae80a98e32ef7c4b57f41d6e0c614ec9f6d84e3b0d8ae28R2944 which avoids the problem of this return value in the Maxima -> PHP connection.

[aharjula]

Well, wrapping it and piping the return value out to some bit bucket instead of returning it would be the workaround for now. You can naturally add a new operator to the current parser, but:

1. The current parser is not really configurable, so the operator would also exist for the students, and if it needs to exist for them, then it might affect some parsing error messages.
2. Is it just a return value in an interesting form, or is it really an operator that can be used? Do we really want to parse things that could never be input?

I would rather start investing in the next-gen parser with its configurable lexers so that one could when needed, use a lexer that accepts that as an operator and otherwise allow simpler ones to be used. This would have less vocabulary and, thus, simpler syntax error messages. Basically, if it currently aims to provide localisable syntax lexers, it can easily also adjust and provide a larger syntax parser for return values from the CAS, or author side code, when need be.

[sangwinc]

I agree @aharjula that adapting the parser is too much work for this case, and probably prone to causing more problems. We'll document the use of let0. There is likely to be little error trapping when we forget as the parser throws an exception which will bring everything to an end...

@LukeLongworth could you create some use-cases and perhaps some docs?