# Add a specifier to namelist read that requires all members to be read **URL:** \ **Category:** Language enhancement\ **Created:** [March 8, 2024, 11:52pm UTC](https://fortran-lang.discourse.group/t/add-a-specifier-to-namelist-read-that-requires-all-members-to-be-read/7578 "2024-03-08T23:52:02Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Beliavsky](https://avatars.discourse-cdn.com/v4/letter/b/ba8739/32.png) [@Beliavsky](https://fortran-lang.discourse.group/u/Beliavsky)\ **Post date:** [March 8, 2024, 11:52pm UTC](https://fortran-lang.discourse.group/t/add-a-specifier-to-namelist-read-that-requires-all-members-to-be-read/7578/1 "2024-03-08T23:52:02Z")
A namelist READ will read the members present in the namelist file or string and leave the other members unchanged. If those members were not set before, they may be inadvertently used before being set. For example, the following program ```auto implicit none real :: x, y, z character (len=100) :: nml_string namelist /xyz/ x, y, z nml_string = "&xyz x=1.2, y=2.5/" ! z is missing read (nml_string, nml=xyz) print*,x,y,z end ``` can give output of `1.200000 2.500000 5.7615271E+21` with ifort. I suggest that an optional `read_all` specifier be added to the namelist READ so that the absence of a namelist member in a namelist file or string causes a run-time error. For example if the program above had the line `read (nml_string, nml=xyz, read_all=.true.)` it would fail with a message such as `could not read namelist member z`. ---
**Author:** ![sblionel](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/sblionel/32/853_2.png) [@sblionel](https://fortran-lang.discourse.group/u/sblionel)\ **Post date:** [March 9, 2024, 1:28am UTC](https://fortran-lang.discourse.group/t/add-a-specifier-to-namelist-read-that-requires-all-members-to-be-read/7578/2 "2024-03-09T01:28:58Z")
This is quite a departure from the design of Namelist and list-directed input. In such cases, you could preset the variables to a sentinel value and then check for it. ---
**Author:** ![Beliavsky](https://avatars.discourse-cdn.com/v4/letter/b/ba8739/32.png) [@Beliavsky](https://fortran-lang.discourse.group/u/Beliavsky)\ **Post date:** [March 9, 2024, 1:39am UTC](https://fortran-lang.discourse.group/t/add-a-specifier-to-namelist-read-that-requires-all-members-to-be-read/7578/3 "2024-03-09T01:39:15Z")
With list-directed input I get an error message with `read (string, *) x, y, z` if `z` cannot be read, rather than have the program continue with `z` unchanged. I think the read\_all specifier would make namelist input act more like list-directed input. ---
**Author:** ![sblionel](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/sblionel/32/853_2.png) [@sblionel](https://fortran-lang.discourse.group/u/sblionel)\ **Post date:** [March 9, 2024, 1:48am UTC](https://fortran-lang.discourse.group/t/add-a-specifier-to-namelist-read-that-requires-all-members-to-be-read/7578/4 "2024-03-09T01:48:23Z")
Not necessarily. ```auto D:\Projects>type t.f90 real :: x,y,z character(80) :: string = "3,4/" read (string, *) x, y, z print *, x,y,z end D:\Projects>ifx t.f90 Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2024.0.2 Build 20231213 Copyright (C) 1985-2023 Intel Corporation. All rights reserved. Microsoft (R) Incremental Linker Version 14.39.33519.0 Copyright (C) Microsoft Corporation. All rights reserved. -out:t.exe -subsystem:console t.obj D:\Projects>t.exe 3.000000 4.000000 0.0000000E+00 ``` ---
**Author:** ![urbanjost](https://avatars.discourse-cdn.com/v4/letter/u/0ea827/32.png) [@urbanjost](https://fortran-lang.discourse.group/u/urbanjost)\ **Post date:** [March 10, 2024, 12:47am UTC](https://fortran-lang.discourse.group/t/add-a-specifier-to-namelist-read-that-requires-all-members-to-be-read/7578/5 "2024-03-10T00:47:50Z")
Different strokes for different folks, I suppose. I have wanted NAMELIST to be able to read from a file that defines values not in the namelist group for a long time; which would make NAMELIST far more flexible for use in reading configuration files. That is, if the namelist file set x, y, and z I would like to read the file with a namelist group that only contained a subset of those values. Otherwise, if I add a value to a NAMELIST file I have to make sure to change any program that reads the file to handle the new variable; or break the file up so it has multiple NAMELIST groups defined in it; and although very very common in the past as part of the many NAMELIST extensions wheh NAMELIST was standardized I am not sure of the top of my head whether auto-scanning for different NAMELIST names and/or multiple NAMELIST defintions made it into the standard; although I still have NAMELIST files like that that have not caused problems. ---
**Author:** ![Beliavsky](https://avatars.discourse-cdn.com/v4/letter/b/ba8739/32.png) [@Beliavsky](https://fortran-lang.discourse.group/u/Beliavsky)\ **Post date:** [March 10, 2024, 11:34am UTC](https://fortran-lang.discourse.group/t/add-a-specifier-to-namelist-read-that-requires-all-members-to-be-read/7578/6 "2024-03-10T11:34:04Z")
> [@urbanjost](#): > > Different strokes for different folks, I suppose. I have wanted NAMELIST to be able to read from a file that defines values not in the namelist group for a long time; which would make NAMELIST far more flexible for use in reading configuration files. That is, if the namelist file set x, y, and z I would like to read the file with a namelist group that only contained a subset of those values. Yes, often two programs share some but not all parameters. Maybe the namelist READ could add an `allow_extra=.true.` specifier to allow a namelist file to have members not present in the namelist of the program. ---
**Author:** ![sblionel](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/sblionel/32/853_2.png) [@sblionel](https://fortran-lang.discourse.group/u/sblionel)\ **Post date:** [March 10, 2024, 8:39pm UTC](https://fortran-lang.discourse.group/t/add-a-specifier-to-namelist-read-that-requires-all-members-to-be-read/7578/7 "2024-03-10T20:39:08Z")
The “alliow\_extra” is not really feasible, as it would require the compiler to pass names and info on every single variable mentioned in the program unit. rather than just those in the namelist. (I implemented namelist in the VAX Fortran run-time library so I know how this works.) I think this need is better suited to one of the XML parsing libraries. ---
**Author:** ![Beliavsky](https://avatars.discourse-cdn.com/v4/letter/b/ba8739/32.png) [@Beliavsky](https://fortran-lang.discourse.group/u/Beliavsky)\ **Post date:** [March 10, 2024, 8:46pm UTC](https://fortran-lang.discourse.group/t/add-a-specifier-to-namelist-read-that-requires-all-members-to-be-read/7578/8 "2024-03-10T20:46:18Z")
The specifier `allow_extra = .true.` would cause the program to ignore data in the namelist file that was not in the namelist of the program. The program would not read variables not in the namelist from the namelist file. ---
**Author:** ![urbanjost](https://avatars.discourse-cdn.com/v4/letter/u/0ea827/32.png) [@urbanjost](https://fortran-lang.discourse.group/u/urbanjost)\ **Post date:** [March 11, 2024, 5:26am UTC](https://fortran-lang.discourse.group/t/add-a-specifier-to-namelist-read-that-requires-all-members-to-be-read/7578/9 "2024-03-11T05:26:51Z")
I was asking that variables be ignored that were not in the NAMELIST group; not that all the variables in a program unit be exposed; but that would indeed be a terrific option as well! I can understand how difficult that would be in a compiled language but it must be feasible (perhaps at a very high performance cost) as debuggers allow it; as well as changing values via expressions. Allowing expressions in NAMELIST input would be another great future; as well as conditionals that I think would be another game-changer for NAMELIST input. But I was just suggest that if I had a number of programs that already read and shared NAMELIST files having GRP2 in them and I then changed on program to have a new variable “N” that I would not have to change all the programs to have N to continue using the same files. The work-around in some cases is to put N into a new NAMELIST group so the file has two groups instead of one in it, which is less than ideal and at least in the past used to have problems with some compilers that did not support multi-group and multi-case NAMELIST files. An artificial single-file program that illustrates what I wish would run successfully: ```fortran program testit implicit none real x; namelist /grp1/ x; namelist /grp2/ x real y; namelist /grp1/ y; namelist /grp2/ y integer n; namelist /grp1/ n integer :: io, iostat character(len=256) :: iomsg x = tiny(0.0) y = huge(0.0) n = digits(0.0) open (newunit=io, & & status='scratch', & & form='formatted', & & access='sequential', & & iostat=iostat, & & iomsg=iomsg, & & action='readwrite') if(iostat.ne.0)then write(*,'(*(g0))')'',iomsg stop 1 endif write (io, nml=grp1) write (*, nml=grp1) rewind (io, iostat=iostat) x=-0.0 y=-0.0 write (*, nml=grp1) !read (io, nml=grp1) ! this would work read (io, nml=grp2) ! file has x,y,z values but just want to read x,y write (*, nml=grp1) end program testit ``` so the suggestion for `allow_extra = .true.` would do what I want; albeit I would probably use it with all NAMELIST group I/O! ---
**Author:** ![everythingfunctional](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/everythingfunctional/32/176_2.png) [@everythingfunctional](https://fortran-lang.discourse.group/u/everythingfunctional)\ **Post date:** [March 11, 2024, 4:44pm UTC](https://fortran-lang.discourse.group/t/add-a-specifier-to-namelist-read-that-requires-all-members-to-be-read/7578/10 "2024-03-11T16:44:14Z")
This is one of the big reasons I stopped using list directed and namelist read for user inputs. There is no way in the general case to determine if the user provided the inputs or not. I always recommend that user inputs be formatted and read in one of a handful of more standardized formats (i.e. json, yaml, toml, etc.). Even still, writing the specifications defining what user options are required, especially in the cases where the are conditional on other inputs, what default values there are, what options should not be present, etc., is a hard problem™. ---
**Author:** ![gronki](https://avatars.discourse-cdn.com/v4/letter/g/a88e4f/32.png) [@gronki](https://fortran-lang.discourse.group/u/gronki)\ **Post date:** [March 11, 2024, 8:55pm UTC](https://fortran-lang.discourse.group/t/add-a-specifier-to-namelist-read-that-requires-all-members-to-be-read/7578/11 "2024-03-11T20:55:00Z")
Personally `namelist` has always felt like an ultra-obsolescent feature to me, just like a `common` block. So the best improvement would be its removal from the language, in my opinion. Luckily with improving Fortran ecosystem we are able to read `json`, `toml`s and other members of the “four letter key-value formats” gang! 🙂 ---
**Author:** ![sblionel](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/sblionel/32/853_2.png) [@sblionel](https://fortran-lang.discourse.group/u/sblionel)\ **Post date:** [March 11, 2024, 9:14pm UTC](https://fortran-lang.discourse.group/t/add-a-specifier-to-namelist-read-that-requires-all-members-to-be-read/7578/12 "2024-03-11T21:14:57Z")
FWIW, NAMELIST was a feature from IBM FORTRAN in the mid-1970s that eventually got added (with slight changes) to Fortran 90. The original intent was to permit a program to save and restore its state, it wasn’t really intended to be for user interactive input, though DEC and others extended it in that direction. I agree with @everythingfunctional that it has largely outlived its usefulness, and don’t recommend it in cases where you want to place additional demands on the user. (Like list-directed, namelist-directed input can accept things you may not want it to.) ---
**Author:** ![rwmsu](https://avatars.discourse-cdn.com/v4/letter/r/48db29/32.png) [@rwmsu](https://fortran-lang.discourse.group/u/rwmsu)\ **Post date:** [March 11, 2024, 10:51pm UTC](https://fortran-lang.discourse.group/t/add-a-specifier-to-namelist-read-that-requires-all-members-to-be-read/7578/13 "2024-03-11T22:51:50Z")
NAMELIST is still very useful during code development for writing small driver routines to do unit tests on individual routines or modules. I find it easier than list directed input/output and lets you delay writing the usually much larger IO routines you will need for your final production code when you only need to specify a few variables for the unit test. Also, according to my 1970 copy of Fredrick Stuarts “Fortran Programming” book, namelist was implemented in a handful of compilers prior to 1970 including one for your old employers PDP-10 systems. ---
**Author:** ![RonShepard](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@RonShepard](https://fortran-lang.discourse.group/u/RonShepard)\ **Post date:** [March 12, 2024, 4:05pm UTC](https://fortran-lang.discourse.group/t/add-a-specifier-to-namelist-read-that-requires-all-members-to-be-read/7578/14 "2024-03-12T16:05:22Z")
> [@gronki](#): > > So the best improvement would be its removal from the language, in my opinion. I use namelist i/o all the time in my codes, so I think it is very useful. If you have many input variables, but only a few of them need to be specified on any particular run, then namelist is optimal. This is, of course, the opposite use case from the thread title. If it were to be improved, I would like it to be able to allocate arrays to the correct size automatically. This feature would be nice for list-directed i/o too, but it would be even more useful for namelist. Otherwise, you need to read in the scalar dimensions in one read, then allocate the arrays, then read in the arrays in another read, which is unnecessarily complicated. ---
**Author:** ![jcwright](https://avatars.discourse-cdn.com/v4/letter/j/f0a364/32.png) [@jcwright](https://fortran-lang.discourse.group/u/jcwright)\ **Post date:** [March 14, 2024, 5:26pm UTC](https://fortran-lang.discourse.group/t/add-a-specifier-to-namelist-read-that-requires-all-members-to-be-read/7578/15 "2024-03-14T17:26:05Z")
This would permit typos ---
**Author:** ![jcwright](https://avatars.discourse-cdn.com/v4/letter/j/f0a364/32.png) [@jcwright](https://fortran-lang.discourse.group/u/jcwright)\ **Post date:** [March 14, 2024, 5:27pm UTC](https://fortran-lang.discourse.group/t/add-a-specifier-to-namelist-read-that-requires-all-members-to-be-read/7578/16 "2024-03-14T17:27:39Z")
Removing features is very anti-fortran. Breaks backwards compatibility at the least. ---
**Author:** ![jcwright](https://avatars.discourse-cdn.com/v4/letter/j/f0a364/32.png) [@jcwright](https://fortran-lang.discourse.group/u/jcwright)\ **Post date:** [March 14, 2024, 5:37pm UTC](https://fortran-lang.discourse.group/t/add-a-specifier-to-namelist-read-that-requires-all-members-to-be-read/7578/17 "2024-03-14T17:37:30Z")
You do understand permitting extra would permit errors and typos , right? Right now you mistype and fortran catches it. With this feature it would be considered extra. Unless you want to require all inputs in the namelist which is basically the opposite of current behavior. typed, name/value pairs in arbitrary order, with partial use and defaults and comments is very powerful. Most languages don’t have it write libraries to provide that functionality. Apple is developing PKL for typed input right now. Though it also includes validation - which I think belongs in the code anyway. or see C++ libconfig ---
**Author:** ![urbanjost](https://avatars.discourse-cdn.com/v4/letter/u/0ea827/32.png) [@urbanjost](https://fortran-lang.discourse.group/u/urbanjost)\ **Post date:** [March 15, 2024, 2:41pm UTC](https://fortran-lang.discourse.group/t/add-a-specifier-to-namelist-read-that-requires-all-members-to-be-read/7578/18 "2024-03-15T14:41:04Z")
Yes. many namelist files I have used are programmatically generated so spelling errors are not a major issue, and the feature (particularly if only available via an optional flag) would be well worth typoed names being allowed. This would be the same case as with Fortran that has the risk of typos without IMPLICIT NONE. The check is highly desirable in many cases, but not all. In this case it would be easy to maintain a small program that checked all names for verifying files. I often see file validation checkers for XML files as one example of how this can be handled. ---
**Author:** ![RonShepard](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@RonShepard](https://fortran-lang.discourse.group/u/RonShepard)\ **Post date:** [March 15, 2024, 5:20pm UTC](https://fortran-lang.discourse.group/t/add-a-specifier-to-namelist-read-that-requires-all-members-to-be-read/7578/19 "2024-03-15T17:20:59Z")
> [@urbanjost](#): > > In this case it would be easy to maintain a small program that checked all names for verifying files That small program could be simply a namelist read with all the variables and without the `allow_extra=.true.` flag. ---
**Author:** ![jwmwalrus](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jwmwalrus/32/4483_2.png) [@jwmwalrus](https://fortran-lang.discourse.group/u/jwmwalrus)\ **Post date:** [June 18, 2024, 2:57am UTC](https://fortran-lang.discourse.group/t/add-a-specifier-to-namelist-read-that-requires-all-members-to-be-read/7578/21 "2024-06-18T02:57:30Z")
(Even though I used to hangout a lot at `comp.lang.fortran` back in the day, this is my first post at `fortran-lang.discourse.group`) I also use namelists all the time, mostly for config input, as in ```fortran type :: app_config logical :: fallback_to_x = .false. integer :: max_retries = 5 integer :: timeout_ms = 60000 character(63) :: default_prefix = '' end type type(app_config) :: config namelist /nml_config/config ... ``` Since config values have a default, and input must be sanitized anyway, the “unexpected input values” argument might not hold. Besides the automatic allocation of arrays feature mentioned by @RonShepard , allowing namelists in the specification part of a (not-in-do-concurrent) block construct would also be a great addition. [Next page](https://fortran-lang.discourse.group/t/add-a-specifier-to-namelist-read-that-requires-all-members-to-be-read/7578.md?page=2)