programming-languages - アンリフトタイプのデメリットは？

Question

Haskell では、持ち上げられた型積とは、(a,b,c) と (a, (b, c)) の間に意味的な違いがあることを意味します。

すべての製品のすべてのパターン一致が常に反駁できない場合、違いはなく、(a、b、c) は (a、(b、c)) の構文糖衣である可能性があります。

Haskell がリフト型製品を選んだ理由は?

Answer 1

Haskell がリフト型製品を選んだ理由は?

怠惰や反駁可能なパターンに訴えることなく、このデザインの選択を正当化できます。ポリモーフィズムをサポートするという理由で、同じ設計の選択が ML になります。検討

fst (x, y) = x
snd (x, y) = y

if(a, (b, c))が のシンタックス シュガーである場合(a, b, c)、どのように特殊fst化sndしてこの型を引数として受け取るかを理解するのは非常に困難です。しかし

fst :: (a, (b, c)) -> a
snd :: (a, (b, c)) -> (b, c)

完全に合理的です。fstやのようなポリモーフィック関数sndは信じられないほど便利なので、Haskell と ML の両方を使用すると、プログラマーは と を区別することが(a, (b, c))でき((a, b), c)ます(a, b, c)。

(コストを気にする人にとって、型構造は、型のサイズと、その要素を取得するために必要な間接参照 (ロード) の数の合理的なガイドでもあります。一部のプログラマーは、そのようなことについて知りたい、または知りたいと思っています。それらに対する小さな程度の制御。)

Answer 2

理由の 1 つは、unlifted product の実装にseqは並列/インターリーブ計算が必要でseq (a, b) TrueあることTrueです。についてどう感じるかによっては、この理由が非常に説得力があるとは思わないかもしれませんが、もちろんポリモーフィックは定義上、Haskell の一部です...abseqseq

Answer 3

必要に応じて、型クラスに関連してセマンティックの違いを生み出すことができます。

(a, b, c)(a, (b, c))クラスを異なる方法でインスタンス化できます。考えてみてください

show (1, 2, 3)

と

show (1, (2, 3))

両方が同じ出力を生成するのは直観に反すると思います。