HaskellでGitHub Actionsのワークフローを書きたい
この記事はHaskell Advent Calendar 2023の9日目の記事です。 Dhallがちょっとつらくなってきた ひとりでちまちまと作り続けているPeridotのCIなどでGitHub Actionsを使っています。 このワークフローの定義を、以前はDhallで書いてyamlに変換するという形で運用していました。Dhallを使うことで生のyamlを触るよりはるかに安全かつ簡単にワークフローの記述/修正を行うことができていましたが、次のようなつらみがあって少し前にHaskell製のお手製ワークフロージェネレータに一気に鞍替えしました。 型推論が限定的 ほぼこれがすべてな気がしますが、Dhallは型推論をしてくれる範囲が全コードではなく、一部は明示的に与えてあげる必要があります。 より具体的には関数適用時に型変数を自動で推論してくれないので、ここを毎回明示する必要があります。設定フ
Dhallの型定義からRustの型を自動生成するマクロ - Qiita
Dhallという面白くて強い設定記述言語とRustに存在する最強なプロシージャルマクロのお話です。 Dhallについて Dhallとは設定記述言語の一つです。要するにINIやJSONやYAMLといったものの一種になります。 Dhallはそうした設定記述言語の中でも、変数が使えたり関数が使えたりと突出してマンフレンドリーな機能を多く備えています。 その一方でチューリング不完全であり、ざっくりというと式の評価が必ず停止します。設定ファイルを読み込んだら記述をミスって無限ループになって初期化フェーズで死んだなんてことになると大変ですので、必ずとある形で評価が停止してくれるというのは設定ファイルとして採用する際に安心できるポイントです。 Haskellよろしくインデントベースな構文であることと、書き方が多様にわたるためプログラムから生成する設定ファイルのフォーマットとして扱うには少し厳しいところが
Dhall - Year in review (2019-2020)
The Dhall configuration language is now three years old and this post reviews progress in 2019 and the future direction of the language in 2020. If you’re not familiar with Dhall, you might want to visit the official website for the language. This post assumes familiarity and interest in the language. I would like to use this post to advertise a short survey you can take if you would like to provi
Dhall を試して物足りない部分を補うツールを自作した
本稿は Haskell Advent Calendar 2018 5日目の記事です． Haskell Day 2018 の発表をきっかけに，兼ねてから気になっていた Dhall を試した． いくつかツールが欲しくなったので作りましたっていう話です． 作ったものはこれ: matsubara0507/yaml-to-dhall - GitHub matsubara0507/dhall-ex - GitHub ちなみに，今回作ったツールは現状の stack の stable resolver にある v1.5.1 を利用している． Dhall Dhall は静的型付けされた設定記述言語である． 多くの場合，プログラミング言語やアプリケーションに使われる設定ファイルには JSON や YAML が利用されている． プログラミング言語のビルドシステムのような設定ファイル一つ程度なら問題ないが，Kub
Dhall v3.0.0 がリリースされた - ryota-ka's blog
この記事は以下のページに移転しました． blog.ryota-ka.me Dhall v3.0.0 がリリースされた．メイジャーバージョンの更新ということで，いくつかの破壊的変更を含む． Version 3.0.0 of the Dhall standard is out: * `Some`/`None` constructors for `Optional` (`Some` performs type inference) * Kind polymorphism (Allows records to store types of mixed kinds) More details: https://t.co/Dln6fFq3FW— Dhall (@dhall_lang) October 16, 2018 Some / None コンストラクタが予約語として導入 Optional 型のコン
Dhall で Kubernetes の YAML 管理をスマートにやっていく
この記事は以下のページに移転しました． blog.ryota-ka.me こんにちは．Kubernetes 班の ryota-ka です。皆さん Kubernetes やっていますか？*1 Kubernetes をやっていこうとすると，大量の YAML を書くことになって大変である．大量の YAML を書くことは大変なので，大抵コピペする．コピペをするが，コピペは怖い．例えば，deployment を定義する YAML をコピペしたとして，万一 label を変更するのを忘れて，想定していない service からルーティングされたりすると悲惨である．そもそも(個人的な意見ではあるが) YAML の仕様自体があまりにも複雑かつ難解であり*2，ある種の仕様が余計なお世話だともしばしば感ぜられる*3． 最近では kustomize が将来的に kubectl に統合される予定で開発が進められて
Dhallによるリッチな設定ファイル体験 - syocy’s diary
(この記事のレギュレーション: lts-11.9) Dhall という設定記述用言語があり、使ってみたところ良い感じだったので紹介します。 なお、この記事は先日某所で発表したものの拡大版になります。 speakerdeck.com Dhallとは何か Dhallについて短かく表現するなら公式サイトの以下の説明が分かりやすいです。 You can think of Dhall as: JSON + functions + types + imports データ表現にプログラマブルさと静的な検査とファイルのインポートを加えたものというわけです。 まだ開発中のためかあまりアピールされていませんがツールチェインも充実しており、 ちょっとした処理を確かめるためのREPLや、 今どきの言語らしく公式フォーマッタもあります。 あと大事なのはチューリング完全ではないということです。 具体的にはループなどは
Haskellで抽象構文木 (AST) にメタデータを付与する - Hash λ Bye
2018-01-04 追記: ここで全部語り尽くされている気がしたので、Labelling AST Nodes with locations なにもこんなブログ読むことはないのかもしれない。 megaparsecを使って構文解析器を書いている。 構文解析やっているとASTにソースファイルの位置情報とかをメタデータとして乗せたくなるが、 どんな感じで実装するのか調べた。 僕自身はどのアプローチをとるのか決まっていない。 問題 やりたいこと megaparsec, parsecなどのコンビネータライブラリはジェネレータ系のalex + happyと比べると幾分まともなエラーメッセージを吐くようになっている。(alex + happyがえげつないほどterseなだけ) しかし、構文解析が終わった後のα変換によるshadowingの回避や型推論のフェーズでコンパイラがエラーを見つけた場合に、 その
Dhall - Year in review (2017-2018)
The Dhall programmable configuration language is now one year old and this post will review progress over the last year and the future direction of the language in 2018. If you're not familiar with Dhall, you might want to visit the official GitHub project which is the recommended starting point. This post assumes familiarity with the Dhall language. Also, I want to use this post to advertise a sh
Semantic integrity checks are the next generation of semantic versioning
The Dhall configuration language just added support for "semantic integrity checks". This post explains what "semantic integrity check" means, motivates the new feature, and compares to semantic versioning. The problem I added this feature in response to user concerns about code injection in Dhall configuration files. We'll illustrate the problem using the following example.dhall configuration fil
Type-driven strictness
I was recently trying to optimize Dhall's performance because the interpreter was performing poorly on some simple examples. For example, consider this tiny expression that prints 3000 exclamation marks: Natural/fold +3000 Text (λ(x : Text) → x ++ "!") "" The above Dhall expression takes over 14 seconds to evaluate to normal form, which is not acceptable: $ bench 'dhall <<< './exclaim' benchmarkin
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - ocharles/dhall-build: Drive the Nix build system using the Dhall configuration language
Dhall - Year in review (2018-2019)
GitHub - as-capabl/clay-dhall: C Layer for Dhall Language
GitHub - matsubara0507/yaml-to-dhall: Roughly implement CLI tool to convert YAML to Dhall
HaskellでDhallをExtensibleのレコードとして読み込めるようにする
GitHub - ababkin/dho: Generate CircleCI config from `dhall` representations
GitHub - mstksg/hakyll-dhall: Dhall compiler for Hakyll
GitHub - vmchale/dhall-vim: Syntax highlighting for Dhall
GitHub - dhall-lang/dhall-haskell: Maintainable configuration files
