Reddit で振り返る今年の英語圏 Haskell 界隈の話題 - Qiita
Haskel advent calendar 2023 の1日めの記事です． お仕事も情報系でなく，多忙を言い訳に数年ほとんどコード自体をかけていなかったのですが，最近 e-Gov 法令検索 で公開されている法令XMLを読みたい需要があって久しぶりに Haskell で書いてみたらやはり書きやすく，とても楽しくて改めて感動しました．書きながら自然に思考が整理される感じがよい． Hoogle は変わらぬ使いやすさでモリモリサポートしてくれるし，環境構築も GHCup などが噛み合って随分スムーズで，Haskell Language Server も成熟してきているようです．環境構築については，昨年の Advent Calendar の1日め @mod_poppo さんの記事 などが参考になります． 最近入った言語拡張にも，ちょっとだけコード書く位でも（大規模なあるいは高度なコードじゃなくても
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プロジェクトのベストプラクティス
Haskellプロジェクトの「良い習慣」と考えられるやつをまとめてみます。あくまで私の個人的な意見です。 プロジェクト固有のPrelude Prelude に相当するモジュールをプロジェクト独自に持っておくと便利ではないか、という話をします。代替Preludeの話ではありません。 プロジェクト固有のPreludeがあると便利な理由 理由の一つは、標準 Prelude の変化です。直近では次のような変化がありました： GHC 9.4: ~ 型演算子が追加（これまでは構文だった） GHC 9.6: liftA2 が追加 GHC 9.10（見込み）: foldl' が追加 もっと昔に遡ると、Semigroup((<>)) が増えるやつなどがありました。 この帰結として、 新しいGHCで名前の衝突が起きやすくなる 新しいGHCで「冗長なインポート」の警告が出やすくなる ことが言えます。これらの問題
Haskellの型システム(+拡張)を実装して学ぶ
導入 Mark P. Jones: Typing Haskell in Haskellという論文があります。この論文は、題通りHaskellでHaskellの型チェッカを実装するというものです。詳細な解説がされており非常にわかりやすく、また型システムの体系的な知識が無くても理解できるように構成されています。 しかしながら、この論文にはソースコードを入力にとって型チェックを行うまでに必要な実装の全ては含まれておらず、プログラムを入力に取って動作させるまでにはいくつかの変換や解析が必要です。Titan Type Checkerは、これら不足している機能(+拡張)を実装し、実際にスタンドアロンに動作する型チェッカを実装したものです。本記事では、論文で解説されていない事柄を中心に振り返りたいと思います。 Typing Haskell in Haskellの動作まで 構文解析 (Parser.hs)
執筆中：「Haskellでの型レベルプログラミング」 | 雑記帳
最近、「Haskellでの型レベルプログラミング」という「本」を執筆している。まだ完成ではないが、以下のリンクから読める： Haskellでの型レベルプログラミング なぜHaskellか 最近いろんな言語が出てきている中で、Haskellの強みとは何だろうか。人によって答えは色々あるだろうが、筆者にとってHaskellの魅力的な側面は強力な型システムである。どのくらい強力かというと、型レベルでプログラミングができ、依存型の模倣さえもできてしまう。 （依存型をやりたいなら最初から依存型のある言語を使えという意見は尤もだが、それはそれとして。） Haskellでの型レベルプログラミングの解説記事というのは、英語圏ではちらほら見かけるが、日本語圏ではあまり見ない。2018年（原文は2017年）に公開された Haskellにおける型レベルプログラミングの基本(翻訳) – Qiita が数少ない例で
関数型プログラミング言語における関数適用構文の歴史的経緯についてのメモ - Arantium Maestum
先日こういうツイートがあった： Haskellとかの関数型言語を使用しているプログラマの皆様にお聞きしたいんですけど、「関数名 引数 引数 ...」みたいな関数呼び出し構文って見にくくは無いですか？「関数名(引数, 引数, ...)」に慣れたこちらからすると、丸括弧が無いからコード中のどこが関数呼び出しなのかパット見で把握しにくい。— sounisi5011/プログラム (@sounisi5011Prog) February 22, 2022 「見にくくは無いですか？」と聞かれると、個人的には「全然大丈夫です」と答えざるを得ないのだが、次のツイートに関しては考えさせられた： 数式でも函数には丸括弧を使ってるのに、どこのタイミングで丸括弧が消失したのかわからないし、その選択をした理由も思いつかない。— sounisi5011/プログラム (@sounisi5011Prog) February
型安全で高速な連鎖行列積の計算
この記事は Haskell Advent Calendar 2021 の22日目の記事です。 次のような３つの行列の積を考えてみましょう。 ABC = \begin{pmatrix} a_{00} & a_{01} & a_{02} \\ a_{10} & a_{11} & a_{12} \\ a_{20} & a_{21} & a_{22} \\ a_{30} & a_{31} & a_{32} \\ \end{pmatrix} \begin{pmatrix} b_{00} & b_{01} \\ b_{10} & b_{11} \\ b_{20} & b_{21} \\ \end{pmatrix} \begin{pmatrix} c_{00} & c_{01} & c_{02} & c_{03} & c_{04} \\ c_{10} & c_{11} & c_{12} & c_{13}
GHC 9.2の新機能と、GHCの動向2021
Haskell Day 2021で「GHCの動向2021」というタイトルで発表しました、mod_poppoです。この記事では、発表の補足としてGHC 9.2の新機能の紹介と、 Data.List の単相化に関する補足を行います。 Haskell Day 2021の動画と筆者のスライドは、それぞれ次のリンクから参照できます： Haskell Day 2021 - YouTube GHCの動向2021 「GHCの動向」のタイトル的な元ネタ（？）は、筆者が3月にブログに書いた GHCに初めてコントリビュートした／最近のGHC動向 です。時代遅れになった記述もあると思いますが、よかったら読んでみてください。 GHC 9.2の新機能 2021年10月29日に、待望のGHC 9.2.1がリリースされました。公式の変更点は 2.1. Version 9.2.1 — Glasgow Haskell Com
Haskell に IDE はないのか？──独断と偏見による Haskell の IDE 十年史
答え：Haskell に IDE はずっとある、今ならHLS使え（内容を読む気がないようという人向けの答え） はじめに 2021年2月現在、Haskell の IDE 環境は Haskell Language Server (HLS) の登場により劇的な進化を遂げていますが、日本の Haskell コミュニティではその前身の Haskell IDE Engine (HIE) の情報がまだ氾濫しており、十分な周知に至っていない現状があります。 本稿では、こうした現状を打破すべく、2021 年 2 月現在の Haskell の IDE 環境を取り巻く現状と、そこに至るまでの歴史を完全に独断と偏見で紹介します。より多くの人に HLS の存在を周知し、皆さんの Haskell Life の一助となれば幸いです。また、HLS の前身である HIE は必ずしも快適に動作するとは言い難かったため、HLS
10年間使ってみて見えたHaskellの闇と光 - Qiita
はじめに わたしがHaskellを使い始めてもうそろそろ10年目になります。（タイトルは多少サバを読んでいますね） これまで使ってきた感想をまとめます。 Haskellのつらいところ まずは愚痴らせてください。 コンパイルが遅い 依存モジュールはすべてソースコードからビルドする必要があります。（バイナリ形式のモジュールはありません） 最初のビルドに20分くらい待つのはザラです。 複雑な型システムをつかうと型推論や型レベル計算に時間がかかります。 高速なHaskellプログラムを書くためには多くの関数をインライン化する必要があります。最適化ビルドではインライン展開によってコードサイズが大きくなるので時間がかかります。 デバッグが難しい 公式のGHCiデバッガはありますが、今のところIDEから簡単に利用できるわけではないですし、コンパイル済みのライブラリはデバッグできないです。 近年スタックト
新しいGHC拡張、NoFieldSelectorsについて - モナドとわたしとコモナド
今まで不満の多かったHaskellのレコードの扱いを改善するための一歩として、NoFieldSelectorsというGHC拡張の実装を進めている。 動機 Haskellにはレコードを定義するための構文がある。 data User = User { userId :: Int , userName :: Text } こう定義すると、各フィールドごとにuserId :: User -> IntとuserName :: User -> Textというゲッターに相当する関数が生成される。これらの関数は特別な意味合いを持っており、以下のレコード操作の構文にも利用できる。 構築 User { userId = 0, userName = "Zero" } パターンマッチ case foo of User { userId = x, userName = name } -> ... 更新 foo {
Haskell 解説本 小史 - golden-luckyの日記
日本語圏におけるHaskellの解説本には、これまで4回の波がありました。 それを思い出しながら、最後に『プログラミングHaskell 第2版』の紹介をします。 第1波 第2波 第3波 第4波 『プログラミングHaskell』が改訂されます 第2版ではプログラミングにおける型の理解が深まると思う ここで買えます 第1波 Haskell解説本の1つめの波は、2006年、『入門Haskell』と『ふつうのHaskell』が出版された頃にありました。 このうち、『入門Haskell』は（おそらく）日本初のHaskell本です。 『入門Haskell』（2006年） 『ふつうのHaskell』（2006年） 『ふつうのHaskell』は、書名だけを見ると「特殊な言語」であるHaskellを「ふつう」に説明している本であるように思えるのですが、実はそうでもなくて、淡々と部品の説明をしていく感じの内容
Haskellで解くAtCoder
最近HaskellでAtCoderの問題を解いたりしているのでごく基本的な知見をまとめておく。 テクニック集 多くは割と色んな人がすでに言っていることではある。また、想定解法を正しく実装すれば以下のようなことを守らなくても時間内に収まるだろうが、GHCは最適化が効かなければ10倍遅くなる言語であるので普段から守っておくに越したことはないと思う。 環境: AtCoderのGHCは2019.04現在7.10なので注意が必要。そのうち上がるかもしれないけど。 Strict拡張がない BangPatterns拡張はある 環境構築がhaskell-platformらしいのでそれに入ってるライブラリしか使えない 文字列 基本はData.ByteString.Chan8 Stringは死んでも使わない(遅いので) Unicode文字列の扱いが必要(今の所みたことないけど)とかならtextを使うといいかも
さようなら遅延評価 - あどけない話
Haskellがとっつきにくい原因の一つに遅延評価がある。入門書では、無限リストと遅延評価がことさら強調される。しかし、Haskellを業務で使ってみると、遅延評価が煩わしくなってくる。遅延評価なしでもほとんどのことは実現できるし、メモリーの使用量は推測できないし、あまりいいことはない。 Haskellの評価戦略が、他の言語と同じように正格評価だったらよかったのに。 今まで、このようなセリフを何度聞いたか分からない。 そもそも遅延評価が役立つことはあるのだろうか？ ある。お世辞抜きに、少なくとも以下の3つでは本当に役立つ。 リスト(あるいは類似のデータ構造)処理 純粋性に対する暗黙のテスト 効率的なCAS 1.はよいだろう。2.は純粋さを守るために必要だが、コンパイラを開発する人にとって重要なのであり、ユーザには関係ない。3.は、並行プログラミングの奥義である。atomicModifyIO
cabal コマンドとの対応表
注意点 このページの内容は cabal HEAD を追っているため、最新版の cabal ではまだ利用不可能な内容も含まれる場合があります。 参考となるサイト&記事 AWESOME-CABAL Why Not Both? Announcing cabal new-build: Nix-style local builds Introduction to Cabal The Haskell Cabal | Overview haskell/cabal-website stack と cabal $ stack --version Version 2.1.3, Git revision 636e3a759d51127df2b62f90772def126cdf6d1f (7735 commits) x86_64 hpack-0.31.2 $ cabal -V cabal-install vers
Haskellにおいて遅延評価は諸刃の剣であり、注意すべきであるという話 - Qiita
Haskellの特徴といえば遅延評価です。 しかしその遅延評価によってパフォーマンスの低下、もしくは不可解なコードに繋がることがあります。今回はそれらについて紹介したいと思います。 遅延評価とは すごいH本によると、遅延評価というのは「結果が必要になるまで関数を実行しない。」という性質です。 例としては以下のものが挙げられます。 これは無限のリストから100個要素を取り、それらの合計値を算出しています。通常であれば無限のリストを渡せばそれを完全に評価しようとするためにプログラムが止まってしまいますが、Haskellは遅延評価のおかげでその心配がありません。 しかしその「必要になるまで関数を実行しない」ということが問題になることがあります。 パフォーマンスの低下 (遅延Map vs 正格Map) HackageのData.Mapのページには冒頭にて以下の注意書きが記載されています Note:
一人CSアドベントカレンダー開催のお知らせ
これは一人Computer Scienceアドベントカレンダー 1日目の記事です。 概要的なもの 「一人アドベントカレンダーって面白そうだな、やってみたい」みたいなノリで登録したんですが、 25日毎日記事を同じテーマで投稿し続けるのどう考えてもめっちゃ大変なのでやはりここは自分が一番得意な分野で行くしかないかなとなりCS関係ということになりました。 上のQiitaのページでも書いてますが、キーワードとして"ラムダ計算・定理証明・Haskell・ML・圏論 とかなんかそのへん"を挙げていますので そのへんのお話になります。今のところは無難に定理証明を中心にテーマをいくつか選んでおいたので多分そのへんの話です。 スケジュール 最終的にはQiitaのカレンダー見ればわかることなんでいいんですが一応今後どういう感じで進めていくのかのスケジュール的なものをまとめておきます。 Isabelle編 Is
私と型システムとポエム
最近巷では俄に型システムについての言及が増え、型システムポエマーが増えてる気がするので自分もその時流に乗りたい。 完全にポエムだけどなんかあったら随時指摘ください。直します。 TL;DR 言いたいことはまとめると次 型システムは程度問題なのでちょうどいいところを探すべき 型は万能でも強さが正義でもない(だから未だに研究されてる) よく知りもしないくせに計算機科学を侮辱するのはやめろ 予防線 あくまでポエムですので中身はないです 私は型理論専攻で学位はとったものの研究者ではないのであまり信用しすぎないように 型システムの過去 型システムは大まかに次のような利点があるとされてきた(個人的主観) 「異常」なプログラムを検出する仕組み 静的解析による分かりやすいエラーメッセージ 型そのもののドキュメント性 IDEでのcompletionに貢献 最適化に貢献 (数学に正しく裏打ちされたsemanti
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
型レベル関数と型族、型演算子｜Haskellでの型レベルプログラミング
HaskellのMonadお気持ちチュートリアル - Qiita