fortran中的嵌套名称列表

namelist

是一种有用的

fortran

结构，用于从文件中快速初始化变量。

名称列表

有一个名称并包含一组已知类型的变量。这使得它类似于

类型

构造

通常情况下，给定给程序或子例程的参数最好不是以列表的形式组织，而是以层次结构的形式组织，如菜单界面。扩展类型，如

类型，扩展（简单）：：高级
似乎是这种层次结构的良好表示

然而，使用
名称列表
结构来读取此数据表示似乎很尴尬，因为最终可能会得到很长的此类名称列表

&options
 very_long_option_X   =  1,
 very_long_option_Y   =  2,
 long_option_B%long_descriptive_name_a = 10,
 long_option_B%long_descriptive_name_b = 20,
 long_option_D%long_suboption_DD%long_descriptive_name_a = 300,
 long_option_D%long_suboption_DD%long_descriptive_name_b = 400,
 long_option_D%long_suboption_DD%long_descriptive_name_c = 500,
/

许多人会说这并不理想，他们更愿意这样做

&options
   very_long_option_X   =  1,
   very_long_option_Y   =  2,
   &long_option_B
      long_descriptive_name_a = 10,
      long_descriptive_name_b = 20
   /
   &long_option_D
      &long_suboption_DD
         long_descriptive_name_a = 300,
         long_descriptive_name_b = 400,
         long_descriptive_name_c = 500
      /
   /
/

因此，我想问什么是读取此类数据结构的好方法。如何处理这种情况？
由于嵌套的名称列表不存在，其他方法可能更好。XML似乎是一种流行的选择。有可用的Fortran XML库，如和。
我在代码中要做的是在名称列表中有一个额外的变量，该变量指向另一个文件，然后该文件读取内容。因此：

&options
very_long_option_X   =  1,
very_long_option_Y   =  2,
long_option_B_filename = 'a_file'
long_option_D_filename = 'another_file'
/

然后在一个_文件中：

&long_option_B

  long_descriptive_name_a = 10,
  long_descriptive_name_b = 20
/

另一个文件：

&long_option_D
  long_suboption_DD_filename = 'another_another_file'
/

等

然后，在中读取每个名称列表以查看文件名是否已设置，如果已设置，则将该文件读入下一个名称列表。
配置文件实际上是一个经常实现自定义语言或至少自定义语法分析器的领域。不仅是Fortran程序员，而且（或主要）是许多其他语言的程序员

基本上，我们可以绘制一个配置文件应该遵循的语法，然后手动为这种语法编写一个解析器，通常可以作为使用语法的各种元素的递归函数构成的递归下降解析器，也可以作为状态机和定义的状态间转换。如果想要避免手动路由，可以使用解析器生成器（如ANTLR）或解析器组合器。这些工具通常不针对Fortran。然而，在github.com上搜索会发现一些最新信息

几年前，当我需要Fortran中的配置文件解析器时，我采用了手动递归下降法。我的拙劣尝试可以在中的
ParseTrees
模块中找到，但还远远不够完美。我展示它只是为了举例说明。它读取的配置文件如下所示

当然可以使用JSON等通用格式的库（也有Fortran实现，例如），但必须遵循它们的格式规范。例如，JSON不允许注释，这对我来说是不允许的

无论您选择哪种高级方式，您都将负责将解析语法树中的数据转换为数据结构。没有工具能帮你，阿法亚。这就是标准名称列表真正发挥作用的方面。
可能不容易将
名称列表
写入XML解析器。如果真的有必要，我可以使用一些TOML或JSON解析器读入这样一个嵌套的输入文件，通过一些辅助代码或脚本将数据写入临时名称列表文件（带有%符号），然后将自动生成的名称列表文件读入Fortran中的派生类型（通过通常的名称列表），尽管有点繁琐。。。（在etc中询问可能对实际代码或其他基于库的方法有用）@roygvib是的，将第二种人类可读形式解析为第一种冗长的名称列表可能并不困难。我会用fortran语言写，但我没有完全意识到可能存在的陷阱。我会看看你的链接。很好的分析！我会看看你提供的链接。我特别同意你的最后一句话。名单的优点是无可争议的，因此我尽量不偏离这条路线太多。