Maybe it's a case of reductio ad absurdum but if I have a long arithmetic list like:
5+9+33+87-92+28+77*4-15-61+88+342 why in the world would I go into the middle to multiply 4*77 before starting on the rest of the math? That makes no sense at all. Multiplication trumps addition? Are we playing bridge here? And yes, having studied other languages I'm aware of their weird operator precedence and, much like Jim, can't remember which does what. Left to right, what could be simpler? Just like reading. Can you imagine reading a line of code where For and Do took precedence over If and Write? I vote left-to-right (as if this were a decision that had to be made.) Thom H. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jim Self Sent: Thursday, August 18, 2005 4:06 PM To: hardhats-members@lists.sourceforge.net Subject: RE: [Hardhats-members] MUMPS features Gregory wrote: >Which language are you referring to? Ada? PL/1? I studied a large number of programming languages back then that I haven't used since, including those two, and I remember very little about them. APL is one that I remembered as having strict right-to-left precedence. >Honestly, I don't know >either of those languages, so I couldn't say whether they use a single >level of precedence. Languages I have used include Basic, Visual Basic, >C, C++, Pascal, Object Pascal, MUMPS, Java, Perl, Python, Fortan 77, >Franz LISP and Scheme (I don't claim to remember them all!) Visual Basic, C++, Java, Perl, Python did not exist at that time. C was barely on the map and Fortran had no operators (that I recall) for anything but basic algebra. I was just getting interested in C when I started with MUMPS and it wasn't yet taught or covered even in advanced computer science classes at UCD until several years later. It was available on the unix computers serving the computing labs, but the only people who knew anything about it were ones who picked it up on their own. >I'll just make one editorial comment: There may indeed be languages >other than MUMPS that do not follow normal operator precedence rules, There was no such thing as a "normal" operator precedence when I was in school, unless perhaps you restricted consideration to operators defined in FORTRAN. >but who is using them today? I would think that MUMPS programmers would >be more interested in seeing the language evolve into something that >more people would be willing to adopt. I am certainly interested in seeing MUMPS based systems evolve, but I think that changing operator precedence would simply break existing applications. I think that the evolution of MUMPS at this point will mostly be in making MUMPS data and executables accessible to other languages. Steve Zeck's Db-GTM Perl module is a start in that direction. Another possibility is OMEGA or RUNE, a long time dream of many veterans of the MDC. >--- Jim Self <[EMAIL PROTECTED]> wrote: > >> Gregory wrote: >> >In every single language using infix notation (except MUMPS) that >> I'm >> >familiar with 2 + 3 * 4 = 16, and it is a longstanding convention in >> >mathematics that 2 + 3 * 4 is 2 + (3 * 4) not (2 + 3) * 4. >> > >> >It's not that I can't live with strict left to right evaluation, >> it's >> >just that it's annoying...really annoying. It's as if someone >> decided >> >that they would violate a well established convention just for >> <insert >> >your favorite expletive> of it. >> >> The convention for precedence among operators was NOT well >> established among different >> programming languages until long after I started using MUMPS which >> again was long after it >> was decided for MUMPS. >> >> When I was a graduate student studying different programming >> languages, some used strict >> right-to-left precedence and among languages that offered a per >> operator precedence scheme >> and a relatively large set of operators, there were many variations >> on precedence that I >> found impossible to follow without a reference manual or excessive >> use of parentheses. >> >> In contrast, MUMPS' left-to-right precedence offered refreshing >> simplicity. This is a dead >> issue, or should be since it was decided for MUMPS decades ago. >> >> --------------------------------------- >> Jim Self >> Systems Architect, Lead Developer >> VMTH Computer Services, UC Davis >> (http://www.vmth.ucdavis.edu/us/jaself) >> >> >> ------------------------------------------------------- >> SF.Net email is Sponsored by the Better Software Conference & EXPO >> September 19-22, 2005 * San Francisco, CA * Development Lifecycle >> Practices >> Agile & Plan-Driven Development * Managing Projects & Teams * Testing >> & QA >> Security * Process Improvement & Measurement * >> http://www.sqe.com/bsce5sf >> _______________________________________________ >> Hardhats-members mailing list >> Hardhats-members@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/hardhats-members >> > > > >=== >Gregory Woodhouse <[EMAIL PROTECTED]> > >"Design quality doesn't ensure success, but design failure can ensure failure." > >--Kent Beck > > > > > > > > >------------------------------------------------------- >SF.Net email is Sponsored by the Better Software Conference & EXPO >September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices >Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA >Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf >_______________________________________________ >Hardhats-members mailing list >Hardhats-members@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/hardhats-members > --------------------------------------- Jim Self Systems Architect, Lead Developer VMTH Computer Services, UC Davis (http://www.vmth.ucdavis.edu/us/jaself) ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
