One of the styles for writing expressions, with operations '''in-between''' the operands (e.g. `6 * 7`), as contrasted to ''postfix'' (e.g. `6 7 *`; operations follow operands, as in [RPN]) and ''prefix'' (e.g. `* 6 7`; operations come before operands, as in [Tcl] in general). Infix notation for mathematical expressions is by far the most common, and is in Tcl supported by [expr]. ---- As of 2006-10-14, [infix] is also the name of a Tcl package (and command defined by this package) that lets programmers write sequences of mathematical formulae in the familiar infix form. A short example: package require infix 0.2 ::infix::core::setup base numconst expr::ops expr::fun proc ngon_corner {num_sides radius} { infix { n <- num_sides r <- radius } { alpha = acos(-1) / n ; # acos(-1) = pi r*cos(alpha), r*sin(alpha) } } ngon_corner 6 10 ; # Returns "8.66025403784 5.0" - a two element list A notable feature is that the [little language] implemented by this package is completely configurable (setting it up for [expr]-like operations is what the ::infix::core::setup command does), so you can define new operations, or define the usual ones to do something unusual. A setting that turns +, -, etc. into the operations of the [math::bignum] package is included with the infix package. The code is available at http://abel.math.umu.se/~lars/tcl/infix.tar.gz (requires tcllib, tcllib 1.8 is sufficient). A paper on the package (which includes the entire source code, commented and explained) is available at http://abel.math.umu.se/~lars/tcl/infix.pdf -- [Lars H] ---- **Some kind of a user's manual (incomplete)** The user commands created by the package are ****'''::infix::core::setup''' ''?module ...?''**** Creates a command '''infix''' in the namespace it is called from, and loads the listed ''module''s of settings for the little language of that '''infix''' command. See below for lists of defined modules and the syntax of the '''infix''' command. ****'''::infix::core::opalias''' ''name type cmd ?arg ...?''**** Define a new operation ''name'' of type ''type'' that gets implemented by appending the operand(s) to the command prefix ''cmd ?arg ...?'', as specified. Any previous meaning of the token ''name'' gets overwritten. The possible ''type''s include: binary ''priority'': A binary, left-associative operation with priority as specified. binary ''priority associativity'': A binary operation with priority and associativity as specified. Possibilities for ''associativity'' include '''right-associative''', '''non-associative''', and '''n-ary'''. prefix ''priority'': A unary prefix operation with priority as specified. postfix ''priority'': A unary postfix operation with priority as specified. The priorities should be Tcl numbers (non-integers are fine). Higher priority means tighter binding to the operands. In case of equal priority, the associativity setting is used to resolve which operation acts on which operands. The standard modules uses priorities in the range -2 (for ;) to 14 (for factorial), with + at 10, * at 11, and ** (right-associative) at 12. Example (requires Tcl 8.5): ::infix::core::opalias ++ {binary 10} ::tcl::mathfunc::hypot ([MetaFont] uses `++` for "Pythagorean addition": length of hypothenuse in right triangle where other sides have these lengths. C programmers no doubt find this very strange.) ****'''::infix::core::funalias''' ''name numargs cmd ?arg ...?''**** Define a new function ''name'' with ''numargs'' arguments that gets implemented by appending the argument(s) to the command prefix ''cmd ?arg ...?'', as specified. Any previous meaning of the token ''name'' gets overwritten. ''numargs'' may be '''any''' (in which case any number of arguments are accepted) or an integer. ***The infix command*** The '''infix''' command has the syntax : '''infix''' ''symlinks body'' The ''body'' is where the actual expressions in the infix little language are written; the infix command returns the value of (the last statement in) the body. The ''symlinks'' argument links symbolic names appearing in the ''body'' to Tcl variables in the context from which ''infix'' was called. The format of the ''symlinks'' is a list with a multiple of three elements. The first element in a triplet is the infix body symbolic name. The last element in a triplet is the external quantity to which the symbolic name is linked. The middle element of the triplet is an "arrow" that determines how the two are linked: `<-`: Input-only value; the external quantity is the name of a variable whose value is copied to the symbol. `->`: Output-only value; the external quantity is the name of a variable which is set to the final value of the symbol. `<->`: Input&output value; combines `<-` and `->`. `<=`: Input-only constant; the external quantity becomes the value of the symbol. Useful for constants that don't fit into the infix body syntax. ` a b <- b } { a := a + b } but also infix { a <- a b <- b c -> a } { c = a + b } To Be Continued... ***List of modules*** Each module ''module'' is implemented by the package `infix::''module''`, so anyone can define new modules. The following are those that come with the infix package itself. +++ base Basic definitions: parentheses for grouping, `=` for definition, `:=` for assignment, semicolon as separator, and comma as list constructor. expr::ops The unary and binary operations of [expr]. expr::fun The [expr] built-in functions. expr::ternary The [expr] ternary `?:` operation. (See `ifthen` for an alternative.) softsemicolon A more forgiving statement seprator. The `base` semicolons may only appear ''between'' expressions, but this relaxes the syntax so that a semicolon is effectively ignored if there is no expression after it. ifthen Implements expression choices of the form '''if''' ''condition'' '''then''' ''expression'' '''else''' ''expression'' '''fi''' (also allowing '''elseif''' clauses and omitting the '''else''' clause). Unlike `?:`, this can have semicolons and the like in the ''expression''s without a need to wrap them up in parentheses. numconst Makes symbols that look like numeric constants be interpreted as such. (Without it, e.g. `0`, `1`, and `3.5` behave just like `x` and `y`.) Underscore is a substitute for minus sign in exponents: `3.2e_1` is 3.2*10**-1. bignum Operations as for `expr::ops`, but implemented using the [math::bignum] commands, with their representation for values. Numeric constants are supported, as are the postfix operations `!` ([factorial]) and `!!` (semifactorial), and functions `sqrt`, `powm`, `fromstr`, and `tostr`. Compatible with the `ifthen` module. TeX::semi Changes the tokenizer, so that [TeX]-style control sequences such `\alpha` and `\cdot` count as tokens. expr::delim Some [expr]-functions written as delimiters. listbracket Brackets for list construction and indexing. +++ **Example: complex numbers** In want of a module for this, operations on complex numbers (as implemened using the [math::complexnumbers] package) are fairly easy to set up using '''opalias''' and '''funalias'''. First we need the basic [package require]s: package require infix infix::core::setup base package require math::complexnumbers Then we can define the operations `+`, `-`, `*`, `/`, and `**`: infix::core::opalias + {binary 10} math::complexnumbers::+ infix::core::opalias - {try {binary 10} - {prefix 13} -} math::complexnumbers::- infix::core::opalias * {binary 11} math::complexnumbers::* infix::core::opalias / {binary 11} math::complexnumbers::/ infix::core::opalias ** {binary 12 right-associative} math::complexnumbers::pow The `try` part in the definition of `-` is because there are two common operations denoted by minus: subtraction (binary) and negation (unary prefix). Both interpretations are tried, in that order. Defining the functions should be equally straightforward, but as it turns out version 0.2 of infix has a bug in the definition of infix::core::funalias, so we need to fix that first: proc ::infix::core::funalias {name numargs cmd args} { set ns [uplevel 1 {::namespace eval infix {::namespace current}}] set fcmd [uplevel 1 [list ::namespace which -command $cmd]] if {$fcmd eq ""} then { return -code error "Undefined command: $cmd" } set ${ns}::tokentype($name) function set ${ns}::function($name) [list $numargs byvalue\ [list ::concat [linsert $args 0 $fcmd]]] } After that, the complex-valued functions are trivial. foreach fun {exp log conj sqrt sin cos tan} { infix::core::funalias $fun 1 math::complexnumbers::$fun } There are however also some real-valued functions which make things trickier, as their results cannot be used as arguments to any of the operations provided by the package. A solution in this case is to define companion commands which return complex numbers (that however has imaginary part 0) and let the infix functions refer to these instead. foreach fun {real imag mod arg} { proc ::math::complexnumbers::c${fun} {z} [format { complex [%s $z] 0 } $fun] } foreach fun {real imag mod arg} { infix::core::funalias $fun 1 math::complexnumbers::c${fun} } (Here I'm putting the companions, e.g. `cimag` of `imag`, in the [math::complexnumbers] namespace too. A well-behaved complexnumbers module would rather put such auxilliary commands in its own private namespace ::infix::complexnumbers.) Some examples: % infix {z <= {2 0}} {-z*z+z} -2.0 0.0 % infix {z <= {2 1}} {conj(-z)} -2.0 1.0 % infix {z <= {2 1}} {exp(-z)*z+z} 2.26012464526 0.845360537469 % infix {z <= {2 1}} {log(-z)*z+z} 6.28738295702 -3.55117113296 % infix {z <= {3 4}} {mod(z)} 5.0 0 % infix {z <= {3 4}} {arg(z)} 0.927295218002 0 % infix {z <= {3 0}} {z**z**z} 7.62559748499e+12 0.0 '''Next step:''' Modify the parser so that complex constants can be inlined into the expressions. ---- **Discussion** [Sarnold], 2008-01-13: [math::bignum] is deprecated in Tcl 8.5, isn't it? But I see a real interest for complex numbers and [math::bigfloat] extension, for instance, to be infix'd. Nice and interesting work you've done! [Lars H]: Well, [infix] was written under 8.4, and (if memory serves) it wouldn't be too hard to get it running under 8.3 as well. But the main reson for doing math::bignum was as a proof-of-concept; demonstrating that infix didn't rely on having [expr] do the parsing or calculations. An extra module for math::complexnumber is fairly straightforward, but at the time I wrote the stuff I found [math::bignum] more appealing for a demo (maybe it was better documented, or had more features, or something). ;-) Update, 2008-01-14: See above for implementing math::complexnumbers operations. ---- [Larry Smith], 2008-07-01: I just noticed that the infix command sports a piece of ambiguous syntax. "a<-5" could be read as either "a:=5" OR as "a < -5". ''[Lars H]: Not really. The arrows belong in the symlinks argument, which is strictly a list (hence spaces are required); think of it as the arguments part of a subroutine declaration. Expressions, which might involve less-than or minus, are written in the body argument.'' [Larry Smith] Okay, I see that. I'm not sure what it buys, though. It's nice to have that kind of control, but not at the expense of a great deal of complexity or code. Why not something like: infix { in a b c out d e f inout g } ... It does not require people to know your convention using arrows. It lacks the ability to specify mappings in great detail, but that seems to be a feature in search of a problem. Even the in/out lists seem a little over-specified to me. [Lars H]: Yes, that's the kind of thing I'm aiming at myself, although for slightly different reasons. In the present version, the "infix variables" are simply entires in an array that the compiled body accesses, so it makes sense for the symlinks to simply specify what to copy into the array at start and what to copy out of it at, but when I had completed the system it became apparent that this simple model had its flaws. In particular, several things could be compiled much better if I could know for sure whether a particular symbol would be defined at a particular point in the program or not. For efficiency reasons, I want to use the ''body'' argument as index into the array that stores compiled code (its hash gets cached in the [Tcl_Obj]). This is only possible if the compiled code depends only on the ''body'' argument, so it needs to contain all '''in''', '''out''', and '''inout''' declarations, pretty much as in your example above. The tricky part for which I have not yet found a satisfactory solution is how to combine the totally flexible syntax of [infix] bodies with the fixed roles of '''in''', '''out''', and '''inout''' declarations. Some possibilities include: 1. Make '''in''', '''out''', and '''inout''' tokens of some new type, that are declared in the `base` module. This has the disadvantage that these names are then not available for symbols. 2. Designate a "delimiter", such that text before it is declarations and can follow other syntax rules than the expressions below it. This has the disadvantage that it feels like a hack. My undecidedness on this matter is the primary reason [infix] hasn't evolved further. (A close second is the many other projects I've been working on in the meantime.) [Larry Smith] And another thing: we go to a lot of trouble to support unicode and then we use "<-" instead of \u2190 (←)? As Ice-T would say, "Whut's up wid dat?" [Lars H]: Even if the language (and package) have no problem with them, the same need not be true for users' Development Environment as a whole: editors may be restricted to 8-bit character sets, and even if they aren't there needn't be a convenient way to type ←. Requiring users to type it (or \u2190 which would work fine ''as the symlinks is just a list'') is far less unfriendly, especially as it is part of the fixed syntax of the [infix] command. For the configurable [little language] found in the body, Unicode symbols are sometimes obvious choices — when coding the math::complexnumbers stuff above I actually considered defining a Weierstrass ℘ or Euler Γ function just to show off this aspect, but I skipped that since I couldn't find an ready-to-use implementation. [Larry Smith](again) This brings up an interesting point that I will just throw out for discussion: when, I ask, ''will'' it be reasonable to expect that any user could reasonably be expected to type a unicode character as ''as such'' in a program? In my opinion we are already past this point: virtually all the editors I use regularly have no problem at all with unicode. vi does, but I suspect there are few die-hard vi users that use a lot of tcl. Unicode presents a cornucopia of symbols that can be made to serve useful ends - admittedly some of those ends could be evil (there are thousands of characters to abuse). It's been in the language now for years, so when can the cobbler's children use them? [Lars H]: FWIW, my particular editor of choice ([Alpha]) unfortunately still doesn't support Unicode in documents (although it uses Tcl as scripting language, and thus can handle Unicode for internal processing, the text buffer code is written in C and years overdue for a rewrite). Also, one shouldn't underestimate the portability problems encountered when code is not pure ASCII; the default for [source] is [encoding system], and as long as you find systems where that is iso8859-1, there will be problems. ---- [AM] (16 march 2010) Here is a simple example of how you can apply this package. The program below uses it to implement the kind of array processing one finds in MATLAB or Fortran (90/95/2003): ====== # example.tcl -- # Example of the use of the infix package # package require infix # add -- # Add the elements of two lists # # Arguments: # alist First list # blist Second list # # Returns: # List of the sum of the elements of the two lists # # Note: # The arguments may also be scalars # proc add {alist blist} { set result {} if { [llength $alist] == [llength $blist] } { foreach a $alist b $blist { lappend result [expr {$a + $b}] } } elseif { [llength $alist] == 1 } { set a $alist foreach b $blist { lappend result [expr {$a + $b}] } } elseif { [llength $blist] == 1 } { set b $blist foreach a $alist { lappend result [expr {$a + $b}] } } else { lappend result [expr {$a + $b}] } return $result } # mult -- # Multiply the elements of two lists # # Arguments: # alist First list # blist Second list # # Returns: # List of the product of the elements of the two lists # # Note: # The arguments may also be scalars # proc mult {alist blist} { set result {} if { [llength $alist] == [llength $blist] } { foreach a $alist b $blist { lappend result [expr {$a * $b}] } } elseif { [llength $alist] == 1 } { set a $alist foreach b $blist { lappend result [expr {$a * $b}] } } elseif { [llength $blist] == 1 } { set b $blist foreach a $alist { lappend result [expr {$a * $b}] } } else { lappend result [expr {$a * $b}] } return $result } # main -- # Test it # ::infix::core::setup base ::infix::core::opalias + {binary 10} add ::infix::core::opalias * {binary 15} mult set a {1 2 3 4} set b {2 4 6 7} set c 2 puts [infix {a <- a b <- b} { a + b }] puts [infix {a <- a b <- b c <- c} { a + c*b }] # # Timing # proc addmult {alist blist c} { set result {} foreach a $alist b $blist { lappend result [expr {$a + $c * $b}] } return $result } puts "Direct: [time {addmult $a $b $c} 1000]" puts "Via infix: [time {infix {a <- a b <- b c <- c} { a + c*b }} 1000]" ====== The output: ====== 3 6 9 11 5 10 15 18 Direct: 3.48 microseconds per iteration Via infix: 15.999 microseconds per iteration ====== (Just to get an impression) [Lars H]: I suspect the relative overhead would be reduced for larger expressions. That's why there are modules defining things like "statement separators", assignments, and ifthen constructions — in many cases, one could write an entire procedure body in some infix little language! [N/A]: I think the add/mult operations contain a bug if the two input lists are mismatched in size. The last clause for addition is: lappend result [expr {$a + $b}] But this simply tries to add up two lists. Similarly for the multiplication one. [AM] You're quite right, but I was just experimenting with the package, so did not intend to create a foolproof program. Another bug you might say is the fact that it does not check the types - you can now pass it a list like {A B C}, causing [[expr]] to complain. [AM] (18 march 2010) A somewhat more elaborate test: ====== proc addmult {alist blist c} { set result {} foreach a $alist b $blist { lappend result [expr {$a + $c * $b}] } return $result } foreach size {10 30 100 300 1000} { set a [lrepeat $size 2.0] set b [lrepeat $size 3.0] puts "Size: $size" puts "Direct: [time {addmult $a $b $c} 1000]" puts "Via infix: [time {infix {a <- a b <- b c <- c} { a + c*b }} 1000]" } puts "Second test:" foreach size {10 30 100 300 1000} { set a [lrepeat $size 2.0] set b [lrepeat $size 3.0] puts "Size: $size" puts "Direct: [time { set r [addmult $a $b $c] set d [mult $a $b] set e [add $c $a] set f [mult $c [mult $a $b]] } 1000]" puts "Via infix: [time {infix {a <- a b <- b c <- c} { a + c*b; d = a * b; e = c + a; f = c * a * b } } 1000]" } ====== produces this output: ====== 3 6 9 11 5 10 15 18 Size: 10 Direct: 7.106 microseconds per iteration Via infix: 21.66 microseconds per iteration Size: 30 Direct: 19.151 microseconds per iteration Via infix: 39.241 microseconds per iteration Size: 100 Direct: 59.159 microseconds per iteration Via infix: 98.564 microseconds per iteration Size: 300 Direct: 181.967 microseconds per iteration Via infix: 280.807 microseconds per iteration Size: 1000 Direct: 574.934 microseconds per iteration Via infix: 873.943 microseconds per iteration Second test: Size: 10 Direct: 32.733 microseconds per iteration Via infix: 50.306 microseconds per iteration Size: 30 Direct: 78.108 microseconds per iteration Via infix: 100.438 microseconds per iteration Size: 100 Direct: 240.574 microseconds per iteration Via infix: 277.947 microseconds per iteration Size: 300 Direct: 689.702 microseconds per iteration Via infix: 780.871 microseconds per iteration Size: 1000 Direct: 2299.788 microseconds per iteration Via infix: 2562.072 microseconds per iteration ====== So, the overhead is not constant, but depends on the actual work (number of operations within the infix body and the amount of work per operation). [Lars H]: Such a difference in the first test isn't surprising; '''addmult''' has only one loop where using '''add''' and '''mult''' instead has one each. The difference in the second test is more worrying, since I think infix should compile the code to pretty much what you're comparing with — in particular there shouldn't be any dependence on the list length! The compiled code is cached in the infix::Cache array. Perhaps you could paste the contents here for comparison? ---- !!!!!! %| [Category Package] | [Category Mathematics] |% !!!!!!