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: <hardhats-members@lists.sourceforge.net>
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
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



-------------------------------------------------------
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

Reply via email to