タグ

Haskellに関するMagicantのブックマーク (24)

  • HaskellとRustを足して2で割ったような関数型言語Fixを作っている話 - Qiita

    はじめに ここ1年ぐらいかけて、Fixという名前のプログラミング言語を作っています。 コアとなる機能の実装がある程度落ち着き、実際にFixを使ってプログラムを書けるようになってきたので、そろそろ言語の紹介をしてみようと思います。 記事はFixのチュートリアルではなく、どういう思想で設計されていて、どういう特徴を持つ言語なのか、という点を紹介するものです。 意見・提案・助言などをいただけるとうれしいです。 リポジトリはこちらです。 ※ コメントやコミットメッセージは一応拙い英語で書いていますが、日語でissueを立てたりdiscordで意見・質問してもらっても大丈夫です。 ※ 急いで作った部分もあるため、コンパイラのコードは結構汚いです。ご容赦ください。 現状、Fixをローカルで実行するためにはLLVMのインストールが必要で時間がかかりますが、Fix playgroundを使えばブラウザ

    HaskellとRustを足して2で割ったような関数型言語Fixを作っている話 - Qiita
  • 10年間使ってみて見えたHaskellの闇と光 - Qiita

    はじめに わたしがHaskellを使い始めてもうそろそろ10年目になります。(タイトルは多少サバを読んでいますね) これまで使ってきた感想をまとめます。 Haskellのつらいところ まずは愚痴らせてください。 コンパイルが遅い 依存モジュールはすべてソースコードからビルドする必要があります。(バイナリ形式のモジュールはありません) 最初のビルドに20分くらい待つのはザラです。 複雑な型システムをつかうと型推論や型レベル計算に時間がかかります。 高速なHaskellプログラムを書くためには多くの関数をインライン化する必要があります。最適化ビルドではインライン展開によってコードサイズが大きくなるので時間がかかります。 デバッグが難しい 公式のGHCiデバッガはありますが、今のところIDEから簡単に利用できるわけではないですし、コンパイル済みのライブラリはデバッグできないです。 近年スタックト

    10年間使ってみて見えたHaskellの闇と光 - Qiita
    Magicant
    Magicant 2021/03/19
    「残念ながらHaskellがRustのような成功を収めることは今後もないでしょう」に Haskeller の悲哀を感じる
  • Haskellでフィボナッチ数列 〜Haskellで非実用的なコードを書いて悦に入るのはやめろ〜 - Qiita

    -- 素朴なコード fib :: Int -> Integer fib 0 = 0 fib 1 = 1 fib n = fib (n - 2) + fib (n - 1) 数学的な定義をそのまま書き下した、Haskellらしい美しいコードですね! ……なーんて感想を抱いた人はHaskell初心者です。計算機で動かすコードを「数学的な美しさ」で語ってどうするんですか??? 美しいバラにはトゲがあるように、美しいHaskellコードには罠があります。 この「素朴なコード」は非常に遅く、実用に耐えません。(この素朴なコードの出番があるとしたら「遅いコードの例」としてでしょう) 素朴なコードの問題点 例として、「素朴なコード」で fib 4 を計算してみましょう。 fib 4 = fib 2 + fib 3 = (fib 0 + fib 1) + fib 3 = (0 + fib 1) + fib

    Haskellでフィボナッチ数列 〜Haskellで非実用的なコードを書いて悦に入るのはやめろ〜 - Qiita
  • haskell - What's a space leak? - Stack Overflow

    Magicant
    Magicant 2018/07/07
    スペースリークの難しさを端的に示す例
  • これからのHaskellプロジェクトではcabalではなくpackage.yaml(hpack)を使いましょう

    sol/hpack: hpack: An alternative format for Haskell packages hpackとは hpackとは, cabalファイルを生成してくれるツールです. package.yamlファイルからcabalファイルを生成します. JavaScriptに対するAltJSのようなものです. hpackは何が良いのか yamlである hpackのフォーマットであるpackage.yamlyamlフォーマットです. 独自のフォーマットを採用しているcabalとは違い, 様々なエディタが普通に対応しており, プログラムからも扱いやすくなっています. ボイラープレートを自動生成してくれる default-language: Haskell2010のような現代では当たり前の記述を自動生成してくれるため, わざわざ書かなくて済むようになります. exposed

    これからのHaskellプロジェクトではcabalではなくpackage.yaml(hpack)を使いましょう
  • Haskellライブラリ所感2016 - syocy’s diary

    (これは Haskell Advent Calendar 2016 の7日目の記事です) 今年使ったり調べたりした Haskell ライブラリを広く紹介していく企画です。 あくまで今年使ったものなので新しいものばかりではないです。 また記事の性質上、紹介するものが偏っていてもご容赦ください。 Hackage にはすごい数のライブラリが登録されていて、 頼もしいことですが目が回りそうにもなってしまいます。 この記事が Haskell のライブラリを調べる上での指針になったら幸いです。 なおこの企画と方向性が似ているものとして State of the Haskell ecosystem ( 2016年2月版 ) があります(英語)。 これは Haskell を取り巻く環境を知る上で非常によいドキュメントです。 ただ各ライブラリについては名前を挙げるだけにとどめられています。 この記事ではもう

    Haskellライブラリ所感2016 - syocy’s diary
    Magicant
    Magicant 2016/12/07
    有名なライブラリーのまとめ
  • StrictData拡張について - Qiita

    Haskellプログラマーなら誰でも経験するスペースリーク。 そして、スペースリークを経験したHaskellerは、おとなしくHaskellを捨て遅延しない言語を使うか、全部バングパターンなり、不自然なパターンマッチなりを意識的に何でも書いていくようになるのだった。。。という時期がHaskell世界にはありました。 GHC8で大きく正格評価サポートが入りました。具体的には、Strict拡張とStrictData拡張です。果たして、これでHaskellerは平穏を取り戻せるのでしょうか!? まあ、それはおいといて、今回はそもそもなぜこの拡張が必要なのか、そしてAdventCalendarらしく(僕の実力が足りないので)ゆるふわにStrictData拡張について紹介したいと思います。 多くのデータコンストラクタにはサンクを渡す必要はない 以下のようなデータについて考えてみます。

    StrictData拡張について - Qiita
    Magicant
    Magicant 2016/12/06
    Haskell がデフォルトで遅延評価するのは筋が悪いと何となく思ってゐたので、やっぱりかういふ機能出てくるよね といふ感想
  • 入門的ではない型クラスの話:Haskellの型クラスがぁ (´^`;) - 檜山正幸のキマイラ飼育記 (はてなBlog)

    タイトルに「入門的ではない」と入れたのは; 先日の「関数型プログラミングとオブジェクト指向について、何か書く、かも」において、「型クラス入門」の記事を書くかもと予告じみたことを言ってしまったので、その入門じゃないぞ、と。でも、型クラスの話だぞ、と。そういう意味合いです。ヨロシク、アシカラズ。 型クラスの元祖はHaskellです。なので、「型クラス = Haskellの型クラス」という前提での解説が多いみたいです。しかし、元祖は“最初の試み”であるがゆえに、使用経験や後発の理論を活かすことが出来ず、むしろ問題をかかえていたりします。Haskellの型クラスも、なんだか残念なところが。 内容: オーバーロードと人生 型クラスは何がうれしいのか(オーバーロードなしでも) 型クラスの実際 記号の乱用の実装法 Haskellの型クラスは何がマズイのか オーバーロードと人生 型クラス誕生の動機は、演算

    入門的ではない型クラスの話:Haskellの型クラスがぁ (´^`;) - 檜山正幸のキマイラ飼育記 (はてなBlog)
  • なぜHaskellを学ぶと良いか - Qiita

    なぜこれを書くのか 私がQiitaに投稿した記事を見た方から、メールが届きました。 プログラミング言語のHaskellを勉強し始めたものの、難しくてやめようかと考えているそうです。 その気持ちも非常によく分かります。 すごいHが出版されてから年月も経ち、それなりに勉強しやすくなったとはいえ、お世辞にもHaskellを学ぶ環境が整っているとは言えません。 私はHaskellで製品開発をする会社を保守運用していたことがあり、また自分自身もHaskellでプログラムを書いています。 また、Haskellを普及させるべく、「こわくないHaskell入門」という記事を書いたこともあります。 これらの経験を踏まえ、この機会にあらためて「なぜHaskellを学ぶと良いか」についてまとめたいと思い立ちました。 Haskellについてまだよく知らない方が、入り口として読める内容を目的としているので、できる

    なぜHaskellを学ぶと良いか - Qiita
  • Literate programming is a terrible idea

  • 翻訳:Haskellと過ごした4年間〜ファウンダーの観点から〜 - Qiita

    BetterというEラーニングの会社をやっていたCarl Baatzさん表題のような記事を書いていて、とても有益だと思ったので訳してみました。 だいたい逐語訳ですがところどころ意訳したり端折ったりしてます。プロの翻訳家ではないので間違いもあるかと思います。ご了承ください。不安なところは原文をご参照頂ければと。自信ないところは括弧に原文を残しているので、よい訳があれば編集リクエストお願いします。あと脚注も Thank you Carl for sharing great experince and knowledge! 原文: A founder's perspective on 4 years with Haskell http://baatz.io/posts/haskell-in-a-startup/ [追記] InfoQでもこの記事が取り上げられていました。 製品開発においてHask

    翻訳:Haskellと過ごした4年間〜ファウンダーの観点から〜 - Qiita
  • http://blog.ezyang.com/2014/07/type-classes-confluence-coherence-global-uniqueness/

    Magicant
    Magicant 2016/07/14
    分割コンパイルのために型クラスのインスタンスの一意性が保てなくてつらいといふ話
  • 目指せワンライナー! 〜 1行コードでがんばる 〜 - Qiita

    これはHaskellアドベントカレンダー2015の(2日遅れの)8日目の記事です。 当にすみませんでした。 導入 小さな部品(関数)を組み合わせて大きなプログラム(関数)を作り上げる、これこそが関数型の醍醐味かなと思います。 しかもHaskellは標準関数も豊富で、それらを糊付けする手段も豊富です。上手くやればプログラム全体を1行で書き上げてしまうことも可能なんじゃないでしょうか。夢がありますよね。 そんなわけで、Haskellにおいて1行(ワンライナー)コードを書くための指針をまとめます。 メリット まずはワンライナーのメリットをおさらいです。 いちいち関数名や変数名を考えずに済む ワンライナーコードは他のワンライナーのパーツとして容易に組み込める 1.について、 いちいち細かな関数に分けて別々に記述していると、それだけ名前を考える必要がありますね。 正直、英語よく分からないし、名前を

    目指せワンライナー! 〜 1行コードでがんばる 〜 - Qiita
    Magicant
    Magicant 2015/12/11
    頭の体操にはなるだらうが保守性が落ちるので、名前を考へるのがめんどい程度の理由でコードを短く詰め込むのは良くない。
  • スペースリーク、その傾向と対策

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

    スペースリーク、その傾向と対策
    Magicant
    Magicant 2015/12/08
    かういふの見てるとスペースリークを論理的に考察したくなってくる
  • 安定結婚問題を解きながらHaskellプログラミングを紹介しつつ恋愛について学ぶ - Qiita

    問題 n人の男性とn人の女性がいて,男性も女性もそれぞれ異性に対して明確な順序づけができる好みを持つとする. nは2以上の有限な自然数. 男性と女性がペアを作る問題を考えるが,このときに安定マッチング(不安定対がないようにマッチング)せよ. 安定マッチングというのは次の条件を満足するもの. そのマッチングを構成するあるペアとは異なるペアを組んだときに,新しいペアの2人がともに元のペアより好ましい相手を得る場合,もとのペアは安定ではない(不安定対).そのようなペアがないようなマッチングが安定マッチング. 不安定対というのは要は他に好き同士がいるので,今の相手との組(関係)は壊れやすいものだと思えばよさそう. Gale - Shapley のアルゴリズム この問題にはGale-Shapleyのアルゴリズムというのが知られている. Shapley先生というのは2012年にノーベル経済学賞を受賞さ

    安定結婚問題を解きながらHaskellプログラミングを紹介しつつ恋愛について学ぶ - Qiita
  • Stackでやる最速Haskell Hello world! (GHCのインストール付き!) - Qiita

    昨日第23回Haskellもくもく会 @ 朝日ネットで初めてstackを触ったのですが、 あまりにも簡単・高速にパッケージ作りの準備ができたので、やったことを共有したいと思います。 GHC(Haskellの最も有名なコンパイラ)のインストールまでやってくれるので、これからHaskell始めます!みたいな人にもオススメです。 stack自体が何かは @tanakh さんのHaskellのビルドツール"stack"の紹介をご覧ください。 一言で言うと「GHCのインストールからパッケージのインストールにビルドまで、ワンストップでやってくれる神ツール」ですかね。 各OSごとに微妙に違うみたいなので、公式ページの解説をご覧ください。 とはいえ、基的には実行ファイルをPATHのどこかに置くだけなので、この手の作業に慣れている人には朝飯前でしょう。 1ファイルだけでインストールできちゃうのも魅力ですね

    Stackでやる最速Haskell Hello world! (GHCのインストール付き!) - Qiita
  • 継続モナドによるリソース管理 - Qiita

    継続モナドって何に使うんだ問題に対する一つの例。 リソース管理の問題 プログラミングをやっていると必ずまとわり付いてくるのがリソース管理の問題です。ここで指すリソースというのは、ファイルのハンドルだとか、ソケットだとか、排他処理のためのロックだとか、グラフィックのハンドルだとかそういう話で、GCのない言語だとメモリの管理もこれに含まれるでしょうか。 言うまでもなく、リソースを確保した後はしかるべきタイミングで確実に解放してやる必要があります。しかし往々にして、現実のプログラムではリソースの解放漏れが発生してしまいます。単に解放するコードを書き忘れると言うのが一番単純でしょうもない理由ですが、それでも、C言語のようにリソース解放のための特別な仕組みを持たない言語では、これを徹底するのも結構骨の折れることだったりします。それはともかく、もう少し高尚な悩みとしては、例外との組み合わせで発生する解

    継続モナドによるリソース管理 - Qiita
    Magicant
    Magicant 2015/06/22
    ネストが「深く」ならないのは偏に do 記法のお蔭ですがね
  • Why free monads matter

    Interpreters Good programmers decompose data from the interpreter that processes that data. Compilers exemplify this approach, where they will typically represent the source code as an abstract syntax tree, and then pass that tree to one of many possible interpreters. We benefit from decoupling the interpreter and the syntax tree, because then we can interpret the syntax tree in multiple ways. For

  • 正格性解析 (Strictness Analysis) - ヒビルテ(2010-12-28)

    λ. 正格性解析 (Strictness Analysis) この記事はHaskell Advent Calendarのために書かれたものです。(22日目) 正格性解析(strictness analysis)は、Haskellのような遅延評価を行う純粋関数型言語での最も基的な最適化のひとつの割に、あまり知られていないようなので、簡単に紹介してみることに。 動機 よくある例だけど、末尾再帰で書かれた sum' :: Int → [Int] → Int sum' s [] = s sum' s (x:xs) = sum' (s+x) xs というプログラムは、Haskellでは最適化が行われない限り悲惨なことになる。 sum' 0 [1,2,3,4] を計算すると、sum' 0 [1,2,3] ⇒ sum' (0+1) [2,3] ⇒ sum' ((0+1)+2) [3] ⇒ sum' (

    正格性解析 (Strictness Analysis) - ヒビルテ(2010-12-28)
  • The Typeclassopediaを訳しました, The Typeclassopedia - #3(2009-10-20)

    ■ [Haskell] The Typeclassopediaを訳しました The Monad.ReaderのIssue 13に掲載されたThe Typeclassopediaという記事が、Functor, Monad, Monoid, Applicative, Foldable, Traversable, Arrowといったような型クラスについて良くまとまっていて、そのあたりを知りたい時の取っ掛かりになりそうだったので翻訳してみました。 作者のBrent Yorgeyさんからも許可がいただけたので公開します。翻訳に慣れていないので変な日語(特に専門用語の日語訳はかなり怪しい)があったり、そもそも間違っていたりするかもしれませんので、何か見つけたらコメントを頂けると助かります。 ■ [Haskell] The Typeclassopedia by Brent Yorgey <first