タグ

ブックマーク / kazu-yamamoto.hatenablog.jp (7)

  • GHCのIOマネージャの歴史と僕の苦悩 - あどけない話

    これは、Haskell Advent Calendar 2021 の8日目の記事です。 Haskellのコンパイラとして事実上一択となったGHCには、「軽量スレッド」が実装されています。軽量スレッドは、ネイティブスレッドよりも軽量なスレッドで、他の言語では「グリーンスレッド」とも呼ばれています。Haskellerが並行プログラミングをするときは、軽量スレッドを息を吸うかのように使います。 複数の軽量スレッドの入出力を束ねるのが、IOマネージャです。IOマネージャも単なる軽量スレッドであり、OSから入出力のイベントを受け取り、それぞれの軽量スレッドにイベントを通知します。 軽量スレッド(っぽい)機能を提供する他の言語では、GHCのIOマネージャを参考にしているようです。僕はIOマネージャの開発に深く関わっています。この記事ではIOマネージャの歴史をまとめるとともに、主にmacOSでの実装に関

    GHCのIOマネージャの歴史と僕の苦悩 - あどけない話
    Haaaa_N
    Haaaa_N 2021/12/13
    OSのバグつら
  • さようなら遅延評価 - あどけない話

    Haskellがとっつきにくい原因の一つに遅延評価がある。入門書では、無限リストと遅延評価がことさら強調される。しかし、Haskellを業務で使ってみると、遅延評価が煩わしくなってくる。遅延評価なしでもほとんどのことは実現できるし、メモリーの使用量は推測できないし、あまりいいことはない。 Haskellの評価戦略が、他の言語と同じように正格評価だったらよかったのに。 今まで、このようなセリフを何度聞いたか分からない。 そもそも遅延評価が役立つことはあるのだろうか? ある。お世辞抜きに、少なくとも以下の3つでは当に役立つ。 リスト(あるいは類似のデータ構造)処理 純粋性に対する暗黙のテスト 効率的なCAS 1.はよいだろう。2.は純粋さを守るために必要だが、コンパイラを開発する人にとって重要なのであり、ユーザには関係ない。3.は、並行プログラミングの奥義である。atomicModifyIO

    さようなら遅延評価 - あどけない話
    Haaaa_N
    Haaaa_N 2019/02/19
    でもリストは遅延評価じゃないと困るな…と思ったけどモジュール単位だから自分のモジュールは正格評価前提で書いても別に良いのか
  • goな関数 - あどけない話

    これは「Haskell (その2) Advent Calendar 2017」の1日目の記事です。遅くなってすいません。 読者として末尾再帰ぐらいは理解しているHaskellerを想定しています。 トップレベルとローカル関数 再帰を用いて関数を書いているとき、トップレベルで再帰するか、ローカル関数で再帰するか、ときどき迷う。この記事では、僕なりの判断基準を示したい。 Data.Listで定義されている再帰が必要な関数は、ほとんどがトップレベルで再帰している。代表例のmapの例を見てみよう。 map :: (a -> b) -> [a] -> [b] map _ [] = [] map f (x:xs) = f x : map f xs mapをローカル関数を使う実装にしてみよう。この記事では、ローカル関数名としてgoを用いる。(loopを使う流儀もある。) map' :: (a -> b)

    goな関数 - あどけない話
    Haaaa_N
    Haaaa_N 2017/12/12
    まあ0みたいな固定値はローカルにしたいですよね
  • PatternSynonymsのススメ - あどけない話

    PatternSynonymsは、その名の通り、パターンの別名である。GHC 7.8.1 で導入された。GHC 7系のPatternSynonymsは、モジュール内に閉じて入れば何の問題もなかったが、モジュールの外へexportする際は、patternキーワードが必要であり、構成子らしくなかった。 {-# LANGUAGE PatternSynonyms #-} module A (Foo, pattern Zero) where newtype Foo = Foo Int pattern Zero :: Foo pattern Zero = Foo 0 GHC 8 からは、patternキーワードが不要となり、構成子らしくなった。 {-# LANGUAGE PatternSynonyms #-} module A (Foo(Zero)) where newtype Foo = Foo I

    PatternSynonymsのススメ - あどけない話
    Haaaa_N
    Haaaa_N 2017/09/20
    これ使ってpersistentへの対応を単なるTextにした方が良いのかもしれない
  • 重複したフィールドラベル - あどけない話

    Haskell 2010 では、同じファイルに重複したフィールドラベルを定義できない。たとえば、以下はエラーになる。 data Foo = Foo { same :: Int } data Bar = Bar { same :: Float } -- これはダメ この問題を解決する案は、OverloadedRecordFields と呼ばれ、苦難の歴史を持つ。実装があるにもかかわらず、 実装が一枚岩 コードの複雑になる割に利益が少ない などの理由により、GHC へはマージされずにいた。現在では、OverloadedRecordFieldsは、三つの拡張へと分割された: DuplicateRecordFields OverloadedLabels Magic type classes この中、1. と 2. が GHC 8.0 に入る。 DuplicateRecordFields Dupli

    重複したフィールドラベル - あどけない話
    Haaaa_N
    Haaaa_N 2017/09/10
    自動導出はいつになるだろう
  • 遅延評価と末尾再帰と余再帰 - あどけない話

    遅延評価では再帰の効率はどうなるかという問題です。Real World Haskell で、末尾再帰は重要だと言った後に、遅延評価では末尾再帰なんて気にするなとちゃぶ台を返しています。ようやく haskell-cafeで答えを見つけたので、Luke Palmer さんの許可を得て訳を公開します。 Luke Palmer さんの説明 私が Haskell でプログラミングするときは、通常関数を末尾再帰にはしません。(Int や Bool など)正格な値へ畳み込む場合、末尾再帰を使うのはよいことです。しかし帰納的な遅延構造を作成する場合、関係する用語は(私の記憶が正しければ)「余再帰」(corecursion)であり(訳注:mapは再帰かつ余再帰だそうですが、専門的すぎるので普通の再帰でいいと思います)、末尾再帰とはまったく異なります。 リストに対し末尾再帰で map する関数を例として考えま

    遅延評価と末尾再帰と余再帰 - あどけない話
    Haaaa_N
    Haaaa_N 2017/06/01
    @miliushin [遅延評価と末尾再帰と余再帰 - あどけない話]:
  • Real World Haskell の古いところ - あどけない話

    Real World Haskell の内容が古くなってきたので、どこが古いかとか、それに変わる新しいものは何とか、まとめたいと思う。 Real World Haskell―実戦で学ぶ関数型言語プログラミング 作者: Bryan O'Sullivan,John Goerzen,Don Stewart,山下伸夫,伊東勝利,株式会社タイムインターメディア出版社/メーカー: オライリージャパン発売日: 2009/10/26メディア: 大型購入: 8人 クリック: 245回この商品を含むブログ (76件) を見る 1章 始めましょう 今でも通用する。 2章 型と関数 今でも通用する。 3章 型を定義し、関数を単純化する 今でも通用する。 4章 関数プログラミング ghc に --make オプションはもう不要。 5章 ライブラリを書く 5.14節では、"runghc Setup build" の

    Real World Haskell の古いところ - あどけない話
    Haaaa_N
    Haaaa_N 2014/02/07
    読む予定なのでブックマークしておこう
  • 1