From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,9cccf6ef6149fdaa X-Google-Attributes: gid103376,public From: Charles Hixson Subject: Re: Operators -> unit analysis Date: 2000/01/06 Message-ID: <3874C553.EB32B002@earthlink.net>#1/1 X-Deja-AN: 569150281 Content-Transfer-Encoding: 7bit References: <38620350.48F8FC08@gecm.com> <83u8l0$5i5$1@nnrp1.deja.com> <84rd2f$snm$1@nntp3.atl.mindspring.net> <84thof$9r3$1@nntp4.atl.mindspring.net> <387383D0.4EA02E95@earthlink.net> <850jiq$mad$1@nnrp1.deja.com> X-Accept-Language: en X-Posted-Path-Was: not-for-mail Content-Type: text/plain; charset=us-ascii X-ELN-Date: 6 Jan 2000 16:39:55 GMT X-ELN-Insert-Date: Thu Jan 6 08:45:02 2000 Organization: EarthLink Network, Inc. Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 2000-01-06T00:00:00+00:00 List-Id: > How would you decide where to place them in the precidence hierarchy? > > (see bottom) > Choices: 1) Put them at the bottom of the precedence hierarchy, with equal precedence. Use parenthesis to do groupings. 2) (too complex) Allow a more verbose declaration form that specifies the binding level. (Arrange all standard operators in ranked order, and allow the newly declared operator to be inserted into the list.) 3) (Complex, but NICE) Arrange for two kinds of operator declaration. One that is at the bottom of the hierarchy (as 1). The other is near the top (don't break apart parenthesized groups!) but left-binding and taking only one parameter. Call this one Unit or some such. This would be for declaring things like grams, dynes, years, etc. So we could have: UnitFunction grams (scalar : <>) returns Gram is Custom operators in complex statements are problematic anyway, but I would like to distinguish between dot product and cross product (and analogous cases), which are conventionally treated as operators rather than as functions. I have never gotten used to the notation that goes: z = x.dot (y); even though it *IS* semantically equivalent to, e.g.: z := x .*. y (It would be even nicer if the large centered dot was a legitimate character [which brings us back to the unicode request earlier in the thread {it seems to have rolled off my newsServer, so I can't say who made the request}], but it *is* a bit hard to type). I frequently find that "common usage" improved the understand ability of code. The problem is that it is hard to support in a compiler (or requires complex implementations). To take an example from a different thread: speed = x miles / y hours; now if there were "a units operator" (i.e., high priority, left binding, takes one operator) one could define miles as an operator that multiplied a scalar by 1 mile and returned a value of type Miles. But units would need to aggregate, so that we could specify area, volume, G, etc. So the exact implementation would need to be carefully thought out. The customary syntax, however, has been with us since grade school, and changing it immediately makes things less intelligible. We have years of experience that tell us that units are high priority, left binding, and take one operator. Except for traditional exceptions like currency which are high priority, right binding, and take one operator (although when spoken the currency units are left binding, just like a normal unit). Thus $5 is 5 dollars, $5.25 is 5 and 1/4 dollars (or 5 dollars and 25 cents). A problem is that the names of units occupy the same space as normal variable names, but conceptually they are a different *kind* of thing. Thus 5 grams IS 5 * (1 gram) IS Gram'(5), but the versions are each more difficult to read than the one prior to it. 5'grams, OTOH, is transparent. Unfortunately, it appears to me that making either: 5 grams or: 5'grams legal would require changes in the specification of any language that I know (except for Smalltalk and Forth, which have other problems). Ted Dennison wrote: > In article <387383D0.4EA02E95@earthlink.net>, > Charles Hixson wrote: > > Terry Sikes wrote: > > > > > ... > > > One thing I'd like to see in both languages is the ability to use a > > > set of non-reserved Unicode symbols for operator overloading, to > > > disambiguate with the normal operator symbols. > > > I don't insist on unicode, but I would also like more operators that > > could be overloaded. > > How would you decide where to place them in the precidence hierarchy? > Having recently built a couple of packages around overloaded operators, > I found that getting the correct precidence for the various new > operators I defined is at least as important as the appropriateness of > the chosen operator symbol to the task. You don't want to end up in a > situation where you have to use parenthesis in counter-intuitive places > to work around the precidence rules. > > -- > T.E.D. > > Sent via Deja.com http://www.deja.com/ > Before you buy.