At 3:14 PM 6/24/96, Ka-Ping Yee wrote: [excerpted] >... >Here is the update: an operational renderer to text >is now available on the site > > http://www.lfw.org/math/ >... > - There isn't a way of directly representing operations > performed upon operators. I believe the way to do this > would be to allow, in the internal representation, > lists as well as atoms to take the first position in > a list. I think it is quite feasible; a possible way > to add this to the syntax is to write .(sum;n) to > qualify the addition operator with the letter n, for > example -- this is natural because the period is used > currently to introduce operators. > > Is operator-operator binding something that will ever > need to be carried to an indefinitely deep level? > As in operating on operators the operate on operators > that ... etc. I think you're talking about what we've been calling "operator embellishment". Since the only "operators on operators" that our group has discussed so far are "layout operators" (what we may have called "2D operators" or "embellishers"), as _ in the expression a +_2 b which might render as a + b 2 , which are not visible themselves but which affect the relative positions/sizes of their operands (e.g. + and 2), it would never be sensible for one of these "embellishers" to itself be embellished. That is, only visible operators need to be embellished, and only invisible operators can perform embellishment. However, it might be necessary for one of the arguments to an embellisher (the operator or the e.g. subscript) to itself be, or contain, an embellished operator. This may be rarely desired, but it is allowed in our proposal, and could be expressed, for example, by a {+_2}_3 b for a + b 2 3 or by a +_{b +_2 c} d for a + d b + c 2 [which are admittedly extremely contrived examples].Received on Tuesday, 9 July 1996 13:11:00 UTC
This archive was generated by hypermail 2.4.0 : Saturday, 15 April 2023 17:19:57 UTC