Re: Operators -> unit analysis

[Charles Hixson <charleshixsn@earthlink.net>]

> 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 : <<Numeric>>) 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 <charleshixsn@earthlink.net> 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.