Prismaticでは，同社のClojureデータ記述ライブラリであるSchemaの0.2リリースに，データの強制型変換(coercion)を追加した。これにより，不正な型のデータを単にリジェクトするのではなく，スキーマに適合させてインスタンスを変換するような設定が可能になる。
ClojureではMapのキーとしてキーワードが慣用的に使用される。そのためJSONオブジェクトの受信時には，変換を実施するために頻繁に使用されるボイラプレートコードが存在する。従来このような変換は，リクエストを検証する前に実行する必要があった。今回の変更により，キーをキーワードとして定義しておけば，Schemaがその処理を実行してくれるようになる。自分自身のニーズに合わせて，独自の変換処理を定義することももちろん可能だ。この追加機能などによってPrismaticでは，データ検証の所要時間が5分の1に短縮されたと説明している。
9月の初回リリース時にSchemaが目標として挙げたのは，"より少ない手間で，Clojureの型システムのメリットをより多く享受する"ことだった。リリースの時点では，同じくClojureに型システムを導入するライブラリであるcore.typedと競合する可能性が指摘されていた。この見方に対しては，core.typedの作者であるAmbrose Bonnaire-Sergeant氏が反論した。両ライブラリは互いに補完し合うものだという氏の主張は，後にcore.typedに関してInfoQがインタビューした時にも改めて述べられている。
InfoQ: Shemaが最初にリリースされたとき，core.typedと組み合わせることで非常に強力なものになる可能性が示唆されました。それ以降，このアイデアに進展はあったのでしょうか？
数年前にQiプログラムを初めて見て以来，Clojureの漸進的型付け(gradual types)には強い興味を持っていました。それを実現したという意味で，Ambroseは素晴らしい仕事をしたと思います。Schemaとcore.typedを組み合わせる方法はいくつかありますが，もっとも興味深いのは多分，core.typedでチェックしたコードとそうでないコードとのブリッジとして，Schemaを使う方法だろうと思います。そうなのですが，残念なことにまだcore.typedを十分に調査する時間が取れていないので，今の時点でご報告できることはほとんどありません。
InfoQ: テストデータ生成への展開は意欲的なテーマだと思うのですが，simple-checkを取り込んだり，test.generativeを利用したりするのでしょうか。あるいは別のアプローチを考えていますか？
選択肢を探している段階です。simple-checkについては素晴らしい評価をたくさん目にしていますから，何とか取り入れたいと思うのですが，今はまだ実装内容を理解して，その生成プロセスに追加の制約を組み込み方法を見つけようとしているところです。個別のデータを疑似ランダムに具体化するような，もっとシンプルなジェネレータも存在するでしょう。テストでは結構，そういったものを多く使用しています。
InfoQ: Schemaの定義からもっと価値を引き出すために，どのような考えをお持ちですか？
強制型変換と変換は非常に強力ですから，今はまだその可能性をすべて引きだそうとしている段階です。同僚のDave GollandがClojure Westで"fnhouse"という，グラフとスキーマを結合してWeb APIを容易に構築可能にする新ライブラリについて話をする予定です。今回のリリースに続いて，fnhouseのAPIからObjective Cと ClojureScriptのモデルクラス，クライアントAPIライブラリを自動生成する"coax"をリリースする予定です。
その後もクレイジーなアイデアがたくさんありますが，まだお話できる段階ではありません。
Graphは2013年にリリースされたPrismaticsのClosureライブラリで，構造化された計算を宣言型のスタイルで表現するものだ。