# Namelist attribute for use in variable declaration **URL:** \ **Category:** Language enhancement\ **Created:** [April 1, 2024, 7:57am UTC](https://fortran-lang.discourse.group/t/namelist-attribute-for-use-in-variable-declaration/7739 "2024-04-01T07:57:16Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Machalot](https://avatars.discourse-cdn.com/v4/letter/m/ebca7d/32.png) [@Machalot](https://fortran-lang.discourse.group/u/Machalot)\ **Post date:** [April 1, 2024, 7:57am UTC](https://fortran-lang.discourse.group/t/namelist-attribute-for-use-in-variable-declaration/7739/1 "2024-04-01T07:57:16Z")
To avoid the need for a namelist variable to appear twice, first in a declaration and then in a namelist group definition, would it make sense to add a `namelist` attribute? So this: ```fortran real :: good, push, it namelist /snp/ good, push, it ``` would be equivalent to ```fortran real, namelist(snp) :: good, push, it ``` To support the fact that a variable can appear in multiple namelist groups, maybe the attribute could accept a comma separated list, like so: ```fortran real, namelist(snp1, snp2, othernml) :: good, push, it ``` This is a half baked idea so I’d love to hear some feedback from the community. ---
**Author:** ![Arjen](https://avatars.discourse-cdn.com/v4/letter/a/b9bd4f/32.png) [@Arjen](https://fortran-lang.discourse.group/u/Arjen)\ **Post date:** [April 1, 2024, 8:32am UTC](https://fortran-lang.discourse.group/t/namelist-attribute-for-use-in-variable-declaration/7739/2 "2024-04-01T08:32:43Z")
Welcome to the forum! I never use namelists (although they are a nice enough feature), but looking at your suggestion, how would you define the order of the variables in the namelist? Here is an example where this is not going to be obvious, as far as I can tell: ```auto real :: good, push, it integer :: countthem namelist /snp/ good, countthem, push, it ``` Wouldn’t your suggestion restrict the ordering? ---
**Author:** ![Beliavsky](https://avatars.discourse-cdn.com/v4/letter/b/ba8739/32.png) [@Beliavsky](https://fortran-lang.discourse.group/u/Beliavsky)\ **Post date:** [April 1, 2024, 12:17pm UTC](https://fortran-lang.discourse.group/t/namelist-attribute-for-use-in-variable-declaration/7739/3 "2024-04-01T12:17:41Z")
To avoid restricting the members of a namelist to having a single data type, one could have syntax analogous to a derived type: ```auto namelist :: snp real :: x, y integer :: i, j end namelist ``` A variable could appear in more than one such namelist declaration, with the restriction that its type must be the same in each. With your proposed syntax, one could allow ```auto real, namelist(snp) :: x, y ... integer, namelist(snp) :: i, j ``` but I think it is clearer to have all members of a namelist listed in one place. ---
**Author:** ![Machalot](https://avatars.discourse-cdn.com/v4/letter/m/ebca7d/32.png) [@Machalot](https://fortran-lang.discourse.group/u/Machalot)\ **Post date:** [April 1, 2024, 4:06pm UTC](https://fortran-lang.discourse.group/t/namelist-attribute-for-use-in-variable-declaration/7739/4 "2024-04-01T16:06:49Z")
It should be simple enough to order the namelist in the same order the variables appear in declarations, just like is done with derived types and enumerators. The following would be equivalent: ```fortran real :: good, push, it integer :: countthem namelist /snp/ good, countthem, push, it ``` ```fortran real, namelist(snp) :: good integer, namelist(snp) :: countthem real, namelist(snp) :: push, it ``` ---
**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:** [April 1, 2024, 4:11pm UTC](https://fortran-lang.discourse.group/t/namelist-attribute-for-use-in-variable-declaration/7739/5 "2024-04-01T16:11:26Z")
This is an example of what’s called “syntactic sugar” - an alternate way of saying something the language already allows. We tend to look on this with disfavor, and I think that attitude would be stronger for a feature such as NAMELIST. ---
**Author:** ![Machalot](https://avatars.discourse-cdn.com/v4/letter/m/ebca7d/32.png) [@Machalot](https://fortran-lang.discourse.group/u/Machalot)\ **Post date:** [April 1, 2024, 4:31pm UTC](https://fortran-lang.discourse.group/t/namelist-attribute-for-use-in-variable-declaration/7739/6 "2024-04-01T16:31:23Z")
What I’m trying to improve (IMHO) with this suggestion is to avoid this situation, having every variable appear twice in the declaration section: ```fortran real, dimension(10), public, save :: good integer, public, save :: countthem real, allocatable, dimension(:,:), public, save :: push real, pubic, save :: it ! 496 other variable declarations namelist / snp / good, countthem, push, & ! 495 other variable names manually retyped to appear a second time in the ! declaration section of this module with a bunch of continuation lines... ! Oops, I forgot 'it' and missed another one somewhere in the middle ``` ---
**Author:** ![Machalot](https://avatars.discourse-cdn.com/v4/letter/m/ebca7d/32.png) [@Machalot](https://fortran-lang.discourse.group/u/Machalot)\ **Post date:** [April 1, 2024, 4:39pm UTC](https://fortran-lang.discourse.group/t/namelist-attribute-for-use-in-variable-declaration/7739/7 "2024-04-01T16:39:34Z")
> [**sblionel**](https://fortran-lang.discourse.group/u/sblionel) > This is an example of what’s called “syntactic sugar” - an alternate way of saying something the language already allows. We tend to look on this with disfavor, and I think that attitude would be stronger for a feature such as NAMELIST. Do you view this differently from other “sugar” features Fortran already has? I might not know enough appreciate the distinction. For example, ```fortran real :: good dimension :: good(10) public :: good namelist / snp / good ``` ```fortran real, dimension(10), public :: good namelist / snp / good ``` ---
**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:** [April 1, 2024, 4:54pm UTC](https://fortran-lang.discourse.group/t/namelist-attribute-for-use-in-variable-declaration/7739/8 "2024-04-01T16:54:54Z")
I do. Fortran 90 added the concept of attributes to a single declaration but did not remove the older statement-style of adding attributes. (New attributes were added as statements for symmetry.) There are other examples of this. What I see as different here is that there are multiple concepts you’re trying to shoehorn into a feature, none of which add new capabilities. That they are tied to the rarely used NAMELIST feature doesn’t help. Personally, I’d find it confusing to need to identify all the variables in a particular namelist group, given that during namelist input you must first give the group name. It’s not like (obsolescent) COMMON, where a variable can belong to only one common block. I often say that there are no zero-cost features. Just the standards work alone to come up with specifications and edits for this would not be trivial, not to mention compiler work. I’d prefer to see us focus on adding new capabilities to the language and not keep one-plusing old stuff. ---
**Author:** ![RonShepard](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@RonShepard](https://fortran-lang.discourse.group/u/RonShepard)\ **Post date:** [April 1, 2024, 5:16pm UTC](https://fortran-lang.discourse.group/t/namelist-attribute-for-use-in-variable-declaration/7739/9 "2024-04-01T17:16:38Z")
> [@Machalot](#): > > What I’m trying to improve (IMHO) with this suggestion is to avoid this situation, having every variable appear twice in the declaration section: The suggested syntax requires multiple references to the namelist group, so I don’t see this as much of an improvement over the current standard syntax. Consider the common code style of one variable per declaration line with inline documentation of that variable. There is also the problem associated with misspellings of the group name. Consider ```auto real, namelist(snp) :: good integer, namelist(snnp) :: countthem real, namelist(snpp) :: push, it ``` How could a compiler recognize the difference between the two typos and the situation where there are three similarly named groups? As for code simplification and reduction of programmer errors, the suggestion seems like six of one, half a dozen of the other. One thing I have wanted in the past is the ability to specify the namelist group and list within the executable statements right before the read statement. The current standard requires that to be in the declaration statements, which is sometimes far removed from the read statement. I think the problem with this is that there are other declaration statements (e.g. `public` and `private`) that can refer to the namelist group, so this feature would require the compiler to look ahead more than is currently necessary. ---
**Author:** ![Machalot](https://avatars.discourse-cdn.com/v4/letter/m/ebca7d/32.png) [@Machalot](https://fortran-lang.discourse.group/u/Machalot)\ **Post date:** [April 1, 2024, 5:58pm UTC](https://fortran-lang.discourse.group/t/namelist-attribute-for-use-in-variable-declaration/7739/10 "2024-04-01T17:58:20Z")
If there’s no appetite for syntactic sugar, let alone `namelist` enhancements, I suppose the rest of this conversation is just a thought experiment. > [@sblionel](#): > > Personally, I’d find it confusing to need to identify all the variables in a particular namelist group, given that during namelist input you must first give the group name. Can you please expand on this statement – “confusing to need to identify”? I could easily be misinterpreting what you mean. ---
**Author:** ![septc](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/septc/32/77_2.png) [@septc](https://fortran-lang.discourse.group/u/septc)\ **Post date:** [April 1, 2024, 5:58pm UTC](https://fortran-lang.discourse.group/t/namelist-attribute-for-use-in-variable-declaration/7739/11 "2024-04-01T17:58:24Z")
@RonShepard, RE repetition and possible typo of namelist-group names, @Beliavsky already suggested a different approach above, which looks nice (to me): > [@Beliavsky](#): > > To avoid restricting the members of a namelist to having a single data type, one could have syntax analogous to a derived type: > > ```auto > namelist :: snp > real :: x, y > integer :: i, j > end namelist > > ``` @sblionel, @RonShepard I wonder what both of you think about the redundancy of declaring a lot of variable names both in the declaration and namelist statements (as suggested by @Machalot above), because I also have similar problems (for which I use derived types as a workaround). Also, because Fortran lacks introspection, even the use of TOML or other modern formats requires further redundant works for setting variable values from input data (e.g., as discussed in the following thread). Because of the lack of introspection in Fortran, I use namelist everyday (as opposed to the “rarely used NAMELIST feature doesn’t help” assumption by @sblionel). > [@Introspection in Fortran for generic file I/O libraries](https://fortran-lang.discourse.group/t/introspection-in-fortran-for-generic-file-i-o-libraries/4997): > > What would it take to be able to write an I/O library (JSON, TOML, etc.) for Fortran that was as easy for a user to use as the built-in namelists (which, frankly, people shouldn’t be using). Currently, users of the libraries for modern file formats have to write a lot of verbose code, since there’s not currently any way for the generic library to know anything about the variables in their custom types. An example: type :: mytype integer, dimension(:),allocatable :: ints character(len=10) :: … ---
**Author:** ![Machalot](https://avatars.discourse-cdn.com/v4/letter/m/ebca7d/32.png) [@Machalot](https://fortran-lang.discourse.group/u/Machalot)\ **Post date:** [April 1, 2024, 6:10pm UTC](https://fortran-lang.discourse.group/t/namelist-attribute-for-use-in-variable-declaration/7739/12 "2024-04-01T18:10:55Z")
> [@RonShepard](#): > > How could a compiler recognize the difference between the two typos and the situation where there are three similarly named groups? I don’t see this as a different class of problem than mistyping similar variable names or procedure names (such as `xi, xii, xix, xlix, xilx`). It is already the programmer’s responsibility to choose good names that are distinct enough so a typo is unlikely to compile into a wrong program. As we know, disabling implicit typing makes this much better. I suppose there should be a `namelist` declaration statement so the compiler can catch typos that don’t match the name of any other `namelist` group. ```fortran namelist :: snp namelist :: snpp ! try choosing more distinct names to avoid problems with typos real, namelist(snp) :: good ! valid integer, namelist(snnp) :: countthem ! compiler error: nonexistent namelist group snnp real, namelist(snpp) :: push, it ! valid ``` But as I said above, sounds like this is DOA so any further discussion is just a thought experiment. Thanks for engaging on my first post! ---
**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:** [April 1, 2024, 9:15pm UTC](https://fortran-lang.discourse.group/t/namelist-attribute-for-use-in-variable-declaration/7739/13 "2024-04-01T21:15:01Z")
> [@Machalot](#): > > Can you please expand on this statement – “confusing to need to identify”? I could easily be misinterpreting what you mean. I meant that if I am scanning the code trying to figure out which variables are in which namelist, scattering the namelist group names across various declarations makes it difficult. ---
**Author:** ![han190](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/han190/32/7158_2.png) [@han190](https://fortran-lang.discourse.group/u/han190)\ **Post date:** [April 1, 2024, 9:26pm UTC](https://fortran-lang.discourse.group/t/namelist-attribute-for-use-in-variable-declaration/7739/14 "2024-04-01T21:26:51Z")
I prefer @Beliavsky 's idea as well. To me a more ideal case is to make `namelist` an attribute of the derive type. In the current Fortran standard, both derived type and parameterized derived type are allowed, and to me that is an advantage of using namelist over TOML/JSON libraries since I don’t have to write an extra layer to convert parameters to my customized derived types. But reading a derived type from a namelist is painful (especially when allocatable components are involved). I guess namelist can be a lot more useful if we could do something like the following: ```auto type :: color integer :: r, g, b end type type, namelist :: window integer :: width integer :: height type(color) :: default_color end type window contains !... read(unit=unit, nml=window) ``` read a namelist ```auto &window width=800 height=600 default_color=color(255, 255, 255) / ``` ---
**Author:** ![urbanjost](https://avatars.discourse-cdn.com/v4/letter/u/0ea827/32.png) [@urbanjost](https://fortran-lang.discourse.group/u/urbanjost)\ **Post date:** [April 1, 2024, 10:34pm UTC](https://fortran-lang.discourse.group/t/namelist-attribute-for-use-in-variable-declaration/7739/15 "2024-04-01T22:34:15Z")
One of the few places where I use semi-colons is when building namelists ```fortran integer :: i; namelist /args/i real :: r; namelist /args/r ``` which comes a little close to the original OP request while conforming to the current standard. I like the suggested syntax by @Beliavsky but I have not though out whether it covers all the interesting aspects of building upon an existing namelist; particularly when imported from a module or in multiple contained procedures or if that meets the restrictions like not building a namelist in a block structure (I think). I seem to recall wanting to create a namelist for debugging using something like ```fortran block namelist /debug/ a,b,c write(*,nml=debug) endblock ``` and being disappointed that was not allowed if I remember correctly (did not verify that). ---
**Author:** ![septc](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/septc/32/77_2.png) [@septc](https://fortran-lang.discourse.group/u/septc)\ **Post date:** [April 2, 2024, 2:35am UTC](https://fortran-lang.discourse.group/t/namelist-attribute-for-use-in-variable-declaration/7739/16 "2024-04-02T02:35:29Z")
> [@han190](#): > > In the current Fortran standard, both derived type and parameterized derived type are allowed, and to me that is an advantage of using namelist over TOML/JSON libraries since I don’t have to write an extra layer to convert parameters to my customized derived types This is exactly the reason why I use namelist with derived types, even though there are a lot of historical pitfalls (like strange treatments of `*`, `/`, etc). Indeed, the combination of namelist + derived type provides a capability somewhat similar to the examples in the Swift and Rust libraries below (to some extent), thanks to the builtin “introspection” by Fortran compilers. - [GitHub - LebJe/TOMLKit: A small, simple TOML parser and serializer for Swift. Powered by toml++. · GitHub](https://github.com/LebJe/TOMLKit) - [toml - Rust](https://docs.rs/toml/latest/toml/) > [@han190](#): > > But reading a derived type from a namelist is painful (especially when allocatable components are involved) In my case, I often create a new derived type by separating a parameter set that describes “static” information of a simulation from other “dynamic” data , via composition of derived types. Something like… ```auto type FooParam_t !! various params here... endtype type Foo_t type(FooParam_t) :: par !! other dynamic data follow... endtype ``` Then, I can pass `foo%par` to a reader routine like ```auto subroutine read_params( par ) type(FooParam_t) :: par namelist /foo_inp/ par ... read( file, nml=foo_inp ) ... end ``` (which is in my case wrapped as a method of Foo\_t). When I use `Foo_t` in other routines, I also use `associate` at the top of the routine if some params are referenced very often: ```auto subroutine blah( foo, ...) let( num => foo% par% num, & val => foo% par% val ) ... body of the routine .... endlet end subroutine ``` (I define “let” = associate via C preprocessor because I feel the keyword too long…). I guess if future Fortran has some auto-forwarding mechanism (e.g, `foo%par%num` is forwarded to `foo%num`), the use of such a composite type may become simpler (rather than using inheritance). EDIT: I’ve just tried using inheritance for separating parameters (for namelist read), and it seems to work… I’ve never used this up to now, but it may be useful to remove “par” when accessing parameters. ```fortran program main implicit none type FooParam !! "static" info integer :: num = 0 endtype type, extends(FooParam) :: Foo !! "dynamic" info integer, allocatable :: arr(:) endtype type(Foo) :: f call read_inp( f % FooParam ) print *, "params = ", f % FooParam !! 100 print *, "f % num = ", f % num !! 100 contains subroutine read_inp( par ) type(FooParam) :: par namelist /foo_inp/ par open( 10, file="foo.inp", status="old" ) read( 10, nml=foo_inp ) close( 10 ) end end program !! foo.inp &foo_inp par%num = 100 / ``` ---
**Author:** ![septc](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/septc/32/77_2.png) [@septc](https://fortran-lang.discourse.group/u/septc)\ **Post date:** [April 2, 2024, 2:40am UTC](https://fortran-lang.discourse.group/t/namelist-attribute-for-use-in-variable-declaration/7739/17 "2024-04-02T02:40:00Z")
By the way, the “color” code also works: ```fortran !! test.f90 program main implicit none type :: color integer :: r = 1, g = 2, b = 3 end type type :: window integer :: width = -1 integer :: height = -1 type(color) :: default_color end type type(window) :: win namelist /window_inp/ win open( 10, file="test.inp", status="old" ) read( 10, nml=window_inp ) close( 10 ) print *, "win = ", win end !! test.inp &window_inp win%width = 100 win%height = 200 win%default_color%b = 777 / $ gfortran test.f90 && ./a.out win = 100 200 1 2 777 ``` ---
**Author:** ![Machalot](https://avatars.discourse-cdn.com/v4/letter/m/ebca7d/32.png) [@Machalot](https://fortran-lang.discourse.group/u/Machalot)\ **Post date:** [April 2, 2024, 5:32am UTC](https://fortran-lang.discourse.group/t/namelist-attribute-for-use-in-variable-declaration/7739/18 "2024-04-02T05:32:22Z")
> [@sblionel](#): > > I meant that if I am scanning the code trying to figure out which variables are in which namelist, scattering the namelist group names across various declarations makes it difficult. Thank you for clarifying. In the case of my own workflow, this becomes far easier with the proposed syntax. With each variable declared on a separate line, `grep namelist_groupname` returns a compact list of the variable declarations of all its members, to be viewed on-screen or redirected to a pipe or a file for further searching or analysis. As a bonus I can see all their types, kinds, dimensions, and other attributes at a glance. ```bash $ grep snp # my namelist is called snp # or a more precise search $ grep 'namelist(snp)' # my namelist is called snp ``` ```auto my_module.f90: real, namelist(snp), public :: good my_module.f90: real, namelist(snp), dimension(10), public :: push my_module.f90: real, namelist(snp), public :: it my_module.f90: integer, namelist(snp) :: countthem ``` In contrast, with the current `namelist` syntax I have to open the file or have `grep` print a large number of context lines to see the `namelist` members. ```bash $ grep snp # my namelist is called snp ``` ```fortran my_module.f90: namelist / snp / good, countthem, push, it & ! only the first few members ``` In reverse, if I `grep` for a variable name using my proposed syntax, I would immediately see its declaration including all its `namelist` groups directly in the result (assuming it fits on one line): ```bash $ grep good ``` ```auto my_module.f90: real, namelist(snp1, snp2, othernml) :: good ``` In contrast, with the current `namelist / groupname / varnames ...` syntax, I would see its declaration but it’s unlikely the `namelist` group name would appear in a search for a variable name since they are generally on separate lines. Most likely I would see a slice of the `namelist` membership without the actual group name, such as ```bash $ grep good ``` ```fortran my_module.f90: real :: good my_module.f90: good, countthem, push, it, & ! no sign of the namelist group name ``` ---
**Author:** ![Machalot](https://avatars.discourse-cdn.com/v4/letter/m/ebca7d/32.png) [@Machalot](https://fortran-lang.discourse.group/u/Machalot)\ **Post date:** [April 2, 2024, 5:33am UTC](https://fortran-lang.discourse.group/t/namelist-attribute-for-use-in-variable-declaration/7739/19 "2024-04-02T05:33:20Z")
> [@urbanjost](#): > > One of the few places where I use semi-colons is when building namelists > > ```auto > integer :: i; namelist /args/i > real :: r; namelist /args/r > > ``` > > which comes a little close to the original OP request while conforming to the current standard. I saw you post this in another thread, and it is the direct inspiration for this post. ---
**Author:** ![shahmoradi](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/shahmoradi/32/3151_2.png) [@shahmoradi](https://fortran-lang.discourse.group/u/shahmoradi)\ **Post date:** [April 3, 2024, 1:02am UTC](https://fortran-lang.discourse.group/t/namelist-attribute-for-use-in-variable-declaration/7739/20 "2024-04-03T01:02:55Z")
It’s a pity that the standard committee and a significant part of the community show so much apathy toward improving and using namelists. It’s a useful flexible IO feature, but the current implementation of namelist has several weaknesses, including 1. the inability to specify the namelist group name as a string in IO statements. 2. lack of support for derived types with allocatable components. 3. lack of support specifying multiple namelist group names for variable names. The last one is similar to your last enhancement request. These limitations have led to complex hacks using preprocessor flags in our codebase, which may also be the only solution for you in light of the standard committee’s lack of interest in enhancements to namelists. An example of such an approach is [here](https://github.com/cdslaborg/paramonte/blob/449d7d2cbc99baa9a372330a7b7e210481ae2536/src/fortran/main/pm_sampling_scio.imp.F90#L151) where the namelists are _included_ in the main file, while the actual implementation is fenced via a preprocessor flag in a [separate file](https://github.com/cdslaborg/paramonte/blob/449d7d2cbc99baa9a372330a7b7e210481ae2536/src/fortran/main/pm_sampling_scio.inc.F90#L2). Without preprocessing, maintaining all these separate namelist groups with so many common variables would be an infernal nightmare. [Next page](https://fortran-lang.discourse.group/t/namelist-attribute-for-use-in-variable-declaration/7739.md?page=2)