Add a specifier to namelist read that requires all members to be read

Language enhancement
22

I have wanted to do something like

block
namelist/printme/a,b,c,d
write(*,nml=printme)
endblock

on multiple occasions, particularly for debug blocks I am conditionally using or even conditionally including via pre-processing.
So I think that would very useful.

23

The namelist feature is indeed extremely useful, since it integrates directly with the language and it is very easy to load data from a human readable file directly into variables, and let the compiler check it.

However, as mentioned above, it has some fundamental limitations to truly live to its (modern) potential and support other formats like TOML, JSON, etc., allowing the user to implement a new format, and so on. Improving either namelist, or adding a new feature for that would be great.

Here is an issue to discuss this:

2 Likes
24

Is there any reason why the namelist approach can’t be copied for (a subset of) JSON? Something like this is what I have in mind:

        ! JSON representation
        ! {"x": 1.2, "y": 2.5, "R": true, "name": "John Doe" }

        real(kind(1.0d0) :: x, y
        logical :: r
        character(len=:), allocatable :: name
        json /EXAMPLE/ x, (y,key="y"), (r,key="R"), (name,key="name")
        read(json=EXAMPLE,unit=my_unit)

Since JSON keys are case-sensitive or could contain UTF-8 characters, a separate key word is necessary. If omitted it could default to the name of the variable in lower-case (the limited reflection available in Fortran)

Admittedly, there are a few issues when it comes to JSON arrays which are allowed to contain different types and dictionaries (map these to derived types?).

1 Like
25

I think it can be done. That’s the idea behind Introspection in Fortran for generic file I/O libraries (TOML, JSON, NPZ, etc.) · Issue #331 · j3-fortran/fortran_proposals · GitHub.

1 Like
26

I realize it is only a cosmetic detail or my OCD, but whenever / appears (common block, namelists etc) I personally think it should be considered obsolete code, therefore I have never touched the namelists. It would be good to find some more modern syntax that would be consistent with the rest of the language. But it is not yet time for this kind of discussion!