Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!ucsd!pacbell.com!pacbell!att!cbnewsc!lgm From: lgm@cbnewsc.att.com (lawrence.g.mayka) Newsgroups: comp.lang.misc Subject: Re: Efficient Fortran Message-ID: <1990Aug4.175714.29902@cbnewsc.att.com> Date: 4 Aug 90 17:57:14 GMT References: <2428@l.cc.purdue.edu> Organization: AT&T Bell Laboratories Lines: 26 In article <2428@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: >This is true. I would be willing to give up a heck of a lot on precedence >structure, however. The precedences, except for the common arithmetic >operators, are fairly arbitrary, anyhow. Why not allow the parser to >ask the programmer for the preference order, as well as evaluation order >if it makes a difference? A lot can be helped by allowing explicitly >temporary variables to handle intermediate results. > >There are ways around the problem of precedence. Maybe we should get rid >of it completely, like APL. There are parentheses. The compliler can >ask the programmer these facts. As you say, precedence is unnecessary. Parentheses are sufficient. Application-oriented notations, such as the use of infix numerical operators with standard mathematical precedence, can be an add-on feature, operative within delimited textual regions (e.g., on the Symbolics workstation, any program text surrounded by sharp-lozenge and lozenge characters). One can define a notation to one's own liking in the same way. Lawrence G. Mayka AT&T Bell Laboratories lgm@iexist.att.com Standard disclaimer.