因此,我的最终目标是评估 cabal 文件中依赖项的准确性,方法是确保项目导入的所有实体都存在于它声称可以使用的版本中。
一个好的开始是查找单个源文件使用的所有导入实体的列表,可选择包含它们来自何处的信息。
我愿意暂时忽略类实例的情况,因为检测它们的使用并不是那么简单。
理想的答案是指向一个工具的指针,它可以做到这一点,但我也会接受一个答案,指向我需要自己编写的资源(GHC 是否收集此信息?它是否将其转储到任何地方?可以吗?被说服这样做?)
因此,我的最终目标是评估 cabal 文件中依赖项的准确性,方法是确保项目导入的所有实体都存在于它声称可以使用的版本中。
一个好的开始是查找单个源文件使用的所有导入实体的列表,可选择包含它们来自何处的信息。
我愿意暂时忽略类实例的情况,因为检测它们的使用并不是那么简单。
理想的答案是指向一个工具的指针,它可以做到这一点,但我也会接受一个答案,指向我需要自己编写的资源(GHC 是否收集此信息?它是否将其转储到任何地方?可以吗?被说服这样做?)
最终,haskell-names应该能够以最小的努力完成类似的事情。需要注意的是,您需要使用 haskell-names 自己的“编译器”重新“编译”您引用的每个包,以便生成接口文件。将来我还计划为所有 hackage 包分发预编译的接口(可能来自 hackage 本身)。
现在 haskell-names 正在进行中,还不能编译base
。
GHC API 的优点是如果您安装了软件包,您已经拥有接口文件,但我不确定它是否可以访问导入的实体列表。