24

私はかなり長い間Haskellを使っています。使うほど、その言語に恋をします。私は自分の人生のほぼ15年を他の言語を使って過ごしたとは信じられません。

しかし、私はゆっくりと、しかし着実に、Haskellの標準ライブラリにうんざりしています。私の主な愛玩動物は、「十分に多型ではない」定義（、、Prelude.mapなどControl.Monad.forM_）です。最初の行が次のようになっているHaskellソースコードファイルがたくさんあります

{-# LANGUAGE NoMonomorphismRestriction #-}

module Whatever where

import Control.Monad.Error hiding (forM_, mapM_)
import Control.Monad.State hiding (forM_, mapM_)
import Data.Foldable (forM_, mapM_)

{- ... -}

importどの定義を非表示にするかを絶えず混乱させないようにするために、このボイラープレートを管理可能な単位にラップする単一または少量のソースコードファイルが必要です。

それで...

  1. 他の誰かが以前にこれをやろうとしたことがありますか？
  2. 前の質問に対する答えが「はい」の場合、結果のボイラープレートラッピングソースコードファイルを投稿しましたか？
4

1 に答える 1

9

あなたが想像するほど明確ではありません。私は頭のてっぺんから考えることができるすべての不利な点をリストします：

まず、これらの関数が取得できる一般性に制限はありません。たとえば、現在、通常の型を含むインデックス付き型のライブラリを作成しています。あなたが言及したすべての関数には、より一般的なインデックス付きの同等のものがあります。誰もがすべてのために私のライブラリに切り替えることを期待していますか？いいえ。

別の例を示します。mapM関数は、クライスリ圏のファンクターの法則を満たす高階ファンクターを定義します。

mapM return = return
mapM (f >=> g) = mapM f >=> mapM g

したがって、トラバース可能な一般化は間違っていると主張できます。代わりに、高階関数クラスのインスタンスとして一般化する必要があります。

また、すべての例を含むこれらの高階クラスと関数のいくつかの例については、category-extrasパッケージを確認してください。

パフォーマンスの問題もあります。これらのより専門的な機能の多くは、パフォーマンスを劇的に向上させる非常に細かく調整された実装を備えています。クラスは、よりパフォーマンスの高いバージョンを許可する方法を公開する場合もありますが、そうでない場合もあります。

型クラスのオーバーロードの問題もあります。利便性よりも理論から導き出された健全な法則がない限り、私は実際には型クラスの使用を最小限に抑えることを好みます。また、型クラスは一般に単相制限でうまく機能せず、アプリケーションコードのシグネチャなしで関数を書くことを楽しんでいます。

味の問題もあります。多くの人は、Haskellの最高のスタイルが何であるかについて単に同意していません。プレリュードについてはまだ同意できません。そういえば、新しいプレリュードを書く試みはたくさんありますが、誰も何が最善かについて合意できないので、とにかくデフォルトでHaskell98に戻ります。

しかし、物事を改善するという全体的な精神は良く、進歩の最悪の敵は満足であると思いますが、すべてを行うための明確な正しい方法があるとは限りません。

于 2012-06-18T14:36:02.753 に答える