独断と偏見で語るGHCのderiving系拡張 - Qiita
先日のHaskell Dayでderivingに関する発表があった Haskell Day 2019を開催しました！ aiya000, 「しんさんきぼう」のDerivingストラテジー ので、触発されて私もderivingについて思うところを書いてみます。主にderiving系拡張の落とし穴・注意点に重点を置きます。 標準でderiveできるやつ、またはGHCに組み込まれているやつ (stock deriving) 標準で Eq, Ord, Enum, Bounded, Show, Read, Data.Ix.Ix がderiveできます。この手の話題で Ix はよく見落とされます。ちゅうか Haskell 2010 Language Report, Chapter 11 のderive可能なクラスの一覧からもオミットされている……。 GHC拡張を有効にすることで、他のいくつかのクラスでも
Algorithmically Scrapping Your Typeclasses :: Reasonably Polymorphic
I’ve been working on a simple Haskell98 compiler over the last few days, partly as an excuse to learn how it works, and partly to have a test-bed for trying out some potential language extensions. More on that in a future blog post. As of yesterday, I have typeclass resolution working. The algorithm to desugar constraints into dictionaries hasn’t been discussed much. Since it’s rather involved, an
Haskellの1 == "x" が違法だなんて誰も言ってない！ - Qiita
前提 例えばJavaを例に上げると、全てのclassはObjectを継承しており、Objectがequalsメソッドを持つので 異なる型を比較（equals）できてしまいます。 class Foo {} class Bar {} public class Test { public static void main(String[] args) { System.out.println(new Foo().equals(new Bar())); } } // {output} // false これはインスタンスをアップキャストしたい際などには便利ですが、 私個人としては「ある値x,yが異なる型を持てば同じものではない（x != y）」というものを認めた方が 誤りが発生しにくいと考えています それをおおよそ認めたとも捉えれられる言語の１つとしてHaskellがあります Haskellは異な
Scrap your type classes
Edit: My opinion on type classes has mellowed since I wrote this post, but I still keep it around as a critique against the excesses of type classes. What I'm about to propose is that all Haskell type class programming can (and should) be implemented purely at the value level using a simple and ordinary code transformation. The trick is simple and I will begin by transforming the Monad type-class.
Explicitly import instances
How do I explicitly import typeclass instances? Also, how do I do this with a qualified import? Currently, I'm doing import Control.Monad.Error () to import the monad instance that I can use for (Either String). Previously, I used import Control.Monad.Error I'm not satisfied with either one, because the Monad instance is implicitly imported.
Haskellの型クラスを活用する - モナドとわたしとコモナド
Haskellの型クラスは、うまく使えば高いパフォーマンスと抽象度を両立できる、優れた仕組みである。その使い方のコツは、決して理解の難しいものではない。 小さな性質、大きな恩恵 プログラマは大きなものを小さく見せがちだ。オブジェクト指向プログラミングに慣れている人がやりがちなアンチパターンとして、欲しい機能と、それを分割する基準が現実に寄りすぎていて、一つ一つが巨大というものがある。 普通のプログラミングではありえない例かもしれないが、たとえば家を作りたいことを考える。「ベッド」「箪笥」「台所」「冷蔵庫」「トイレ」「風呂」のように設備ごとに分けた抽象化をしたいと考えるだろう。確かにこれは理に適っているように見える。だが、これらの設備を型クラスでまとめるのは悪手だ。 風呂やトイレには水を利用できるという性質が、冷蔵庫には電気が必要だ。部屋と部屋は壁で仕切られ、場合によっては扉があるかもしれな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
concurrency and Performance
Type-checking plugins, Part II: GHC's constraint solver
haskell 型クラスのデフォルト型
Inspecting Haskell Instance Resolution
simplifying-typeclasses
GitHub - matt-noonan/lawful: A constraint to assert that your typeclass instances are lawful