类型同义词对类型类实例的影响是什么？GHC中的TypeSynonymInstances pragma有什么作用？

Question

我正在读真实世界Haskell Pg 151,我已经盯着下面的一段时间了一个多小时:

回想一下,String是[Char]的同义词,而Char又是类型[a],其中Char代替了类型参数a.根据Haskell 98的规则,在编写实例时,我们不允许提供类型代替类型参数.换句话说,为[a]编写实例对我们来说是合法的,但对于[Char]则不是.16条评论5335

它只是没有下沉.盯着RWH第6章的(免费盗版)副本,我看到很多其他人真的很痛苦.我仍然不明白这些评论......

首先,关于这一切的一切让我感到困惑,所以如果你觉得你可以解释这段经文的任何事情,TypeSynonymInstances请你做.

这是我的问题:

• Int是一个数据构造函数
• String是数据构造函数 AND 类型同义词

现在我无法回答这些问题:

1. 为什么类型同义词会排除使类型成为类型类的成员(我正在寻找可能与类型同义词的编译或实现相关的某些原因)？
2. 为什么语言的设计者,不想要这种语法(我要求推理不是广泛的理论或unicode数学符号).
3. 我看这条线"其中字符替换了类型参数的类型[A]",我想知道为什么我不能用它替换此"的类型,其中INT是代替类型参数".

谢谢!

Answer 1

我认为问题的一部分是两个很大程度上不相关的限制在起作用:

• 没有类型同义词实例意味着实例只能是使用dataor newtype而不是声明的事物type.这禁止String,但不是[Char].
• 没有灵活的实例意味着实例只能提到一个不是变量的类型,只有那个类型可以用作类型构造函数.这种禁止Maybe Int和f Int,但不会Maybe a.

下面是GHCI说,大约Int,Char以及String:

data Char = GHC.Types.C# GHC.Prim.Char#
data Int = GHC.Types.I# GHC.Prim.Int#
type String = [Char]

Int并且Char都是没有类型变量参数的简单类型; 没有涉及类型构造函数,因此您可以非常自由地使用它们创建实例.

但是,String在两个方面都失败了.它是一个类型的同义词,这是不允许的,它也是一个应用于非变量的类型构造函数,即应用于Char的列表类型构造函数.

为了便于比较,注意[a],Maybe a和Either a b在所有情况下有效,但是[Int],Maybe [a]和Either String a是被禁止的; 希望你现在能明白为什么.

至于你的直接问题,我不知道用这种方式设计语言的原始动机是什么,而且我没有资格做出关于"最佳实践"的权威性陈述,但对于我自己的个人编码,我不知道我真的很犹豫使用这些pragma:

{-# LANGUAGE GeneralizedNewtypeDeriving #-}
{-# LANGUAGE EmptyDataDecls #-}
{-# LANGUAGE TypeSynonymInstances #-}
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE FlexibleContexts #-}

你总是可以去看看使用pragma的包.似乎灵活的实例确实得到了相当多的使用,并且来自"可敬的"软件包(例如,Parsec的源代码中有几个点击).

Answer 2

实际上,既不是数据构造函数Int也不String是.也就是说,您无法使用它们来创建值

> (Int 42, String "bob")
<interactive>:1:1: Not in scope: data constructor `Int'
<interactive>:1:9: Not in scope: data constructor `String'

Int命名一种新的,不同的代数数据类型.String是现有类型的"类型同义词"或别名:[Char].问题是Haskell 98说你不能在实例声明中使用类型同义词.

我不能说为什么Haskell 98报告的作者在这种情况下选择限制类型同义词.它们有很多限制.例如,它们不能被部分应用(如果它们采用类型参数).我认为§4.2.2结尾处有一条线索:

类型同义词是一种方便但严格的语法机制,可使类型签名更具可读性.除了实例声明的实例类型(第4.3.2节)之外,同义词及其定义是完全可互换的.

据推测,有一种程序编译方法,这种语法可互换性会导致实例出现问题.也许它与它们从包中漏出的实例的显着方面有关...

至于你的最后一个问题,我认为解释是两个事情:1)String是一个类型的同义词[Char],它反过来是一般类型的特化[a]和2)即使没有同义词,[Char]也不能用于头部一个实例.

第二个问题与类型同义词无关,但是实例头必须将类型构造函数的所有类型参数都设置为变量,而不是具体类型.也就是说,你不能定义单独的实例[Int]和[Char]一些类,你只能定义一个实例[a].(请记住,尽管方便的语法,[]是一个类型构造函数,里面的东西是类型参数.)

同样,我不知道为什么报告会限制这些,但我怀疑它也与编译策略有关.由于GHC的实例编译策略可以处理这个问题,你可以通过GHC放宽这个约束-XFlexibleInstances.

最后,我已经看到两个扩展都在相当多的代码中启用,但也许具有更多Haskell经验的人可以权衡它们是否是"最佳实践"或不是.