Hexyll.Core.Provider をリファクタリングする

[Hexirp]

See https://github.com/Hexirp/hexirp-hakyll/issues/98 .

Provider ディレクトリをつかさどる。補助として Store の作用を使う。

[Hexirp]

うーん、リソースの情報を纏められるという感じかな？　リソースの更新日時とかメタデータとか。

[Hexirp]

https://github.com/Hexirp/hexirp-hakyll/blob/fa0f4d089425372951b283432a940c6046a2b9f5/hexyll-core/src/Hexyll/Core/Provider.hs

中核になりそうな関数も色々ある。

[Hexirp]

https://hackage.haskell.org/package/hakyll-4.13.2.0/docs/Hakyll-Core-Provider.html

なるほどなあ？

[Hexirp]

全てのリソースは対応する識別子を持っている。リソースには更新日時がある。リソースにはメタデータが付属している場合もある。メタデータもリソースであり、識別子が付いている。

[Hexirp]

ううむ……ここの作り方が適当だ。

https://github.com/Hexirp/hexirp-hakyll/blob/fa0f4d089425372951b283432a940c6046a2b9f5/hexyll-core/src/Hexyll/Core/Provider/MetadataCache.hs#L25

エラーを握りつぶしている。

[Hexirp]

関連してそうなのは Metadata 作用と Universe 作用と Store 作用である。

[Hexirp]

https://github.com/Hexirp/hexirp-hakyll/blob/fa0f4d089425372951b283432a940c6046a2b9f5/hexyll-core/src/Hexyll/Core/Provider/Internal.hs#L86-L87

ここはどこから来るんだろう？ Store かな？

[Hexirp]

Store 作用は type Storable a = (Typeable a, Binary a) である型の値をストアに保存したり読み込む。

Universe 作用は、認識している全ての識別子を読み込むことが出来る。

Metadata 作用は、識別子に付随しているメタデータを読み込むことが出来る。

[Hexirp]

ここでポイントなのは空のメタデータが許されることか？

[Hexirp]

そういえば MetadataEnv を作っていないな。不要だろうけど。

[Hexirp]

空のメタデータはこのようになる。

emptyMetadata :: Metadata
emptyMetadata = Metadata HM.empty

[Hexirp]

Provider 作用の中核になるべきなのは、この二つだろう。

resourceMetadata :: Provider -> Identifier -> IO Metadata
resourceBody :: Provider -> Identifier -> IO String

更新日時の作用とは分離すべきだろう。

[Hexirp]

さらに resourceMetadata は getMetadata と統合される……！

[Hexirp]

つまり、こうなる？

class MonadMetadata m => MonadProvider m where
  getBody :: Identifier -> m String

ああ、それっぽい。出力を String だけに制限するのはどうしたものか。

[Hexirp]

ここでさらに Store 作用を加えるべきか？

[Hexirp]

もしかして Provider って Store を除けば不変なのか？

[Hexirp]

やはりそうだ。 newProvider で生成した後は変化しない。確かに Store もそうっちゃそうだからいいんだけど。

[Hexirp]

うーん、やっぱり内部で Store 作用を利用するので含めよう。

[Hexirp]

関数を一つずつ検索して、必要かどうか確かめていこう。

[Hexirp]

resourceFilePath ってどうして必要なの？ identifierPath を使えばいいんじゃない？　と思っていたけど、ファイルのパスに providerDirectory を付けるのか。

[Hexirp]

getMetadata :: Identifier -> IO Metadata
resourceMetadata :: Identifier -> IO Metadata

resourceFilePath :: Identifier -> IO FilePath

resourceModificationTime :: Identifier -> IO UTFTime

resourceBody :: Identifier -> IO String

こういう風に色々な情報を取得できるようになっているんだな。

[Hexirp]

メタデータについてもっと考えないといけない。リソースには必ずメタデータが付いていると MonadMetadata により設定されている。それで Metadata はリソースなのか。識別子がつくのか。

[Hexirp]

嘘でしょ？　メタデータの形式がここでハードコーディングされている。

https://github.com/Hexirp/hexirp-hakyll/blob/fa0f4d089425372951b283432a940c6046a2b9f5/hexyll-core/src/Hexyll/Core/Provider/Metadata.hs

[Hexirp]

こんなの意味がない。メタデータもコンパイラーで取得するようにしよう。

[Hexirp]

全てがリソースである、つまり全てに識別子が付く主義を取ると、メタデータのメタデータのメタデータという困ったことが起きる。

[Hexirp]

コンパイラの途中のデータもリソースと捉えるべきか？　分からない。

[Hexirp]

https://github.com/Hexirp/hexirp-hakyll/blob/fa0f4d089425372951b283432a940c6046a2b9f5/hexyll-core/src/Hexyll/Core/Provider/Internal.hs#L128

ここがメタデータがリソースとして扱われているらしき場所……かと思ったけど違うみたい？

[Hexirp]

https://github.com/Hexirp/hexirp-hakyll/blob/fa0f4d089425372951b283432a940c6046a2b9f5/hexyll-core/src/Hexyll/Core/Provider/Internal.hs#L64

ここで致命的にそうなってる。

[Hexirp]

識別子 (Identifier) とファイルパス (FilePath) の混同か？

[Hexirp]

Hexyll はリソースという概念を中心として動く。

• 全てのリソースには識別子がある。
• ファイルを表すリソースがある。
• メタデータを表すリソースがある。
• リソースには一つかゼロのメタデータがある。

[Hexirp]

• ファイルを表すリソースには更新日時がある。
• ファイルを表すリソースにはファイルパスがある。
• メタデータを表すリソースには更新日時がある。
• メタデータを表すリソースにはファイルパスがある。

[Hexirp]

別のモデルとして……

• 全てのリソースには識別子がある。
• ファイルを表すリソースがある。
• リソースには一つのメタデータがある。
• ファイルを表すリソースには更新日時がある。
• ファイルを表すリソースにはファイルパスがある。
• メタデータを表すリソースには更新日時がある。

[Hexirp]

• ファイルを表すリソースはボディを読み込むことが出来る。
• リソースはメタデータを読み込むことが出来る。
• ボディの読み込みはキャッシュされる。
• メタデータの読み込みはキャッシュされる。

そして

• ファイルを表すリソースは provider ディレクトリ以下にあるファイルに対応するもののみである。

[Hexirp]

• メタデータを表すリソースはコンパイラーにより登録されていく。

[Hexirp]

https://github.com/Hexirp/hexirp-hakyll/blob/fa0f4d089425372951b283432a940c6046a2b9f5/hexyll-core/src/Hexyll/Core/Compiler/Internal.hs#L135

何かを要求するときは、何が必要なのだろうか？　生の文字列？　コンパイラー結果？　前者だろうな。

[Hexirp]

いや、コンパイラーの結果だ。それは SomeItem で抽象化される。

https://github.com/Hexirp/hexirp-hakyll/blob/fa0f4d089425372951b283432a940c6046a2b9f5/hexyll-core/src/Hexyll/Core/Runtime.hs#L108

一つのリソースに一つのコンパイラーが対応する……。

[Hexirp]

コンパイラーの多重化は identifierVersion で実現されるのだろうか……？

[Hexirp]

纏めようか？

• 全てのリソースには識別子が一つ以上対応している。同じリソースに対応しながらも identifierVersion が異なる識別子が複数存在する可能性もある。
• provider ディレクトリ以下のファイルの一つに対応するリソースが一つある。これをファイルに対応するリソースとする。
• ファイルに対応するリソースには更新日時が存在する。
• ファイルに対応するリソースにはファイルパスが存在する。
• リソースには一つかゼロのメタデータが対応する。
• 一つのメタデータに対応するリソースが一つある。これをメタデータに対応するリソースとする。
• メタデータに対応するリソースには更新日時が存在する。

[Hexirp]

resourceInfoMetadata は内部でしか使われていない。

[Hexirp]

だが、メタデータの取得の形式も自由にしたいので、メタデータもリソースとすることにする。

[Hexirp]

• 全てのリソースには識別子が一つ以上対応している。同じリソースに対応しながらも identifierVersion が異なる識別子が複数存在する可能性もある。
• provider ディレクトリ以下のファイルの一つに対応するリソースが一つある。これをファイルに対応するリソースとする。
• ファイルに対応するリソースには更新日時が存在する。
• ファイルに対応するリソースにはファイルパスが存在する。
• リソースには一つかゼロのメタデータが対応する。
• 一つのメタデータに対応するリソースが一つある。これをメタデータに対応するリソースとする。
• メタデータに対応するリソースには更新日時が存在する。

[Hexirp]

んんん……？　「メタデータに対応するリソースには更新日時が存在する」は、メタデータが別のファイルとして存在する形式 a.txt.metadata に対応するためか？

[Hexirp]

• 全てのリソースには識別子が一つ以上対応している。
• 全ての識別子に一つかゼロのコンパイラーが対応している。
• 同じリソースに対応しながらも identifierVersion が異なる識別子が複数存在する可能性もある。
• provider ディレクトリ以下のファイルの一つに対応するリソースが一つある。これをファイルに対応するリソースとする。
• ファイルに対応するリソースには更新日時が存在する。
• ファイルに対応するリソースにはファイルパスが存在する。
• リソースには一つかゼロのメタデータが存在する。
• 一つのメタデータに対応するリソースが一つある。これをメタデータに対応するリソースとする。
• メタデータに対応するリソースには更新日時が存在する。

たとえば、 index.md をコンパイルするのに index.md のメタデータが必要としよう。 index.md のコンパイラーは index.md (metadata) のコンパイル結果に依存する。 index.md (metadata) のコンパイラーは生の index.md が必要かもしれないし生の index.md.metadata が必要かもしれない。

[Hexirp]

MonadProvider はファイルに対応するリソースを扱うモナドであり……メタデータに関する機構はより高機能な箇所……つまり、コンパイラーなどで実装される。

[Hexirp]

MonadUniverse はどうするか……。ファイルに対応するリソースが全てであるならば MonadProvider が継承する道理はあるが。

しかし、そうではない。新しいリソースが登場する可能性がある。

[Hexirp]

https://github.com/Hexirp/hexirp-hakyll/blob/fa0f4d089425372951b283432a940c6046a2b9f5/hexyll-core/src/Hexyll/Core/Provider/Internal.hs#L170

ここは私の考察の裏付けになるな……

MonadProvider において Identifier は不要であり Path Rel File で十分。

[Hexirp]

Ident と略するのをやめようか。

[Hexirp]

H.C.Metadata のそもそもの設計が悪い可能性が？