Windowsで動くプログラミング言語に脆弱性、引数の扱い方の穴を突いて攻撃
CERT Coordination Center (CERT/CC, Carnegie Mellon University)は4月10日(米国時間)、「VU#123335 - Multiple programming languages fail to escape arguments properly in Microsoft Windows」において、Windows上で動作する複数のプログラミング言語から引数を適切にエスケープしない脆弱性を発見したと報じた。この脆弱性はアプリケーションのコマンドインジェクションにつながるとして注意を呼びかけている。 VU#123335 - Multiple programming languages fail to escape arguments properly in Microsoft Windows 脆弱性の詳細 多くのプログラミング言語にはオ
GHC 9.10の新機能
GHC 9.10.1-alpha1が2024年3月14日にリリースされました。正式版のリリースは4月ごろを目指しているようです（9.10.1 · Milestones · Glasgow Haskell Compiler / GHC · GitLab）。 この記事では、GHC 9.10の新機能を確認していきます。過去の類似の記事は GHC 9.2の新機能と、GHCの動向2021 GHC 8.10とGHC 9.0の新機能 GHC 9.4の新機能 GHC 9.6の新機能 GHC 9.8の新機能 です。 この記事は網羅的な紹介記事とはなっていません。是非、公式のリリースノート類も参照してください： 2.1. Version 9.10.1 — Glasgow Haskell Compiler 9.10.0.20240313 User's Guide docs/users_guide/9.10.1-
2023年にHaskell関連で知ってよかったこと - あどけない話
これはHaskell Advent Calendar 2023の19番目の記事です。 フォーマッター 以前、フォーマッターをいくつか試しましたが、どれもイマイチでした。しかし、fourmoluはいけてます。fourmoluは、Ormoluのフォークで、Ormoluが偉大なのでしょう。両方試しましたが、僕はformoluに決めました。 Hackageに上がっているので好きな方法でインストールしてください。 % cabal install fourmolu formoluにHaskellのプログラムを渡すと、整形したプログラムを出力してくれます。ファイルの内容を直接書き換えたいときは、-iオプションを渡します。エディタやIDEと連動できますが、お試しでプロジェクト全体を整形するには、以下のようにするといいでしょう。 % find . -name "*.hs" | xargs fourmolu
inline CUDA - Qiita
目的 HaskellでGPUを扱う場合にはaccelerateなどがありますが、既存のGPUを扱えるC/C++のコードを使ってGPUとやり取りする場合に、直接CUDAのコードを扱いたい場合があります。 現状では、CUDAのファイルを使うワークフローが煩雑です。 cabalファイルはCUDAをサポートしてないので、CUDAのコードをあらかじめMakefileなどを使って事前にビルドし、cabalファイルにそのライブラリのファイルを追加するという流れになるかと思います。つまりcabalだけでビルドできません。 こちらの例ではMakefileでnvccを使ってCUDAのファイルをビルドしてghcでそのファイルにリンクしていると思います。 今回HaskellのコードにCUDAのコードを埋め込み、cabalファイルに特別な変更を入れないでCUDAのコードを扱えるようにし、cabalだけでビルドできる
AI搭載エディタ「Cursor」にHaskellを書かせてみた
これは「Haskell Advent Calendar 2023」13日目の記事です。 日頃、私は趣味としてAIをHaskellで実装することに没頭しています。しかし、今回は少し違ったアプローチを試してみようと思います。逆に、AIにHaskellを使って自ら実装させ、その過程や成果を共有してみたいと考えています。この新たな取り組みがどのような結果を生むのか、一緒に探ってみましょう。 AI搭載エディタ「Cursor」 気を取り直して、今回は最近話題のAI搭載エディタ Cursor を使って実際に動くHaskellのアプリを0から作らせてみたいと思います！Cursorをまだ知らない人は以下の記事がオススメです（僕もまだこれしか読んでません🤫） Cursorのダウンロードとインストール、そしてアカウント登録が完了したらさっそくHaskellを書かせてみたいと思います。 それではレッツ・・・ ゴ
HaskellでGitHub Actionsのワークフローを書きたい
この記事はHaskell Advent Calendar 2023の9日目の記事です。 Dhallがちょっとつらくなってきた ひとりでちまちまと作り続けているPeridotのCIなどでGitHub Actionsを使っています。 このワークフローの定義を、以前はDhallで書いてyamlに変換するという形で運用していました。Dhallを使うことで生のyamlを触るよりはるかに安全かつ簡単にワークフローの記述/修正を行うことができていましたが、次のようなつらみがあって少し前にHaskell製のお手製ワークフロージェネレータに一気に鞍替えしました。 型推論が限定的 ほぼこれがすべてな気がしますが、Dhallは型推論をしてくれる範囲が全コードではなく、一部は明示的に与えてあげる必要があります。 より具体的には関数適用時に型変数を自動で推論してくれないので、ここを毎回明示する必要があります。設定フ
HaskellのAlexとHappyでnode-semverパーサーを実装する
この記事はHaskell Advent Calendar 2023４日目の記事です。 最近node-semverのパーサーを作る機会があったので、HappyとAlexを用いたパーサーの作り方について紹介します。あまりnode-semverの仕様には立ち入らず、HappyとAlexの使い方について焦点を当てます。 パーサーの実装はここです。 パーサの種類 パーサーの実装は主に手書きするか文法書から生成する２通りの方法があります。最も有名なのは再帰降下構文解析と、LR構文解析でしょうか。 PEGやパーサーコンビネータは再帰降下に属し、yaccやbisonはLR系の構文解析に属します。 こちらのサイトでは様々な構文解析法の分析をしています。箇条書きで抄訳したいと思います。 再帰降下系 わかりやすい 実はどの文法クラスに対応するか理論的に明らかになっていない 曖昧な文法を事前に検知できない 無限に
Haskell の Array
Haskellのカレンダー | Advent Calendar 2023 - Qiita 3日目の記事です。 Haskell の Array (配列) について書こうと思います。Haskell の Array は索引が型クラスの Ix で抽象化されているため、特に配列の次元を拡張する際に柔軟性がありとても便利です。 そんな便利な Array ですが、もともと Haskell はリスト操作が強力ということもあってか、既存の参考書をみても Array の解説はほんの少しにとどまっているか、解説がないことがほとんどです。 Array が必要になる場面の多くは「リストだと !! によるインデックスアクセスで O(n) になってしまい間に合わない」という場面が多いと思います。しかし Haskell にはインデックスアクセスが O(1) の Vector (vector: Efficient Arra
Reddit で振り返る今年の英語圏 Haskell 界隈の話題 - Qiita
Haskel advent calendar 2023 の1日めの記事です． お仕事も情報系でなく，多忙を言い訳に数年ほとんどコード自体をかけていなかったのですが，最近 e-Gov 法令検索 で公開されている法令XMLを読みたい需要があって久しぶりに Haskell で書いてみたらやはり書きやすく，とても楽しくて改めて感動しました．書きながら自然に思考が整理される感じがよい． Hoogle は変わらぬ使いやすさでモリモリサポートしてくれるし，環境構築も GHCup などが噛み合って随分スムーズで，Haskell Language Server も成熟してきているようです．環境構築については，昨年の Advent Calendar の1日め @mod_poppo さんの記事 などが参考になります． 最近入った言語拡張にも，ちょっとだけコード書く位でも（大規模なあるいは高度なコードじゃなくても
A Fistful of Automata
20 October 2023 Recently, I have been brushing up my knowledge of Formal Languages and stumbled again into the many different faces of finite automata. Most materials present DFAs, NFAs and company as distinct beasts, each with their own properties and theorems. Nevertheless, I couldn’t get out of my mind that all definitions seemed too similar. After hitting my head into a couple walls, I finally
[Haskell] f <$> x <*> y よりも liftA2 f x y の方が計算コストを抑えられることがある - Qiita
Applicative の値に関数を適用したいとき、liftA2 関数を用いると演算子 <$> を使用するより計算コストを抑えられることがあります。 意味的には liftA2 f x y = f <$> x <*> y です (※定義ではなく、実際の計算方法は異なります) 。 参考「liftA2 - Control.Applicative」 参考「[Haskell] モナド 演算子 まとめ - Qiita」 1. liftA2 関数および liftA3 関数 ここでは説明のため各演算子および関数の型クラス制約を略しますが、型変数 f の型は Functor および Applicative クラスのインスタンスです。 liftA2 関数および liftA3 関数の型は以下のようになっています。 -- Functor (比較用) (<$>) :: (a -> b ) -> f a -> f b
![[Haskell] f <$> x <*> y よりも liftA2 f x y の方が計算コストを抑えられることがある - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/2cf0cb67600cef21cdb0e6bfa1fda03790c9153a/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JTVCSGFza2VsbCU1RCUyMGYlMjAlM0MlMjQlM0UlMjB4JTIwJTNDJTJBJTNFJTIweSUyMCVFMyU4MiU4OCVFMyU4MiU4QSVFMyU4MiU4MiUyMGxpZnRBMiUyMGYlMjB4JTIweSUyMCVFMyU4MSVBRSVFNiU5NiVCOSVFMyU4MSU4QyVFOCVBOCU4OCVFNyVBRSU5NyVFMyU4MiVCMyVFMyU4MiVCOSVFMyU4MyU4OCVFMyU4MiU5MiVFNiU4QSU5MSVFMyU4MSU4OCVFMyU4MiU4OSVFMyU4MiU4QyVFMyU4MiU4QiVFMyU4MSU5MyVFMyU4MSVBOCVFMyU4MSU4QyVFMyU4MSU4MiVFMyU4MiU4QiZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnR4dC1jbGlwPWVsbGlwc2lzJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9MjlkOTg1MDljZDA1YWVhMGMxNTc5YTI4ODAyMDhhMjQ%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTcxNiZ0eHQ9JTQwa2VydXBhbmkxMjkmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zMiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPWU4MjQ5MmYzMTc5OGQ3ZDVkOWM0ZTRhOWE2YmViNWJl%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3D497d0edfe356fa5db4ce935c3a8136c8)
unsafePerformIOではじめる愉快なHaskellプログラミング
Haskellは「入出力のためにIOモナドを使う必要があるので難しい」というイメージを持たれがちです[要出典]。この記事ではそのイメージに異を唱えることを目指します。すなわち、モナドを使わずに入出力を含むプログラミングをやってみます。 と言っても、Haskell標準の入出力関数には IO 型がついていることに変わりはありません。ですが、 unsafePerformIO という魔法の関数を使うと、IO 型を外して値を取り出すことができるのです。この記事ではこれを最大限活用します。 module System.IO.Unsafe where -- 魔法の関数 unsafePerformIO :: IO a -> a
Haskellプロジェクトのベストプラクティス
Haskellプロジェクトの「良い習慣」と考えられるやつをまとめてみます。あくまで私の個人的な意見です。 プロジェクト固有のPrelude Prelude に相当するモジュールをプロジェクト独自に持っておくと便利ではないか、という話をします。代替Preludeの話ではありません。 プロジェクト固有のPreludeがあると便利な理由 理由の一つは、標準 Prelude の変化です。直近では次のような変化がありました： GHC 9.4: ~ 型演算子が追加（これまでは構文だった） GHC 9.6: liftA2 が追加 GHC 9.10（見込み）: foldl' が追加 もっと昔に遡ると、Semigroup((<>)) が増えるやつなどがありました。 この帰結として、 新しいGHCで名前の衝突が起きやすくなる 新しいGHCで「冗長なインポート」の警告が出やすくなる ことが言えます。これらの問題
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - jozefg/pcf: A small compiler for PCF
Haskellのzip関数を一般化すると何になるか
Pandoc in Wasm
GitHub - shapr/kudzu: coverage driven random testing framework
Haskell webassembly in the browser
NeoHaskell
GitHub - travitch/haggle: An efficient graph library for Haskell