Wadlerは素晴らしい論文を書きました: Propositions as Types - 彼はHoward-Curry対応について述べており、プログラムの動作をプログラムの型の観点からチェックできると述べています。(特定の言語サブセットの場合)。

最近、Rich Hickeyは、データと関数の仕様を定義するClojure 仕様をリリースしました。

ここでコメンテーターは次のように書いています。

Wadler から、props ≅ types、specs ≅ props -> types が得られたので、静的な spec/contract/type チェックを行うことができます。

私の質問は、Clojure の仕様は Wadler の命題と同等ですか?

私はclojure.specを研究していて、次のことに遭遇しました：

#inst "2000"それは 2000 年の初めの時間のインスタンスを意味する可能性があると思います。しかし、Google では、表記法とその背後にある概念を説明する適切なドキュメントを見つけることができませんでした。

Clojure の教科書でも習っていませんでした。

clojureの意図が理解できませんでした。スペック

それはどのような問題を解決しますか？

なぜそれを使用する必要があるのですか？

最後の数日間、Clojure と ClojureScript のclojure.specをさらに掘り下げました。

今までは、spec を特定の形式のデータに依存するパブリック関数内:preおよびパブリック関数内でガードとして使用することが最も便利だと思いました。:post

そのアプローチの問題は、仕様を正確に満たしていないものjava.lang.AssertionError: Assert failed: (s/valid? ::person person)についての情報なしで取得することです。

またはガードでより良いエラーメッセージを取得する方法を知っている人はいますか?:pre:post

conformとについては知っていますが、それらやガードexplain*には役に立ちません。:pre:post

だから、私はClojure.Specをどんどん深く掘り下げています。

私がつまずいたのは、スペックをどこに置くかということです。次の 3 つのオプションが表示されます。

グローバル スペック ファイル

私がオンラインで見つけたほとんどの例ではspec.clj、メインの名前空間で必要になる大きなファイルが 1 つあります。すべての「データ型」と機能のすべてと機能を備えています(s/def)。(s/fdef)

プロ：

• すべてを支配する 1 つのファイル

反対:

• このファイルは大きくなる可能性があります
• 単一責任の原則に違反していますか?

プロダクション名前空間の仕様

(s/def)and(s/fdef)を本番コードのすぐ隣に置くことができます。そのため、実装と仕様は同じ名前空間に共存します。

プロ：

• 実装と仕様のコロケーション
• 1 つの名前空間 - 1 つの懸念事項?

反対:

• 本番コードが乱雑になる可能性があります
• 1 つの名前空間 - 2 つの懸念事項?

専用スペック名前空間構造

次に、仕様は第 3 の種類のコード (本番とテストの次に) ではないかと考えました。したがって、次のような名前空間の独自の構造に値する可能性があります。

プロ：

• 仕様専用の (しかし関連する) 名前空間

反対:

• 正しい名前空間を調達して要求する必要があります

アプローチの1つを経験したのは誰ですか?
別のオプションはありますか？
さまざまなオプションについてどう思いますか?

clojure.specガイドの例の 1 つは、単純なオプション解析仕様です。

後で、検証conformセクションで、この仕様を使用して内部的にその入力を行う関数が定義されます。

このガイドは REPL から簡単に理解できるようになっているため、このコードはすべて同じ名前空間で評価されます。ただし、この回答では、@levand は仕様を別の名前空間に配置することを推奨しています。

私は通常、スペックが記述している名前空間と並んで、仕様を独自の名前空間に入れます。

これは上記の使用法を壊します::configが、その問題は解決できます:

仕様のキー名は、仕様の名前空間ではなく、コードの名前空間にあることが望ましいです。これは、キーワードで名前空間エイリアスを使用することで簡単に実行できます。

彼は続けて、仕様と実装を同じ名前空間に入れることができると説明していますが、それは理想的ではありません:

確かに、同じファイル内の仕様コードのすぐそばにそれらを配置することはできますが、それは読みやすさの IMO を損ないます。

ただし、これがdestructuringでどのように機能するかがわかりません。例として、上記のコードを複数の名前空間に変換した小さなBootプロジェクトをまとめました。

boot.properties:

src/example/core.clj:

src/example/spec.clj:

build.boot:

しかし、もちろん、これを実際に実行するとエラーが発生します。

(require 'example.spec)に追加することでこの問題を解決できますbuild.bootが、これは見苦しく、エラーが発生しやすく、仕様の名前空間の数が増えるにつれて、さらに多くなるでしょう。requireいくつかの理由により、実装の名前空間から仕様の名前空間を取得できません。を使用した例を次に示しますfdef。

boot.properties:

src/example/spec.clj:

src/example/core.clj:

build.boot:

最初の問題は最も明白です。

の仕様では、述語を使用して返された要素を検証しfactorたいと考えています。prime?この仕様の優れた点は、それが正しいとfactor仮定すると、関数を完全に文書化し、その関数の他のテストを作成する必要がなくなることです。しかし、それがあまりにもクールだと思う場合は、何かに置き換えることができます.prime?factorpos?

ただし、当然のことながら、再試行してもエラーが発生しますboot run。今回は、 orまたは(最初に試行した方)の:args仕様が不足していると不平を言います。これは、名前空間であるかどうかに関係なく、指定したシンボルが既に存在するvar を指定しない限り、そのエイリアスを使用しないためです。var が存在しない場合、シンボルは展開されません。(さらに楽しむには、fromを削除して何が起こるか見てみましょう。)#'example.core/divisible?#'example.core/prime?#'example.core/factoraliasfdef:as corebuild.boot

そのエイリアスを保持したい場合は、(:require [example.spec])fromを削除してtoexample.coreを追加する必要があります。もちろん、それはfor の後に来る必要があります。そうしないとうまくいきません。そして、その時点で、 を に直接入れてみませんか?(require 'example.spec)build.bootrequireexample.corerequireexample.spec

これらの問題はすべて、仕様を実装と同じファイルに入れることで解決できます。では、仕様を実装とは別の名前空間に置くべきでしょうか? もしそうなら、私が上で詳述した問題はどのように解決できますか?

この回答を書いた後、私はClojure の分解言語をspec次のように指定しようと思いつきました。

順次分割部分は正規表現で簡単に指定できます (ここでは無視します) が、連想分割で行き詰まりました。最も基本的なケースは、バインド フォームからキー式へのマップです。

しかし、Clojure にはいくつかの特別なキーも用意されています。

に準拠するマップ::assocと に準拠するマップをマージして作成できるマップの仕様を作成するにはどうすればよいですか? 私はあることを知っています：::mappings::optsmerge

しかし、これmergeは基本的に の類似物であるため、機能しませんand。に似たものを探していorますが、マップ用です。

関数とマップを入力として取り、関数を使用して競合を解決するマージ関数の仕様を作成しようとしています。ただし、関数用に書いた仕様は失敗します。そのような関数の仕様を記述する方法を理解しようとしています。

以下はコードスニペットです。

私が得ている仕様エラーは次のとおりです。