DeriveFunctor 是一个公认的扩展吗？阴谋集团似乎很困惑
阴谋集团给我的信息很复杂。当我说：
Extensions: DeriveFunctor
它说：
Warning: Unknown extensions: DeriveFunctor
但是当我说：
GHC-Options: -XDeriveFunctor
它说：
Warning: Instead of 'ghc-options: -XDeriveFunctor' use 'extensions:
DeriveFunctor'
现在我将使用 {-# LANGUAGE DeriveFunctor #-} 编译指示。
$ cabal --version
cabal-install version 0.8.2
using version 1.8.0.6 of the Cabal library
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.12.3
$ basename $(mdfind haskell-platform | grep .dmg)
haskell-platform-2010.2.0.0.i386.dmg
Cabal is giving me mixed messages. When I say:
Extensions: DeriveFunctor
It says:
Warning: Unknown extensions: DeriveFunctor
But when I say:
GHC-Options: -XDeriveFunctor
It says:
Warning: Instead of 'ghc-options: -XDeriveFunctor' use 'extensions:
DeriveFunctor'
For now I'm just going to use the {-# LANGUAGE DeriveFunctor #-} pragma.
$ cabal --version
cabal-install version 0.8.2
using version 1.8.0.6 of the Cabal library
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.12.3
$ basename $(mdfind haskell-platform | grep .dmg)
haskell-platform-2010.2.0.0.i386.dmg
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您仍然可以在 .cabal 文件中使用
扩展：DeriveFunctor。是的，它不是 Cabal 目前已知的扩展，但您仍然可以使用它，并且只要编译器识别它，它就可以工作。事实上，Cabal 会检查编译器是否识别该扩展，即使 Cabal 本身并不知道它。模块
Language.Haskell.Extension中有一个扩展的中央注册表。该注册表的目的是使不同的编译器在实现相同的扩展时可以就相同的名称达成一致。过去我们遇到过不同编译器的作者不小心给同一个扩展概念赋予不同名称的情况。并非所有扩展都需要注册。不注册仍处于高度试验阶段的扩展是有意义的，例如 DPH 扩展“PArr”仍未注册。 Hackage 要求所有上传的包仅使用已知的已注册扩展，这是有道理的，因为如果扩展足以在分布式包中使用，那么就可以注册。在这种特殊情况下，GHC 开发人员似乎忘记注册扩展。
还值得注意的是，从 Cabal-1.10 开始，
extensions字段被分为两个：default-extensions和other-extensions。这解决了约翰在回答中指出的问题，即之前的行为是所有扩展对所有模块都是活动的，我们承认这是一个错误。other-extensions字段允许列出某些模块中使用的扩展（即使用LANGUAGEpragma）。 Cabal 最终将强制将它们全部列出，就像它要求列出所有包依赖项一样。语言依赖也是依赖。You can still use
extensions: DeriveFunctorin your .cabal file. Yes, it is not an extension that is currently known to Cabal, but you can still use it and as long as the compiler recognises it then it will work. Indeed Cabal will check that the compiler does recognise the extension, even though Cabal does not itself know about it.There is a central registry of extensions in the module
Language.Haskell.Extension. The purpose of this registry is so that different compilers can agree on the same names when they implement the same extensions. We have had cases in the past where authors of different compilers have accidentally given different names to the same extension concept. Not all extensions need to be registered. It makes sense not to register extensions that are still highly experimental, for example the DPH extensions "PArr" is still not registered. Hackage requires all uploaded packages to use only known registered extensions, which makes sense since if an extension is sufficiently ready to be used in a distributed package, then it is ok to register.In this particular case, the GHC devs appear to have forgotten to register the extension.
It is also worth noting that as of Cabal-1.10 the
extensionsfield is being split into two:default-extensionsandother-extensions. This addresses the issue that John points out in his answer, that the previous behaviour is that all extensions are active for all modules, which we acknowledge is a mistake. Theother-extensionsfield allows the extensions used in some modules (i.e. with theLANGUAGEpragma) to be listed. Cabal will eventually enforce that they are all listed, just like it requires that all package dependencies are listed. Language dependencies are dependencies too.根据 Hackage 文档，从 Cabal-1.8.0.6 开始，无法识别
DeriveFunctor。它是 GHC 的一个相对较新的补充，并且似乎没有广泛使用，所以我并不惊讶它会被 Cabal 忽视。这可能应该作为针对 Cabal 的错误（功能请求？）提交。@Tom Lokhorst 是对的，语言编译指示是最好的选择。我不喜欢使用 Cabal 的扩展字段，因为这样所有扩展都对所有模块都有效，这是我通常不想要的。
According to the Hackage documentation, as of Cabal-1.8.0.6
DeriveFunctoris not recognized. It's a relatively new addition to GHC and it doesn't seem to have wide use, so I'm not surprised it would have been overlooked for Cabal. This should probably be filed as a bug (feature request?) against Cabal.@Tom Lokhorst is right that a LANGUAGE pragma is the best option. I don't like using Cabal's Extensions field because then all extensions are active for all modules, which I often don't want.