What is the origin of NAMELIST?

1

Hello all - first post here, but I have lurked around for a very long time. I am always impressed with the wealth of knowledge and the Fortran comradery displayed in this group; and I am just like you all a very strong proponent and supporter of the continued efforts to modernize the language (my username is just a cheeky nod to the past, haha).

My question is the following: after an internal debate at work regarding the use of NAMELIST in the 60s (way before it got standardized), I wondered if anyone knows the origin of the NAMELIST statement: what compiler was it first introduced for? How did the concept got disseminated across the many, many compilers that existed in the 60s and 70s? And eventually, who made the proposal to include NAMELIST in the Fortran 90 standard? I suspect the inclusion of that feature in the standard may have triggered epic debates due to the various implementations that existed back then.

If you have references on the topic (papers, books, manuals) that you can recommend this would be great as well!

3 Likes
2

For a list of compilers up to around 1970, you should try to find a copy of Fredrick Stuart’s book “Fortran Programming”, John Wiley and Sons, 1970. Stuart’s book has several tables listing the various capabilities and functions supported by around 80 compilers available on about 160 machines at the time. The table listing NAMELIST supports shows only about 14 of the 80 compilers at the time supported NAMELIST.

5 Likes
3

The, quite famous, IBM (H) Compiler for System/360 had it in 1966, according to this

4 Likes
4

Here is a list of vendors and machines that supported NAMELIST in their compilers per Stuarts book. There are an additional 7 compilers listed in the appendix that I missed first time around bringing the total up to around 16.

Vendor Systems

Burroughs Corp B6500, B7500, B8500
Control Data (CDC) 6400, 6500, 6600, 7600 (EXTENDED FORTRAN compiler)
Digital Equipment(DEC) PDP-10
English Electric Computers EE 4-50
General Electric GE 625, 635, 645
IBM 360-44PS (G, H, levels)
IBM 360 Time-Sharing(360-67)
IBM 7090, 7094I, 7094II
Raytheon 520
RCA SPECTRA 70/15, 70/25, 70/35, 70/45, 70/46, 70/55
Scientific Data Systems SDS 910, 920, 925, 930, 940, 9300
Scientific Data Systems SIGMA 5, SIGMA 7
Sperry/UNIVAC UNIVAC 1108
Electro-Mechanical Research EMR ADVANCE 6130
Sperry/UNIVAC UNIVAC 9400

As to the origin of NAMELIST, my money is on either IBM or CDC. What is interesting about Stuart’s tables is the sheer number of hardware vendors who had Fortran (oops FORTRAN) compilers at that time.

2 Likes
5

Thank you @themos for telling us about an IBM compiler that had NAMELIST in 1966. It did not appear in either the f66 or f77 standards.

6

@goto, awesome, welcome to the forum!

1 Like
7

Thanks to all for the very constructive answers. @rwmsu I ordered the book you recommended, I suspect it’s a mine of information and anecdotes from way-back-then.

So far we can go back as far as 1966 for the introduction of NAMELIST thanks to @themos reply. I am wondering if it’s even older than this; taking a look at Fortran (FORTRAN, haha) manuals from that time is probably the way to make that determination.

8

I think I just found the answer in this paper.. It looks like NAMELIST was introduced by IBM in 1964. The author writes: “The NAMELIST feature for data input and output was recently introduced into FORTRAN IV” and provides a reference to the corresponding publication by IBM.

1 Like
9

I wonder if this keyword i/o was unique to FORTRAN at that time, or did other languages of that era such as algol and pl/1 also have it?

10

Don’t really know a lot about COBOL, but that is the first language that I would think had something like keyword I/O due to what it was designed to do.

Edit

Having written my own keyword based I/O routines, I have a deep respect for the programming skills of the people who implemented NAMELIST way back in the 60s. Its hard enough using Modern Fortran’s string handling capabilities. I can’t imagine what it was like trying to implement it in assembler.

11

Algol 60 and Pascal did not have NAMELIST. I don’t think Algol 68 had it either, but my Algol 68 book is not currently accessible.

12

PL/I had something similar to namelist in the GET DATA and PUT DATA constructs.

Besides providing an easy way to get labelled debug output, we would sometimes use GET DATA at the beginning of a program to set run-time control inputs in a kind of self-documenting way.

I think you could even use it without listing the variables, so that GET DATA; would allow you to set any variable accessible in the scope of the statement.

Fun times.

13

Things I like about namelist:

  • I specify typed variables (integers, reals, arrays, …) and with minimal syntax the compiler ensures the input file gets loaded correctly into the variables

What I don’t like:

  • the namelist syntax can be limiting and it is non-standard (no other modern tool uses it)

Modern tools use TOML, JSON, sometimes also CSV, XML. There are libraries to read all those, for example for TOML there is GitHub - toml-f/toml-f: TOML parser implementation for data serialization and deserialization in Fortran, however you have to use the toml-f API to extract all the information, it is about 10x more lines and one has to study the API.

What I would like:

  • I would like to be able to use toml-f, but with syntax like a namelist.
  • (The same mechanism could then be used to load any format, like JSON, CSV, XML, …)

One way is to do it like Rust does: toml - Rust, where you just have to create the struct and decorate it:

#[derive(Deserialize)]
struct Config {
   ip: String,
   port: Option<u16>,
   keys: Keys,
}

Then call it like this:

let config: Config = toml::from_str(r#"
   ip = '127.0.0.1'

   [keys]
   github = 'xxxxxxxxxxxxxxxxx'
   travis = 'yyyyyyyyyyyyyyyyy'
"#).unwrap();

and it will just work.

Rust has mechanisms to do this, and I am not proposing that Fortran becomes Rust. But there might be a way to extend Fortran in some minimal fashion that would allow this kind of simple and compiler-checked syntax. For example, maybe it is possible for toml-f to implement a “namelist interface”, and the compiler would allow to use a nice namelist syntax, but implemented via the toml-f library (or any other user-specified library, not hardwired in the compiler).

4 Likes
14

Some kind of variable/type introspection is something i was thinking about for this:

1 Like
15

I opened up an issue for this introspection proposal at Introspection in Fortran for generic file I/O libraries (TOML, JSON, NPZ, etc.) · Issue #331 · j3-fortran/fortran_proposals · GitHub.

1 Like
16

NAMELIST has been used/misused for purposes uses such as passing data between programs, configuration files, dump/restore, debugging and introspection, I have found a need for each of those at one point or another. I find embeddable languages such as Lua can be used for all those purposes with with less effort than any other single solution. There are a few lisp-like interpreters written in Fortran, but I find the more “Fortranik” style of the old matlab88 interface fits my needs the best. I started modernizing a version and find it very useable for my needs but honestly it needs a complete rewrite at some point. There used to be several Fortran 77 interpreters written in Fortran 77-ish code that took liberties with Fortran syntax primarily to make interactive usage easier. My biggest disappointment with TOML/JSON/YAML is the lack of conditionals. Has anyone been thinking along the lines of a more language-like interface or providing a standard interface to an interpreted language like Lua or some of the mini- C-interpreters (since Fortran already defines a C interface definition)?

17

The most desirable extension to me currently for NAMELIST is to be able to declare a namelist and have it populated from command-line arguments using some of the currently most popular CLI styles. Both (like some of the formats above) can basically be reduced to name–value pairs with specified types so the information aligns very well. I can get close but not quite to the point of it being intuitive.
See one approach at GitHub - urbanjost/M_CLI: Unix-like command line parsing -- prototype style converts command line to a NAMELIST group that explores the idea.