Hakyll.Core.Compiler: added makeItems

[wrengr]

I added a function makeItems which behaves like (mapM makeItem) but far more efficiently

[wrengr]

Also added optionalField which behaves as a combination of field and boolField

[krsch]

The optionalField has already been suggested in #311. That implementation accepts Item a -> Compiler (Maybe String) which in my opinion is much better. That pull request was closed due to its simplicity. However maybe implementing optionalField at least in documentation would really help someone.

I don't quite understand when would you need to create a list of Items with the same identifier. Could you make an example? And is makeItems really more efficient than mapM makeItem?

[nagisa]

@krsch #311 is still open.

[krsch]

@nagisa sorry, my mistake. Then this pull request might be a reason to merge #311.

[wrengr]

I'm all for the type Item a -> Compiler (Maybe String); I just implemented the simplest thing I could get to work based on a quick look at how the other field operators are defined (esp., boolField). Even if it is "trivial", the fact that multiple folks have requested it, and that it wasn't immediately obvious how to implement it (I'm only using it as a -> Maybe String and I had to sift through the Hakyll source to try and figure out how the $if()$ stuff even works) suggests that, in fact, it isn't so trivial to the uninitiated. Honestly, I was surprised that it wasn't already included in the library.

As for makeItems, I have a lot of database-like pages. That is, many of my pages are generated from lists of records (e.g., 1, 2), and it's necessary to convert each pure [A] into some [Item A] for passing off to contexts, templates, etc. So far as I'm aware, the Itemness is irrelevant here, and makeItem/makeItems is the simplest way to have things typecheck. Performance-wise, makeItems is more efficient because it does not need to repeatedly call getUnderlying and because the monad does not interfere with the ability to fuse away intermediate lists. In theory, GHC might be able to optimize away the overhead of using mapM makeItem, but that's relying on compiler magic unnecessarily.

The ultimate issue behind both these extensions is that it seems like Hakyll is (currently) designed exclusively to handle one-off pages (e.g., 3, 4) and blogs, and so has little support for pages generated from non-blog databases.

[jaspervdj]

I think we should add something like boolField or optionalField, since this has been requested twice now.

I don't think something like makeItems is necessary though. It will confuse people more since it uses the same underlying identifier. If you want this sort of "advanced" behaviour, it's not that hard to write mapM makeItem. And the performance of mapM makeItem really becomes a bottleneck (which I doubt it will)`, you can implement it in your site?

[wrengr]

No worries, I can implement makeItems locally :) It really shouldn't be a bottleneck (if it is, that's a separate problem imo), I just default to high-level say-what-you-mean operators whenever possible— both for performance reasons and for semantic clarity/concision.

[wrengr]

Also, boolField is already present in the current version on Hackage; it's just optionalField that's missing