[unix-history] / .ref-BSD-3 / usr / doc / ratfor / m5

.NH
CONCLUSIONS
.PP
Ratfor
demonstrates that with modest effort
it is possible to convert Fortran
from a bad language into quite a good one.
A preprocessor 
is clearly a useful way to extend or ameliorate
the facilities of a base language.
.PP
When designing a language,
it is important to concentrate on
the essential requirement of providing
the user with the best language possible
for a given effort.
One must avoid throwing in
``features'' _
things which the user may trivially construct within the existing
framework.
.PP
One must also avoid getting sidetracked on irrelevancies.
For instance it seems pointless for
Ratfor
to prepare a neatly formatted
listing of either its input or its output.
The user is presumably capable of the self-discipline required
to prepare neat input
that reflects his thoughts.
It is much more important that the language provide free-form input
so he
.ul
can
format it neatly.
No one should read the output anyway
except in the most dire circumstances.
.SH
Acknowledgements
.PP
C. A. R. Hoare
once said that
``One thing [the language designer] should not do
is to include untried ideas of his own.''
Ratfor
follows this precept very closely _
everything in it has been stolen from someone else.
Most of the control flow structures
are taken directly from the language C[4]
developed by Dennis Ritchie;
the comment and continuation
conventions are adapted from Altran[10].
.PP
I am grateful to Stuart Feldman,
whose patient simulation of an innocent user
during the early days of Ratfor
led to several design improvements
and the eradication of bugs.
He also translated the C parse-tables
and
.UC YACC 
parser
into Fortran for the
first
Ratfor
version of
Ratfor.
Commit	Line	Data
8340f87c BJ	1	.NH
	2	CONCLUSIONS
	3	.PP
	4	Ratfor
	5	demonstrates that with modest effort
	6	it is possible to convert Fortran
	7	from a bad language into quite a good one.
	8	A preprocessor
	9	is clearly a useful way to extend or ameliorate
	10	the facilities of a base language.
	11	.PP
	12	When designing a language,
	13	it is important to concentrate on
	14	the essential requirement of providing
	15	the user with the best language possible
	16	for a given effort.
	17	One must avoid throwing in
	18	``features'' _
	19	things which the user may trivially construct within the existing
	20	framework.
	21	.PP
	22	One must also avoid getting sidetracked on irrelevancies.
	23	For instance it seems pointless for
	24	Ratfor
	25	to prepare a neatly formatted
	26	listing of either its input or its output.
	27	The user is presumably capable of the self-discipline required
	28	to prepare neat input
	29	that reflects his thoughts.
	30	It is much more important that the language provide free-form input
	31	so he
	32	.ul
	33	can
	34	format it neatly.
	35	No one should read the output anyway
	36	except in the most dire circumstances.
	37	.SH
	38	Acknowledgements
	39	.PP
	40	C. A. R. Hoare
	41	once said that
	42	``One thing [the language designer] should not do
	43	is to include untried ideas of his own.''
	44	Ratfor
	45	follows this precept very closely _
	46	everything in it has been stolen from someone else.
	47	Most of the control flow structures
	48	are taken directly from the language C[4]
	49	developed by Dennis Ritchie;
	50	the comment and continuation
	51	conventions are adapted from Altran[10].
	52	.PP
	53	I am grateful to Stuart Feldman,
	54	whose patient simulation of an innocent user
	55	during the early days of Ratfor
	56	led to several design improvements
	57	and the eradication of bugs.
	58	He also translated the C parse-tables
	59	and
	60	.UC YACC
	61	parser
	62	into Fortran for the
	63	first
	64	Ratfor
65	version of
66	Ratfor.