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での型レベルプログラミング」 | 雑記帳
最近、「Haskellでの型レベルプログラミング」という「本」を執筆している。まだ完成ではないが、以下のリンクから読める： Haskellでの型レベルプログラミング なぜHaskellか 最近いろんな言語が出てきている中で、Haskellの強みとは何だろうか。人によって答えは色々あるだろうが、筆者にとってHaskellの魅力的な側面は強力な型システムである。どのくらい強力かというと、型レベルでプログラミングができ、依存型の模倣さえもできてしまう。 （依存型をやりたいなら最初から依存型のある言語を使えという意見は尤もだが、それはそれとして。） Haskellでの型レベルプログラミングの解説記事というのは、英語圏ではちらほら見かけるが、日本語圏ではあまり見ない。2018年（原文は2017年）に公開された Haskellにおける型レベルプログラミングの基本(翻訳) – Qiita が数少ない例で
関数型プログラミング言語における関数適用構文の歴史的経緯についてのメモ - Arantium Maestum
先日こういうツイートがあった： Haskellとかの関数型言語を使用しているプログラマの皆様にお聞きしたいんですけど、「関数名 引数 引数 ...」みたいな関数呼び出し構文って見にくくは無いですか？「関数名(引数, 引数, ...)」に慣れたこちらからすると、丸括弧が無いからコード中のどこが関数呼び出しなのかパット見で把握しにくい。— sounisi5011/プログラム (@sounisi5011Prog) February 22, 2022 「見にくくは無いですか？」と聞かれると、個人的には「全然大丈夫です」と答えざるを得ないのだが、次のツイートに関しては考えさせられた： 数式でも函数には丸括弧を使ってるのに、どこのタイミングで丸括弧が消失したのかわからないし、その選択をした理由も思いつかない。— sounisi5011/プログラム (@sounisi5011Prog) February
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
Haskell Development
Tips 完全なリビルド おすすめの開発方法 script interpreter + stack script でスクリプティング！ config.yaml のよくある設定 ghc-options の推奨設定 HDD の容量が少なくなってきた時 最小のプロジェクト ファイル単位で ghc-options を指定する方法 カスタムスナップショットの紹介 namespaced templates プロファイルの取得方法 extra-deps に github の短縮形が指定できるようになります stack-2.1 から location に extra-dep を指定できなくなります アプリケーションのバックトレースを取得する cabal コマンドとの対応表 stack サブコマンド stack build stack test stack run stack exec stack clea
Haskell でのデバッグ手法あれこれ | 雑記帳
プログラムにバグはつきものです。強力な型システムを備えている Haskell でもそれは同じです。この記事では、 Haskell プログラムのデバッグ手法をいくつか挙げてみます。 なお、使用している GHC は 8.2.2 です。より新しいバージョンで追加されるであろうより便利な機能は、この記事の対象外です。 【2018年2月8日 更新：-fexternal-interpreter, Control.Exception.assert, debug パッケージについて追記】 【2018年5月25日 更新：プロジェクトごとにPreludeを持っていると便利という話を追加】 心構え：処理を分割せよ Haskell は純粋な言語です。IOが絡まない関数であれば、同じ引数に対しては同じ結果が返ってくることが期待されます。 よって、処理を細かく（純粋な）関数に分割し、それぞれ GHCi で動作を確かめ
Haskell入門という本を書きました - Pixel Pedals of Tomakomai
Haskell入門 という本を書きました。まだ店頭で買うことはできませんが、amazonでは予約を開始しています。また、電子版も早いうちに出ると聞いているので、そちらもあわせてお求め下さい。技術評論社さんのサイトではサンプルのpdfも読むことができます。 Haskellには すごいH本 というとても良い教科書がすでにありますが、「アプリケーションを作って楽しむ」という観点から書かれた本も欲しいなということを常々感じていました1。すごいH本でHaskellの考え方やプログラムの組み方は学べますが、例えば、プロジェクトを作成して開発を始めるにはどうするかであったり、必要なライブラリをどこから探してどのように自分のプロジェクトへ組み込むのかといった、開発に必要な基本的な事項は自分で学ぶ必要があります。今回執筆した Haskell入門 ではとにかくHaskellでアプリケーションを作ることにフォー
有理数とか有限体とかのはなし - Qiita
一部間違いがあります、本文中でも明記しましたが最初の終了条件はInt を覆っていません。 最後に訂正したバージョンとより厳しいquickCheck の結果も載せておきました。 Haskell Advent Calendar 2016 の10日目です。 去年は眺めているだけだったので今回枠取れたの嬉しいです！ レベル分け的にはAdvanced Beginner の一人が同じくらいのレベルの人に向けて書いてるつもりです、やや内容に初等整数論が含まれます。 あわよくばより詳しい人にトンテンカンカンと直していただきたい感じですが。 モチベーション 電卓などで(1/3) の計算をした後、答えに3 を掛けたことがある人、そしてそのとき1 に戻らなかった経験ある人もきっと多いことだと思います。 今回の話はそれにちょっと関係している、かもしれません。 今回は体を取り上げます、体と言うのはいわゆる四則演算に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
型レベル関数と型族、型演算子｜Haskellでの型レベルプログラミング
HaskellのMonadお気持ちチュートリアル - Qiita