Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!bu-cs!purdue!decwrl!sun!pitstop!sundc!seismo!uunet!mcvax!ukc!stl!stc!praxis!hilbert!mct
From: mct@praxis.co.uk (Martyn Thomas)
Newsgroups: comp.lang.misc
Subject: Re: How to supplant FORTRAN (Was: Algol-68 down for the count)
Message-ID: <3517@newton.praxis.co.uk>
Date: 15 Dec 88 11:05:01 GMT
References: <406@ubbpc.UUCP> <3688@hubcap.UUCP> <416@ubbpc.UUCP> <37846@XAIT.Xerox.COM>
Sender: news@praxis.co.uk
Reply-To: mct@praxis.co.uk (Martyn Thomas)
Organization: Praxis Systems plc, Bath, UK
Lines: 40

Is there a formal, semantic definition of FORTRAN yet?

If so, please will someone post a reference?

If not, FORTRAN programs would seem not to mean anything, so people who
write programs in it must either:
	- 	not realise that their programs are meaningless, or
	-	not mind, or
	-	believe that they know their own compiler so well that they
		can safely predict the behaviour of their programs.

In the last case, they are either right or wrong (probably wrong). If they
are right, then they are effectively using a local language, of limited
portability, which happens to bear a passing resemblence to other local
languages (also called FORTRAN).

Isn't this the essence of the problem? Of course, it applies to most
languages.

Of course, if there is a semantic definition, and compilers are validated
against it, and programmers understand it, then the analysis above is out of
date.

Then there's the problem of programmers making mistakes (which they can
easily do, even in a well-defined language, and not all mistakes can be
detected by the compiler or run-time system).  Strong typing helps a lot
here, by encouraging the programmer to provide (logically redundant)
information (in type definitions) which can be used for checking consistency
of use of data.  Good compilers (and hardware architectures) trap common
dynamic errors (such as index out-of-bounds).

The worst combination would be a language with no formal semantics, weak
data-structuring and weak typing, limited bound-checking (and other
exception-detection), running on a hardware architecture with no memory
protection, or overflow/underflow detection.

Does this remind you of a FORTRAN (or C or ...) implementation somewhere
near you?
Martyn Thomas, Praxis plc, 20 Manvers Street, Bath BA1 1PX UK.
Tel:	+44-225-444700.   Email:   ...!uunet!mcvax!ukc!praxis!mct