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 >> [email protected] >> 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 >[email protected] >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 [email protected] https://lists.sourceforge.net/lists/listinfo/hardhats-members
