建议导出机制哈斯克尔

Question

我很抱歉，如果这个问题似乎病了深思熟虑的，但我不知道是否有可能定义一个一致的语义类似下面哈斯克尔：

derive Num String from Int where 
    get = read 
    set = show 

derive Ord Bool from Integer where 
    get = fromEnum 
    set = toEnum 

derive (Monad, Functor) Maybe from [] where 
    get (Just x) = [x] 
    get Nothing = [ ] 
    set [x]  = Just x 
    set [ ]  = Nothing 

我没有理由不这样做，在某些情况下它似乎会减少样板，但我不知道是否（如果是这样，多么容易）这可以实施。

编辑：

我的意图是为例如，第一个例子被替换为这样的东西：

instance Num String where 
    get = read :: String -> Int 
    set = show :: Int -> String 
    a + b = set $ get a + get b 
    a * b = set $ get a * get b 
    ... 

Answer 1

你在这里描述的基本上是通过同构定义类实例。这明显可以通过定义get和set函数来实现，但我们将其称为to和fro，以便更清楚一点。

toSI :: String -> Integer 
fromSI :: Integer -> String 

instance Num String where 
    a + b = fromSI $ (toSI a) + (toSI b) 
    abs = fromSI . abs . toSI 
    ... 

这些确实是很容易的定义写，有可能是通过在(to, fro)自动升降类的实例，但这个系统必须认真遵循许多规则，为了不污染全局类型类减少样板一些价值实例空间与垃圾。

特别是，我们可能会问(to, fro)形成一个同构。这意味着在双向往返是身份。换言之，这意味着给定任何整数n，我不应该能够通过任何方式区分(froSI (toSI n))与n（好吧，有些东西，比如计算速度会被忽略）。此外，我必须拥有的任何字符串s：toSI (froSI s)必须与n无法区分。

第二个明显失败，因为"I am not a number!"在该往返中抛出错误。有很多原因为什么在纯代码中抛出错误是危险的，而且类型类危险会继续并污染任何曾经导入代码的人的代码。

您可能会指出，这只是因为并非所有字符串都是有效数字。好像fromSI . toSI总是麻烦，但toSI . fromSI应该工作。也许它只影响像例化instance Num String这样的东西，而如果我们改为使用我们的(toSI, froSI)对来推导instance的Integer那String我们会处于一个好位置。 也许吧。

让我们试试吧。 String是Monoid一个实例，看起来像这样

instance Monoid [a] where  -- if a ~ Char then this is String 
    mempty = [] 
    mappend as bs = as ++ bs 

如果我们通过mappend = toSI . mappend . fromSI实施mappend它为我们提供了“串联整数”像

(1 <> 2) <> 3 == 123 
1 <> (2 <> 3) == 123 
(0 <> 1) <> 1 == 11 
0 <> (1 <> 1) == 11 

，如果我们仔细定义"" -> 0而不是使它失败，那么我们也可以得到一个有用的mempty。

mempty = toSI mempty 

这似乎应该工作得很好。它真的是IntegerInteger继承其“单向同构”与String（想想为什么我必须在这里使用Integer，而不是Int）。更具体地说，我们无法通过从Monoid类型类中的函数构建的任何测试来区分toSI (fromSI n)和n，所以它足够“足够”来进行此映射。

但是后来我们碰到了另一个问题。 Integer已经有一个Monoid实例。它已经拥有了其中的约10％，最流行的是乘法和加法

instance Monoid Integer   instance Monoid Integer 
    mempty = 0      mempty = 1 
    mappend = (+)      mappend = (*) 

所以，我们通过挑选这些情况中的任何一个是规范类型类的实例含半幺群失去了大量的信息。 Integer通过它的“单向同构”（又名“缩回”）与String变成Monoid更加准确，但也可以通过剥离来增加，但也可以通过剥离来增加乘法。

我们真的要保持信息的周围这就是为什么Monoid包定义之类的东西Sum和Product这表明该Integer一直专注于只使用其Addition性能。

就是这样，在一天结束时，您完全可以解决类型实例超出同构的问题。通常情况下，类型具有很多可以以这种方式滥用的同构和缩进，并且很难有真正的规范，守法的实例。当你找到一个代码时，通常值得把代码税明确写出来，即使你最终使用同构来完成。

当没有你有一个像newtype文书规范的选择和库的快速访问哪些只是“下面”你newtype层全部从普通GeneralizedNewtypeDeriving扩展出路的Control.Newtype package或直接启发Iso, au and auf摆和整个Wrapped, ala, alaf机制lens。

本质上，这个机制是为了让它更容易地讨论各种同构，特别是那些由newtype诱发的实例。