It's true that evaluating an infix expression using normal operator precedence rules does require at least a stack. My point is that I think the MUMPS community does not take very seriously how deeply engrained operator precedence rules are in the way we've learned to think about mathematics. And it's not just arithmetic: consider
P or Q and R My guess is that it is the rare person indeed who would intuitively parse this as (P or Q ) and R Regardless of the historical basis of the operator precedence rules employed in MUMPS, the resulting cognitive dissonance is immense, and the strict left to right evaluation rules can only have the same effect on the programmer (user) as a "garden path" sentence like The horse raced past the barn fell. After all these years, that sentence STILL makes stop short and do a kind of a mental reset. Evaluating 2+3*4 as 20 is no different. --- Thomas Salander <[EMAIL PROTECTED]> wrote: > At 8/16/2005 07:05 PM, Greg Woodhouse wrote: > >It's as if someone decided > >that they would violate a well established convention just for > <insert > >your favorite expletive> of it. > > No. It was done that way out of pragmatism. The basis for the > language was > developed in the 1960's with very limited hardware resources. Strict > left-to-right processing was the most efficient use of resources. > > Since then two generations have been raised using the same > left-to-right > notation on the most ubiquitous computer, the common calculator. But > even > if you are right about a "well established convention", you are > talking > about the world you live in today, 2005. This design decision was > made > decades ago in a different environment, a different world. It wasn't > arbitrary, it wasn't capricious. It was pragmatic. > > >But how could you evolve the order of precedence into something > different > >than the current standard without breaking old code? > > > >I cannot recall the names of all of the languages I have used. They > > >included extinct ones like Focal and Coursewriter II. I do not > recall any > >languages that used the operators "+", "-", and "*" with a different > order > >of precedence than what is described below, however there were host > of > >other operators including "^", "**", "#", "\", and some others. The > > >others were not consistent from language to language as I recall. > > > >I will also say that I know what Mumps will do with the following, > but do > >not recall what Fortran, Pascal, PL/I, or Basic would do with > > > >2*3/4*5/6 > > > >Jim Gray > > > >----- Original Message ----- From: "Greg Woodhouse" > ><[EMAIL PROTECTED]> > >To: <[email protected]> > >Sent: Wednesday, August 17, 2005 11:25 AM > >Subject: RE: [Hardhats-members] MUMPS features > > > > > >>Which language are you referring to? Ada? PL/1? 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!) > >> > >>I'll just make one editorial comment: There may indeed be languages > >>other than MUMPS that do not follow normal operator precedence > rules, > >>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. > >> > >>--- 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 > > > > > > > >------------------------------------------------------- > >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 > > > > > > > ------------------------------------------------------- > 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
