Re: one-liner for characater replacement

James Giles wrote:
analyst41@xxxxxxxxxxx wrote:

OK. If someone wanted a Fortran-like prototyping/proof-of-concept
language for mathematically oriented computing (not necessarily
backwards compatible with f77 code) that incorporates as much as
possible of what has been learnt about computing after f77 - what
would your specs of the language for him look like?

Do you want an interpreted language? There are Mathematica,
Matlab, and R (or S) as mathematical prototyping (interpreted)
languages. Otherwise, PL/I was designed as a replacement
for Fortran. As I understand it, IBM originally was not planning
Fortran compilers for OS/360, expecting to convert everyone over
to PL/I.

C was designed as a systems programming language, mostly
not emphasizing mathematical uses. (Note that the
mathematical functions are in a separate library often
not included by default.) C++ and Java similarly don't
emphasize mathematical use. All three can be used for
mathematical applications, though.

Well, that's still an awfully big project (just defining *any* language
is a big project). I've seen languages where the whole description
of both the syntax and semantics could fit in two or three pages.
The person (or people) that wrote it probably took a month or
more to decide what those pages should say.

Not trying to promote PL/I, but only make constructive
comparisons, it seems to me that PL/I is the only language
since the beginning of Fortran with replacement of Fortran
as part of its design. More specifically, a language
designed to be compiled and run reasonably fast.

So, where do you want to start? My preference is 1) the language
(as constrained above) is *not* Fortran. It's not a subset of Fortran.
Not of any flavor of Fortran. To be sure it would have a very
Fortran-like syntax (syntax is what most people think of as being
the basic characteristic of a language). And, things that are common
to *most* languages (including Fortran) woud be kept in the new
language. The reason that there are things common to most
languages is that there are few sensible alternative ways to do
those things. Everything else is on the cutting board!

PL/I keeps no reserved words, using a free form semicolon
terminated statement syntax.

2) Lexical structure next? Well, case should have no significance
except in character literals. Identifiers should have no a-priori limit
in length. The bracketing delimiters {}, [], and () should all have
identical meanings. And so on. Settling all these issues would take
an afternoon (at least). Like: should keywords be reserved?

PL/I uses () for bracketing delimiters, except for statement
groups which use PROC/END, BEGIN/END, or DO/END. It originally
only had one case, and has no reserved words (except in the
48 character source character set option).

3) Intrinsic data types? Floats (at least all the types supported by
the host hardware), integer (one type, arbitrary precision), rationals
(arbitrary precision), character (at least ASCII, Latin-1, and some
UNICODE - I'd personally prefer UTF-16), and Logical (one type).
No KINDs, all these are distinct types. (No parameterized types
at all: you did posit it had to be a simple language.) Other intrinsics
might be desirable (bits say). Depends on details elsewhere.

Data types may be the biggest complaint about PL/I. Floating
point and fixed point data precision may be specified in bits
or digits, as needed. An appropriate type will be supplied.
For fixed point, a scaling factor (number of digits after
the radix point.) (There is some suggestion that it also
specifies the base used in arithmetic. This isn't so
obvious as it seems.)

4) Modules or COMMON? Everything is on the cutting board.
A simple language should have only one of these. Modules are
the simpler of the two: no storage association. Also, a module
gives an obvious place for initializations and can also hold named
constants. In any case, even in a scripting language or that kind
of thing, there are likely to be things you want to save end reuse
over several projects and modules provide good packaging for
that kind of thing.

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

5) External procedures, module procedures, or internal procedures?
A simple language should have only one of these features. Modules
are a cleaner solution than externals and provide a way to share
some things without making them public. As for compilation cascades:
well such a language is involved with small programs anyway (and
may even be implemented interpretively), so it's not really an issue.
And again, you will probably want to save an reuse *some* codes:
modules provide good packaging.

Internal procedures complicate separate compilation, so
I don't believe they should be the only option.

6) Derived data types, yes or no? I think yes. If you need the ability,
there's no useful alternative. And if you don't need it, you won't
notice it's there. It's not like it's something you can accidentally
trip over. If you have this, then COMPLEX (which I didn't mention
as an intrinsic) should be a predefined one of these. This obviously
involves the introduction of overloaded operators and intrinsic
functions.

I believe that PL/I structures were borrowed from COBOL.
(Features came from Fortran, ALGOL, and COBOL.) Having
COMPLEX as a predefined structure data type is an interesting
idea. PL/I uses it as an attribute to any numeric data type.
That is, fixed point or floating point data is either REAL
or COMPLEX.

7) SAVE or not? All module variables should have that property
automatically, no other variable should be permitted to have it.
Arrays? Yes (arbitrary dimension, local arrays can be "automatic").
Strings? Yes (any base type, and always dynamic length). Pointers?
No. Allocatable? Probably no. INTENT? Yes (IN or OUT - not
specifying should mean the same thing as INOUT, so you don't
actually need to be able to say INOUT). OPTIONAL? Maybe,
but with different rules than Fortran. Asynchronous, protected,
volatile, etc.? No. This is supposed to be a simple language.

PL/I has four storage attributes, STATIC, AUTOMATIC, BASED,
and CONTROLLED. Also, scope attributes of INTERNAL and EXTERNAL.
Some combinations are not allowed, such as AUTOMATIC EXTERNAL.
Not having to support legacy code, arrays are only passed as
descriptors. STATIC array dimensions must be compile time
constants, otherwise dynamic. Expressions, including a
variable in parenthesis or an expression with a different
type than the declared dummy as converted and a temporary
is passed. The called routine is allowed to modify the
temporary.

8) Inheritance? Certainly not. There's no evidence it improves
productivity. (In fact, there's evidence to the contrary.) And it's
a *VERY* big feature to haveto support in a simple language.
Generic procedures? Maybe. It has to be simple. It actually can
be. Generic data type (variant derived types)? Maybe. Of course
you can't have those unless you have derived types at all (6).

No comment on this one.

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:

http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/ibmol004/3.1.3.5.1

1) **, prefix +, prefix -, not (¬)
2) *, /
3) infix +, infix -
4) string concatenation (||)
5) relational (comparison) operators
6) boolean AND (&)
7) boolean OR (|)

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.

10) ... and so on. I can think of about a dozen other issues off
the top of my head. If I dug out the Fortran manual and read
through it page by page I could probably think of several dozen.
Just hashing out what all the basic issues are would be a task
for a week or more. *Deciding* on all of them is months.

I agree.

(The above is not in any particular order of priority. It's just the
order the issues came to mind, and is not recommended as any
outline for further discussion. Indeed, since it's just off the cuff,
there may be issues not on the list that, on reflection, I would
regard as more important than many of the things I mentioned.)

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

Again, this is not meant to promote PL/I. Only to show that
some issues have been considered before. The reasons behind
the decisions may have changed over the years, though.

I would be interested in comparisons to other languages
designed for mathematical programming.

-- glen

.

Relevant Pages

  • Re: PL/I and OOP
    ... But considering language purely, although there are some aspects of PL/I ... unnecessarily clumsy overloading (called "generics" in PL/I jargon), ... Fortran not until 1991. ...
    (comp.lang.pl1)
  • Re: PL/I, COBOL, Advantages, Equivalence, et al
    ... than any general-purpose language could hope to do. ... hope to see solutions in PL/I that take advantage of mixing, ... code, or Fortran code, or existing Jovial code, in a PL/I program. ... Whereas the Fortran object code - when executed separately ...
    (comp.lang.pl1)
  • Re: PL/I, COBOL, Advantages, Equivalence, et al
    ... the designers of Fortran are ... That's been possible in PL/I since 1966. ... appropriate model for language design. ... design for modularity, for object-oriented programming, ...
    (comp.lang.pl1)
  • Who is R.Vowels
    ... There was no reason Robin had to put her 1-line ... > solution into a subroutine (like you HAD to for Fortran). ... aware ANYONE has ever posted such language before, ... If OOP was integrated into PL/I ...
    (comp.lang.pl1)
  • Re: Frank is a liar!
    ... There are MORE Fortran compilers for WINDOWS on the market today than any ... other language. ... Go tell it to the fortran newsgroup. ... PL/I is more modern than Fortran and many other recent languages. ...
    (comp.lang.pl1)