Re: one-liner for characater replacement

James Giles wrote:
(snip)

Yeah, I wouldn't recommend anyone immitate PL/I's types or
it's syntax, One *supporter* of PL/I recommended that you should
never use the divide operator (/) on fixed-point types: there were
too many "gotcha's". Instead, he recommended that people should
use the DIVIDE intrinsic (which has 4 arguments). Sounds real
natural to me.

Fixed point divide isn't easy in the general case.
For add and subtract the result has the scale (digits after
the radix point) as the maximum scale of the operands.
For multiply, it is the sum of the scale of the operands.
Both those we learn in school maybe around 3rd grade.
(There is always the possibility of overflow, but the
otherwise the rules work pretty well.) There is no
rule for divide that works they way those do for add,
subtract, and multiply, so IBM made one up. Often
it works well, sometimes it doesn't. Also, the same
rule is used for variables and constants, which also
causes problems.

Scaled fixed point is currently very popular in
DSP (digital signal processing).

PL/I uses STATIC EXTERNAL structures, somewhat similar to
the way they work in C.

Too prolific in spreading things around the global namespace.
Using either COMMON or modules only adds the name of the
block or the module to the global namespace - not the name of
every object you decide to share.

If you just have one structure with all the variables, only
the structure name is external. For S/360 that was pretty
important, as it allowed the compiler to keep the address in
a register. (For Fortran and COMMON, too.) In C, one can
also collect variables in a single external structure.


(snip on COMPLEX data)

9) Operator precedence? C/C++ have 15 (or more, depends on
how you count). Fortran has 10 (or more, depends on how you count).
Pascal has 4. I think there should be 6 or 8 depending on whether
you allow user defined operators or not. User defined operators?
I could be convinced either way.

PL/I seems to have seven:

Yeah, right after I posted the last article, I realized that 7 are needed
(or nine - if user defined operators are permitted):

1) user defined prefix operators
2) exponentiation (I prefer to spell it ^)

I think you can get kicked out of the Fortran newsgroup for that.

3) multiply, divide (*,/)
4) unary + or -, infix + or -
5) concatenate (//)
6) relational operators (oh, you know the usual ones)

In addition to >= and <=, PL/I has ¬< and ¬>.

(Once when making a comment that some quantity was less than
some other quantity, I was told it should be "fewer than" and
not "less than" for integers. My answer was that couldn't be right
because Fortran didn't have a .FT. operator for integer comparisons.)

7) logical not (¬ is fine)
8) logical and (/\), logical or (\/), logical xor (><)
9) user defined infix operators.

1) **, prefix +, prefix -, not (¬)

This doesn't match normal mathematical usage (where unary
signs are lower precedence than exponentiation). Further, all
logical oparators really should be lower than the relational
operators.

It seems that for level one they associate right to left,
all others left to right. That works for **, and also gives
the right result for a leading unary sign on and exponentiation.

6) boolean AND (&)
7) boolean OR (|)

Dijkstra recommended that those operators have the same
precedence and that parenthesis should always be used to
emphasize order (that is, the language processor should
insist on it). I have come to agree.

AND/OR logic is common in digital logic design.
I agree, though, with anything too long to fit on one line it
should be parenthesized. It seems unusual to require
parenthesis, though.

The four operators at the highest level seem a little
unusual, as languages go. PL/I will convert data where
needed, such that some combinations not allowed in other
languages are allowed in PL/I.

Probably another bad idea. Too many things that are often
(maybe even usually) errors cannot be detected or reported
by the compiler.

I could argue that about conversions between INTEGER
and REAL in Fortran, but I don't know that there would be
much interest in removing them. I won't argue about it, though.

(snip on period delimited operators)

One that I don't see mentioned is I/O. That may or may not
be important for any particular problem.

And I left out whole-array operations. Are they simple enough?
As I mentioned before, I probably left out a whole lot of important
stuff.

Some are simple, some are not. Less simple ones often require
temporary arrays, which can be slow and cause memory problems.

PL/I also allows structure expressions, which again may be simple
or not so simple.


-- glen

.

Relevant Pages

  • Re: modifying constants
    ... Fortran doesn't require a temporary ... PL/I does. ... My understanding is that this is exactly the same as ...
    (comp.lang.fortran)
  • Re: log10 - g95 bug?
    ... had full generic COSD etc, ... As you wrote, Fortran won't od log, and PL/I will. ...
    (comp.lang.fortran)
  • Re: Does PL/I support dynamic function outputs?
    ... I am certain that if a paying IBM customer asked him the question ... ... "Can programming language A "exactly duplicate" the code in Programming Language ... I am certain that when you purchase a currently supported version of PL/I (any ... > On several occasions you have replied saying you were Fortran rusty, ...
    (comp.lang.pl1)
  • RE: SSP in PL/I or Fortran
    ... >>Subroutine Package that used to exist in both PL/I and Fortran. ... > I have the manual for the FORTRAN SSP and it might be 2 volumes. ... Not to be a party pooper, but please remember that most of these manuals ...
    (bit.listserv.ibm-main)
  • Re: despair
    ... COBOL or PL/I programmers. ... PL/I and C programs for equivalent functionality, you will find that the C version ... As well as Pascal for most of them, Fortran for most of them even COBOL ...
    (comp.os.vms)