TIP #133: Extending [expr] Operators 
Author Message
 TIP #133: Extending [expr] Operators

 TIP #133: EXTENDING [EXPR] OPERATORS
======================================
 Version:      $Revision: 1.1 $
 Author:       Richard Suchenwirth <Richard.Suchenwirth-Bauersachs_at_siemens.com>
 State:        Draft
 Type:         Project
 Tcl-Version:  8.5
 Vote:         Pending
 Created:      Tuesday, 08 April 2003
 URL:           http://www.*-*-*.com/
 WebEdit:       http://www.*-*-*.com/
 Post-History:

-------------------------------------------------------------------------

 ABSTRACT
==========

 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 "&&", "||", "!".

 RATIONALE
===========

 Inclusion of a value in a list is frequently tested with the construct

      if {[lsearch -exact $list $value] >= 0} {...}

 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

      if {$value in $list} {...}

 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 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.

 IMPLEMENTATION PROPOSALS
==========================

 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:

    expr_register_operator in  {val list} {expr {[lsearch -exact $list $val]>=0}}
    expr_register_operator and {p q}      {expr {$p && $q}}
    expr_register_operator or  {p q}      {expr {$p || $q}}
    expr_register_operator not {p}        {expr {!$p}}

 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:

    expr operator in  {val list} {expr {[lsearch -exact $list $val]>=0}}
    expr operator and {p q}      {expr {$p && $q}}

 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.


 assignment operator, could in the same way easily be added by users who
 so want:

    expr operator = {varName value} {upvar 1 $varName var; set var $value}

 COPYRIGHT
===========

 This document has been placed in the public domain.

-------------------------------------------------------------------------

 TIP AutoGenerator - written by Donal K. Fellows


  Announcements archived at http://www.*-*-*.com/

  Tcl/Tk at http://www.*-*-*.com/ ]]



Tue, 18 Oct 2005 06:43:22 GMT  
 TIP #133: Extending [expr] Operators


: 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:
:
:    expr_register_operator in  {val list} {expr {[lsearch -exact $list
:$val]>=0}}
:    expr_register_operator and {p q}      {expr {$p && $q}}
:    expr_register_operator or  {p q}      {expr {$p || $q}}
:    expr_register_operator not {p}        {expr {!$p}}
:
: 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.

Doesn't one run the risk of extensions by different developers
defining operators in conflicting manners?  Let alone the problem of
someone redefining something that you have already defined.

--
The Tenth Annual Tcl/Tk Conference <URL: http://www.tcl.tk/community/tcl2003 >
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.



Thu, 20 Oct 2005 18:09:09 GMT  
 TIP #133: Extending [expr] Operators

Quote:

>  For a simple start, it shall be an error to define an operator both as
>  unary and binary.

There should be strict rules, I think, for the names of these operators,
otherwise a pathological operator like "-1" could be defined and it
becomes
unclear how to evaluate "1-12".

What however with expressions like this:

   set a "a"
   set b {a b c d}
   expr "$a in $b"

(note the quotes)
Due to the expansion of a and b the expression becomes ambiguous or even
invalid.

This TIP does seem an opportunity to build in an existing extension:
introducing
procs as math functions.

Quote:
>  Rules for operator precedence, and a way of specifying the precedence
>  level, will still be needed.

I would prefer the simplest rules possible, like those used in fortran
90:
- user-defined unary operators take the highest precedence
- user-defined binary operators take the lowest precedence

Regards,

Arjen



Sat, 22 Oct 2005 15:11:58 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. list contains and tip 133

2. TIP #123: Adding an Exponentiation Operator to the [expr] Command

3. Reading more than 133 bytes

4. Program lockup on AST 133

5. Canon Pentium 133, 16 MB, Complete System

6. 486 dx4/100 faster than p-133?

7. Printing to PC 133 characters

8. INFO-ADA Digest V93 #133

9. Which gui for slow (133 Mhz) pc

10. expr eq/ne operator puzzle

11. TIP #182: Add [expr bool] Math Function

 

 
Powered by phpBB® Forum Software