タグ

haskellに関するpetite_blueのブックマーク (14)

  • Arrow syntax

    Hughes's original formulation of arrows used a point-free style, which is convenient for calculating general properties, but cumbersome for specific definitions. [Pat01] proposes to extend Haskell so that arrows are almost as convenient to describe as monadic computations. The new forms are defined by translation back to standard Haskell. Here's a simple example to illustrate the notation: addA ::

  • Haskell は Rust になれるのか?──2023年の Linear Haskell 体験記

    追記:いくらなんでもあまりにも長いので、配列演算に焦点を絞ってより「Rustっぽさ」の気持ちを強調した姉妹編を書きました。手っ取り早く雰囲気を掴みたい方はこちらもどうぞ。 TL;DR GHC 9.0 から Haskell に入った線型型(Linear Types)の機能を一部割とガッツリ使ってみたので、Linear Haskell の現在の使い心地と将来の展望を報告するよ。 使おうと思えば使える段階にあるけれど、一部バグもあるし、まだ言語機能面で実装が追い付いていない部分もあって、快適に書けるようになるにはもうちょっと掛かるよ。それでも実用しようと思えばできるレベルにあるよ。 RustのようになるにはLinear Constraintsに期待。 更新履歴 2023/12/15 11:45 姉妹編へのリンク追加。 2023/10/01 12:30 線型性を納得してくれない場合の \eta-展

    Haskell は Rust になれるのか?──2023年の Linear Haskell 体験記
  • Beautiful folding

    > {-# LANGUAGE ExistentialQuantification #-} > import Data.List (foldl') If you're not a Haskeller, and were thus hoping to learn how to fold a shirt beautifully, I'm afraid you're out of luck. I don't know either. Much has been said about writing a Haskell function to calculate the mean of a list of numbers. For example, see Don Stewart's "Write Haskell as fast as C". Basically, one wants to writ

  • A Tale of Two Functors or: How I learned to Stop Worrying and Love Data and Control

  • Haskeller の異常な愛情:または、生粋の Haskeller は転職して Rust を一ヶ月半書いて何を思うようになったか

    Haskeller の異常な愛情:または、生粋の Haskeller は転職して Rust を一ヶ月半書いて何を思うようになったか この記事は Jij Advent Calendar 2024、Haskell Advent Calendar 2024、およびRust Advent Calendar 2024シリーズ2 の18日目の記事です。 各カレンダーの前後の記事は以下の通りです: Haskell Advent Calendar 2024 前の記事: 次の記事:gotoki_no_joe さんの「集めるDPについて」 Rust Advent Calendar 2024 シリーズ2 前の記事:yasuo-ozu さんの「物のSpecializationをStable Rustで!」 次の記事:hyumanase さんの「Rust.Tokyo 2024 に初参加した」 Jij Advent

    Haskeller の異常な愛情:または、生粋の Haskeller は転職して Rust を一ヶ月半書いて何を思うようになったか
  • This FTP site

    Index Unless specified otherwise, all the code and the documentation on this site is in public domain Recent changes:  December 7, 2024 | RSS | Atom Computation fixpoints; Having an Effect; monads; programming as collaborative reference; effects without monads; Turing machines; Markov algorithms; R-technology; CK macros; generators vs. lazy evaluation; IO monad realized in 1965; grasping patterns;

  • Writerを使ってはならない - Qiita

    2022-05-20追記: mtl-2.3, transformers-0.5.6以降においてリークの起こらないCPS版Writerが提供されているのでそちらを用いてください: https://hackage.haskell.org/package/mtl-2.3/docs/Control-Monad-Writer-CPS.html https://hackage.haskell.org/package/transformers-0.5.6.0/docs/Control-Monad-Trans-Writer-CPS.html Writer Monadの問題点 Haskell スペースリーク アドベントカレンダーX日目(X ~ 360)です。 Writer Monadを使ってはならないという話があります。 理由は単純で、スペースリークが発生するためです。 以下の単純なアクションを評価してみま

    Writerを使ってはならない - Qiita
  • スペースリーク、その傾向と対策

    スペースリークの傾向とその対策を見ていきます。 ここでは3つのパターンを取り上げます。他のパターンがまだ見つかりそうな気がしているので、気がついた方は是非記事を書いてください。 注意事項 「サンクを積む」という表現を多用していますが、「関数適用によってサンクを大きくする」と言った意味合いで使っています。多分に誤用なので外では使わない方がいいと思います(と思ったらそういう表現を使うこともあるそうです) 以前の記事もそうですが、「簡約」は「評価」に統一してます 基方針 追記: 正格評価 無限ループをしない 必要ない式は評価しない 遅延評価 無限ループをしない 必要ある式はサンクを積まない サンクの必要とする空間と、潰した後の空間 サンクは必ずしも悪いものではありません。非常に大きなサンクの場合とそれを潰した場合に、どちらがメモリを消費するかは一概には言えないのです。 少し違いますが、わかりや

    スペースリーク、その傾向と対策
  • Freeモナド - haskell-shoen

    2013年、Extensible Effects: an alternative to Monad Transformersが発表された。ベースのFunctorを拡張可能バリアントにすることでさらにモナドを作りやすくし、しかも変換子のスタックよりも早くなるというものだ(実際のところ、ほとんどの場合遅くなる)。斬新なアイデアであることは間違いなく、世界中を沸かせた。 従来のFreeモナドは、>>=が左結合になっていると二乗オーダーで遅くなるという欠点を抱えていた。かと言ってCPS変換すると、ステップ単位での実行ができない。それに対するソリューションとして2014年、Reflection without remorseというアプローチが生まれた。これは、継続の列を結合可能キューに格納することによって、その弱点を克服するというものだ。しかし、そのキューは極めてオーバーヘッドが大きく、通常のFre

    Freeモナド - haskell-shoen
  • UTF-8のバリデーションとモノイドと半群

    この記事はUTF-8のバリデーションとオートマトンの続きです。 前回はUTF-8のバリデーションが8状態のオートマトン (DFA) で表現できることを見ました。状態と遷移を擬似コードで書けば次のようになるでしょう: -- 8つの状態 data State = START | TAILx1 | TAILx2 | TAILx3 | A | B | C | D -- 入力バイトに応じて次の状態を返す。次の状態が該当しなかったら Nothing を返す next :: Word8 -> State -> Maybe State +----+----+-----+----+ | a0 | a1 | ... | aN | 8ビット整数列 +----+----+-----+----+ | | | v v v +----+----+-----+----+ | m0 | m1 | ... | mN | モノ

    UTF-8のバリデーションとモノイドと半群
  • WebAssembly backend merged into GHC

    Tweag has been working on a GHC WebAssembly backend for some time. Recently, the WebAssembly backend merge request has landed in GHC, and is on course to appear in the upcoming 9.6 release series. This post will give a quick demonstration of how to try it out locally, and explain what comes in this patch and what will be coming next. Playing with WASM locally If you’re using nix on x86_64-linux, c

    WebAssembly backend merged into GHC
  • Levelsモナドを使った幅優先探索の仕組み

    Haskellは関数型プログラミング言語と呼ばれますが、関数だけでなく型も重要な役割を担っています。アルゴリズムを考える時、手続きの最適化だけでなく、正しいデータ型を選択することがシンプルなアルゴリズムを導き、実装をコンパクトにできるというのはよくある話です。今回は非常に単純な型でありながら幅優先探索というアルゴリズムのエッセンスを詰め込んだ Levelsというデータ型 について紹介したいと思います。 ピタゴラス数を列挙する ピタゴラス数とはピタゴラスの定理における関係式 a^2 + b^2 = c^2 を満たす自然数の三つ組です。 Haskellのリストは遅延評価なので 全ての自然数の三つ組を列挙する 列挙した自然数の中から関係式を満たすものだけ抽出する という手順でピタゴラス数を列挙することを考えてみましょう。 実際この方法は有限な探索範囲ではうまく機能します。 pyth :: [(I

    Levelsモナドを使った幅優先探索の仕組み
  • Haskell入門

    Skip to the content. Haskell入門 従来の言語では問題を部分化する方法について概念的な限界がいくつかある。関数型言語はこれらの限界を押し広げるも のである。 なぜ関数プログラミングは重要か 関数プログラミングを習得するには,これまで命令プログラミングで培った技術はいったん忘れ,真っ白な気持ちで臨む必要があります。関数型の山を登るためには,命令型の山を降りなければなりません。 第1章 関数プログラミングは難しくない! Haskellは理解すれば理解するほどきれいに書けることを約束してくれます。信頼してください 常にパターンを探しましょう。単純になるとき、またその時だけそれらを抽象化するのです 辛抱強く抽象化を正しく理解しましょう。もしそれが出来たならすべてのことが魔法のようにつじつまが合うようになるでしょう。 実装そのものが設計図となります … Haskell Ma

  • モナド教

    前提知識:モナド モナドを理解せずともモナド教を信ずることは出来ますが,理解していればより深く納得できるでしょう. 操作 :: 型 -> 型 は,"型"から"型"へ写す"操作"の存在を表します. モナドの文脈 m が必要とする2つの操作: return :: a -> m a で,値を保ちつつ文脈 m の中に入れ込むことが出来ます. (=<<) :: (a -> m b) -> (m a -> m b) で,「値を文脈に入った別の値へ写す操作」を「文脈に入った値を同じ文脈に入った別の値へ写す操作」に変換します. id :: a -> a は値をそのまま返す操作です. id を =<< で変換して得られる操作 join :: m (m a) -> m a で,二重に文脈に入った値を一重の文脈に入った値に戻すことが出来ます. 文脈の値から生の値を取り出す型 m a -> a を持つ操作は,一般

  • 1