Extending [expr] OperatorsRichard Suchenwirth$Revision: 1.6 $
This TIP proposes a way to define new operators for conditions and the expr command. It also includes demonstrations of how it might work in the examples: in tests inclusion in a list, and and, or, and not are aliases for "&&", "||", "!".
Inclusion of a value in a list is frequently tested with the construct
ICAgaWYge1tsc2VhcmNoIC1leGFjdCAkbGlzdCAkdmFsdWVdID49IDB9IHsuLi59
The proposal, first brought by Reinhard Max in the Tcl Chatroom, is to allow an in operator in the language understood by expr, and the condition parts of for, if and while, so that the above can be written as
ICAgaWYgeyR2YWx1ZSBpbiAkbGlzdH0gey4uLn0=
This is shorter to type and much better to read.
In the same vein, I propose to allow operators "and", "or", "not" to be resolved exactly like the current "&&", "||" resp "!" The new "operator aliases" are not shorter than the original operators, but definitely better readable - and easier typed too, as no Shift (or Alt-Gr on German keyboards) key is needed.
When Tcl was young, almost all users knew C, so the C style operators were a good choice. In recent years, there is tendency that Tcl is used by persons who have no or less experience with C, but come from other languages (etc. BASIC variants have the AND, OR, NOT operators) or have Tcl as a first language. For all these, the option of natural-language operators will make the learning just a little bit easier.
Donal K. Fellows remarked (on an earlier proposal relating to just an in operator) in the Tcl Chatroom: "On the plus side, it shouldn't be hard to implement (might need an extra opcode for lsearch, but that's pretty straightforward.)"
Pascal Scheffers proposed an extension mechanism for expr and conditions, so the proposed extensions to the expression language can be done in Tcl, with the commands:
IGV4cHJfcmVnaXN0ZXJfb3BlcmF0b3IgaW4gIHt2YWwgbGlzdH0ge2V4cHIge1tsc2VhcmNoIC1leGFjdCAkbGlzdCAkdmFsXT49MH19IGV4cHJfcmVnaXN0ZXJfb3BlcmF0b3IgYW5kIHtwIHF9ICAgICAge2V4cHIgeyRwICYmICRxfX0=IGV4cHJfcmVnaXN0ZXJfb3BlcmF0b3Igb3IgIHtwIHF9ICAgICAge2V4cHIgeyRwIHx8ICRxfX0=IGV4cHJfcmVnaXN0ZXJfb3BlcmF0b3Igbm90IHtwfSAgICAgICAge2V4cHIgeyEkcH19
Such operator registrations can have one or two arguments (for unary and binary operators, respective) in the second argument. The third argument is a body that is evaluated, with local variables from the argument list substituted, and returns the resulting value, to be substituted for the operator and its operands.
Alternatively, one could stipulate that expr interprets its arguments in the above sense when called like this:
IGV4cHIgb3BlcmF0b3IgaW4gIHt2YWwgbGlzdH0ge2V4cHIge1tsc2VhcmNoIC1leGFjdCAkbGlzdCAkdmFsXT49MH19IGV4cHIgb3BlcmF0b3IgYW5kIHtwIHF9ICAgICAge2V4cHIgeyRwICYmICRxfX0=
This would currently raise an error, hence cannot break existing code.
For a simple start, it shall be an error to define an operator both as unary and binary.
Rules for operator precedence, and a way of specifying the precedence level, will still be needed.
A feature sometimes discussed in , an assignment operator, could in the same way easily be added by users who so want:
IGV4cHIgb3BlcmF0b3IgPSB7dmFyTmFtZSB2YWx1ZX0ge3VwdmFyIDEgJHZhck5hbWUgdmFyOyBzZXQgdmFyICR2YWx1ZX0=
Reinhard Max has also proposed a unary empty operator:
ICBleHByIG9wZXJhdG9yIGVtcHR5IHtsaXN0fSB7ZXhwciB7W2xsZW5ndGggJGxpc3RdPT0wfX0=
This document has been placed in the public domain.