Re: choice of character for relational division

On Mar 31, 11:01 pm, "Bruce C. Baker" <bcbake..._at_cox.net> wrote:
> "Marshall" <marshall.spi..._at_gmail.com> wrote in message
>
> news:1175401670.752367.58550_at_y66g2000hsf.googlegroups.com...
>
> > On Mar 31, 6:04 pm, "Bruce C. Baker" <bcbake..._at_cox.net> wrote:
> >> "Marshall" <marshall.spi..._at_gmail.com> wrote in message
>
> >> Why restrict yourself to one ASCII character? Why not something
> >> unambiguous
> >> like "reldiv", e.g.,
>
> >> C := A reldiv B
>
> > I don't like alphabetical strings for infix operators.
>
> I used to feel the same way, but I've become symbol-agnostic over the years.
> :-)

Okay. But symbol-agnosticism doesn't necessarily mean that all choice of symbol sets are equally good. If you allow alphabetic infix operators, and you look at a string like this:

  a b c

You can't tell whether b is an infix operator working on a and c, or whether a is a prefix operator on b, with c applied via juxtaposition, or b in front of c etc. But if we limit infix to nonalpha symbols, and we see a string like this:

  a $ b

We know we're looking at an infix operator $ and two operands a and b, without having to know anything about the referent of a, $, or b. This makes the language's life easier and the reader's life easier, and that's a good thing.

> > 3 plus 2 times 5
>
> > Yuck.
>
> > Anyway, the number of characters or choice of characters doesn't
> > determine the ambiguity.
>
> I meant "ambiguity in isolation", so to speak; "+", for instance, can mean
> addition and/or string concatenation, depending on the language.

What *any* string of symbols means depends on the language. Perhaps you meant "familiarity." I could define left parenthesis to mean addition and upper case Q to mean subtraction, and it could very well be unambiguous, depending on the language. But it would still confuse people. And anyway, familiarity is a good argument for restricting infix operators to symbol characters and not alpha characters.

> Even
> restricting the symbol to *only* addition, it can be and usually is
> overloaded to mean int+int, float+float, int+float, and float+int.

Well, (int,int) and (float,float) anyway. But even those are two different operators. If you add 123456789 to itself as an int, you get 246,913,578, which happens to be correct. Float to float, you get 246913584. And in fact neither operator is addition. The first one is modular or ring addition; the second is an approximation of real addition.

But this kind of overloading is normal and familiar.

> > 3+2*5
>
> > Pretty clear what that means.
>
> Depends on operator precedence, if any, and whether you parse right to left
> or vice versa.

Yes, it certainly depends. It always depends. In fact, I think it would be fair to say that what language *is* is the thing that determines what symbols mean.

However there is a very strong standard here. 3, 2, and 5 are integer constants; + is addition; * is multiplication. Parsing is done left to right, * has higher precedence than +. Quick! What language am I talking about?

C/C++
Java
Python
SQL
standard US math notation

Trick question: they all work that way.

> > Single character symbols with no obvious algebraic operation
> > associated:
>
> > ! _at_ # $
>
> http://www.jsoftware.com/index.html
>
> "ASCII APL", in a very approximate way of speaking.

Believe me, J has been an influence on me. The semantics are quite interesting! Not the notation, though; that sucks.

On the one hand you have terseness and high expressive power per character. APL/J choose this path. (Perl too I guess.) On the other hand you have verbosity but a high degree of informative names and low ambiguity. Java and others go this route. I like the middle path.

> > I'll pick one of those. Okay, it's $.
>
> Your choice, of course,and FW( little )IW I'm cool with that.
>
> (I'm not trying to rain on your parade, Marshall; just pointing out that all
> the good operators have been taken! :-) )

Yeah. :-(

Marshall Received on Sun Apr 01 2007 - 10:52:00 CEST