Re: one-liner for characater replacement

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?

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.

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!

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?

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.

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.

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.

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.

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.

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

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.

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.

(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.)

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare


.

Relevant Pages

  • Re: Matrix Multiplication
    ... to be more a setup for language wars than about Matrix Programming. ... I am using LAPACK that is written in Fortran 77 and MUMPS ... Matrix multiply is one of the supplied intrinsics. ... use of the array notations. ...
    (sci.math.num-analysis)
  • Re: Surprise
    ... haven't seen any Fortran libraries that do that. ... Libraries are a huge part of the reason why one language would be ...
    (comp.lang.fortran)
  • Re: one-liner for characater replacement
    ... convert to another language. ... upgrade to upward compatible versions of the same language. ... Under the above rules of the game, unless the Fortran world announces ...  The user base has not shrunk all that much. ...
    (comp.lang.fortran)
  • Re: interpretive vs. compiled
    ... for specific needs in FORTRAN. ... Nowadays, workstations are also available to engineers, and there's no ... Excel/VBA and much less exposure to programming. ... colleges are wondering what language to use in classes. ...
    (comp.programming)
  • Re: Help from fellow Fortran Users
    ... and Fortran in which he introduced the subject of Pascal, ... Pascal is a useful, high-level, portable language that is easy to use ... Inasmuch as his comments considered extensions for Pascal in the '70s, ... standard differs from ...
    (comp.lang.fortran)