问题标签 [happy]

我遇到了由 Happy 生成的看似无效的代码。问题归结为 GHC 没有为函数推断出多类型签名。这是一个例子：

由于 GHC 正在推断f :: a -> ()where a :: *，因此失败了

我可以打开任何语言编译指示来编译此代码吗？我知道理论上我可以只添加类型签名，但是因为这是由 Happy 生成的代码，我不想手动修改任何内容。

我目前正在使用 alex 和快乐的词法分析器/解析器生成器来实现以太坊智能合约语言可靠性的解析器。目前我正在使用简化的语法来简化初始开发。

我在解析我的测试合同文件的“合同”部分时遇到错误。

以下是语法的代码：

以下文件是我的测试“合同”：

结果是将我的测试合同传递给我的解析器的主要功能。

从错误中它表明问题是第 2 行第 1 列上的“合同”令牌的第一个字母。但据我了解，这应该正确解析吗？

--有没有办法像在 Haskell 中那样将所有内容注释到行尾？我能找到的唯一注释语法是{- commented stuff -}语法。

我在 Happy（Haskell 的 Bison 等价物）中制作了一个简单的解析器，我偶然发现了这些规则中的 shift/reduce 冲突：

信息文件说明了移位/减少冲突：

第 61 条是这样的：

我不确定如何解决这个问题。我尝试使用优先规则来使警告静音，但没有达到我的预期。

我有一个语法，根据产生的顺序，快乐报告 3 减少/减少冲突或没有。我能找到的最小示例是：

这有 3 个减少-减少冲突，基于无法区分“ both 7 -3”和“ both 7-3 2”。很公平！

但是，如果将最后两个产生式换成 E ('-' E %prec NEG和E '-' E)，reduce/reduce 冲突就会消失。更令人费解的是，如果您随后删除该%prec NEG指令，它们就会返回。我对这里发生的事情感到很困惑：为什么顺序很重要？

在我的整个开发过程中，我一直在手动运行 alex/happy 来生成我的解析器文件，然后运行 ​​ghci 来测试代码。这可以正常工作并将我加载到 GHCI 中，但是每当我运行程序时，我的文件cabal repl中都会抛出一个错误。Parser.hs

该错误是一个类型错误：Couldn't match type '[a]' with 'Expression'但是每当我手动测试此代码时ghci main，代码运行正常吗？

我不确定我是否没有完全理解 cabal 的工作原理，但我注意到从 happy 和 cabal 生成的 haskell 解析器是完全不同的。

我在下面附上了 cabal build 命令的错误消息的开头。

编辑

因此，正如 Alec 所指出的，每当运行 cabal 构建时，它都会对-agc标志感到满意，我不知道这一点，因此我的代码需要调整。

解决方案是使用标志构建 Happy 解析器-agc并确保它以这种方式编译。这可能会导致解析器中出现一些新错误，因为生成的解析器略有不同，但根据我的研究，如果没有cabal repl上述标志，就无法愉快地运行。

我用 Alex 和 Happy 构建了一个解析器和词法分析器，它生成了我正在解析的语言的抽象语法树（Solidity）。我现在的问题是如何正确遍历和匹配语言的某些方面。目的是创建一个规则引擎，该引擎将对生成的 AST 执行代码分析，检查特定问题，如函数使用不当、危险调用或缺少某些元素。

这是我的数据的布局，它很高兴作为 AST 输出。（这不是完整的 AST，只是一个快照）

我目前的思路是通过将 传递[SourceUnit]给函数并针对特定情况进行匹配来使用模式匹配。例如，以下函数匹配代码并返回状态变量声明的数据类型。

这会输出以下内容，这部分是我需要的。不幸的是，该语言可能包含多个合同声明，具有多个状态变量声明，所以我认为以这种方式匹配它是完全可能的。

我读过一些关于通用编程和“废弃你的样板”的文章，但我不明白它是如何工作的，或者实现它的最佳方法是什么。

问题是，在这种模式匹配方面，我是否走在正确的轨道上，还是有更好的选择？

我正在从头开始创建一个简单的命令式语言，我已经有了一个工作语法树，没有太多复杂性，它只是使用自下而上的解析方式使用简单的树数据结构来创建它。现在的想法是实现一个完整的 LeBlanc-Cook 风格的符号表。它的结构并不复杂，问题是我不知道如何在创建树的同时让快乐填充它。

一次性完成所有操作背后的想法是，通过这种方式，AST 可以只填充最少必要的内容，而忽略变量或类型声明之类的内容，这些内容只有符号表中的效果。遍历 AST 来填表是我最后的选择。

我的基本概念是它是某种全局状态，仅在某些选择时间进行修改，例如打开新块或声明变量时，但我不知道如何使用快乐给我的环境使用我将创建的任何一元结构。

我知道这个问题可以简化为“快乐是如何工作的？”，但无论如何。任何评论表示赞赏。

这是一个例子来更好地说明我的问题。

似乎单个状态可能无法解决，并且存在单子和非单子动作的组合，解决此问题的最佳结构是什么。

我有以下 yacc/bison/happy 语法：

bison -v告诉我以下情况有两个冲突：

我试图通过给出明确的优先级声明来解决冲突%prec，但无济于事。鉴于野牛根据需要解决了冲突（例如，转变而不是减少），这还不错，但我想知道我们如何在不改变公认语言的情况下摆脱冲突。

我开发了一个预处理器，将 C 语句的子集转换为 gcc _asm 语句。对于这个项目，我很乐意重用使用任何流行的 Haskell 技术编写的现有 C 语句解析器，或者只是从一些简单的 C 子集解析器开始以避免重做现有工作。

不幸的是，到目前为止，我发现除了 C 之外的所有语法。虽然我可以从 Java/Go 的 Parsec 语法开始，但似乎 MegaParsec 是更好的选择？

我可以快速开发小的 C 子集的语法，但是对于较大的 C 子集的即用型语法将允许我完全跳过 C 语句解析器的开发，而专注于项目的核心 - asm 代码生成。

最终，它可能会变成 C++ 代码的 LLVM pass 转译部分，但为了快速原型，我更喜欢 Haskell，特别是如果我能找到现成的解析器。