惯用的意思是重写Haskell JSON创建库
我不想问这个问题时不礼貌。但是,我最近一直在尝试学习Haskell,并希望了解该语言的最佳实践。我目前正在阅读有关解析haskell文件的库,并作为JSON文档排除解析树。 main.hs并尝试为解析树的每个元素得出JSON生产商。撰写Haskell程序时,人们通常会使用代码生成器吗?我认为计算机创建的代码会破坏功能编程的优雅,还是我错了?是否有任何简化以下代码的惯用方法?
// ~80 lines of the same statements have been elided
instance ToJSON l => ToJSON (FunDep l) where
toJSON (FunDep l n1 n2)
= object [pack "FunDep" .= [toJSON l, toJSON n1, toJSON n2]]
instance ToJSON l => ToJSON (GadtDecl l) where
toJSON (GadtDecl l n1 t2)
= object [pack "GadtDecl" .= [toJSON l, toJSON n1, toJSON t2]]
instance ToJSON l => ToJSON (FieldDecl l) where
toJSON (FieldDecl l n1 b2)
= object [pack "FieldDecl" .= [toJSON l, toJSON n1, toJSON b2]]
鉴于所有功能都具有相似的签名,难道无法创建一个函数构建器,该函数构建器返回parse树每个元素的必要参数?或者,一个人至少可以将必要的信息存储在CSV文件中并在运行时检索它吗?
我对继续进行Haskell研究的持续非常热情,并且不想挑选任何特定的存储库。
I do not wish to be rude in asking this question; however, I have recently been attempting to learn Haskell and wish to understand the best practices of the language. I am currently reading about a library that parses a Haskell file and emits a parse tree as a json document. The contents of Main.hs appear repetitive and attempt to derive a json producer for every element of the parse tree. Do people commonly use code generators when writing Haskell programs? I would assume that computer created code would defeat the elegance of functional programming, or am I wrong? Would there be any idiomatic means of simplifying the following code?
// ~80 lines of the same statements have been elided
instance ToJSON l => ToJSON (FunDep l) where
toJSON (FunDep l n1 n2)
= object [pack "FunDep" .= [toJSON l, toJSON n1, toJSON n2]]
instance ToJSON l => ToJSON (GadtDecl l) where
toJSON (GadtDecl l n1 t2)
= object [pack "GadtDecl" .= [toJSON l, toJSON n1, toJSON t2]]
instance ToJSON l => ToJSON (FieldDecl l) where
toJSON (FieldDecl l n1 b2)
= object [pack "FieldDecl" .= [toJSON l, toJSON n1, toJSON b2]]
Given that all of the functions possess similar signatures, would it not be possible to create a function builder that returns the necessary parameters for each element of the parse tree? Or, could one at least store the necessary information in a csv file and retrieve it at runtime?
I am very enthusiastic regarding the continuation of my Haskell studies and do not wish to single out any particular repository.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
生成代码是正常的,惯用的,并且在您指向的文件中使用。如果您滚动几行,您会看到:
这些行是在将来的某个时候扩展到您显示的线条;有关为什么它们当前不存在的更多信息,请参见链接的问题。
(顺便说一句:没有什么可以阻止某人创建
derivetojsons
或以类型名称而不是单个类型名称的收集的东西。他们可能应该这样做,以便他们可以写作并只有一个列出了约50个元素,而不是派生的50行。
Generating code is normal, idiomatic, and used in exactly the file you pointed at. If you scroll up a few lines, you'll see:
These lines are intended, at some point in the future, to expand to the ones you show; see the linked issue for more on why they don't currently.
(Aside: there is nothing stopping somebody from creating a
deriveToJSONs
or something that takes a collection of type names instead of a single type name. They probably should do that, so that they could writeand just have a list with ~50 elements rather than 50 lines of deriving calls. Probably they just didn't think of it.)