flupe / achille Goto Github PK

Currently I have the following primitive task/program:

match
  :: (Eq a, Binary a) 
  => Pattern -> (Task m Path -> Task m a)
  -> Task m [a]

The first thing we could do is lift the Pattern argument to the world of tasks:

match
  :: (Eq a, Binary a) 
  => Task m Pattern -> (Task m Path -> Task m a)
  -> Task m [a]

Still, the biggest problem right now is that match is part of the core definition of Program. But why so?

First, I think it would be beneficial to split match into the following:

glob :: Task m Pattern -> Task m [Path]
mapCached
  :: (Eq a, Binary a, Eq b, Binary b)
  -> (Task m a -> Task m b)
  -> Task m [a]
  -> Task m [b]

And then define match as such:

match p f = mapCached f . glob p

Then, it means mapCached would have to be part of core programs.
The reason for that is that mapCached (and currently match) have to be aware of (task) variable uses inside their higher-order arguments to trigger subruns appropriately. Future me has to think carefully about how to abstract over this.

achille should provide better primitives for (colorful) logging, with verbosity options.

Things that should be there, probably:

• info
• warn
• error
• debug

we may want to additionally log the origin (in the haskell file) of the log message,
maybe using HasCallStack or similar.

Hi, the documentation website seems to be unavailable. Also, there is no snapshot of its subpages in the internet archive. If this is not a temporary problem, maybe you can organize the docs somewhere else?

Thanks!

It is, I should finally make this available.
Although I may want to provide additional combinators for Task m Bool?

With the old version of achille, I often wanted to extend the CLI with new options (like -D to build article drafts) and had no recourse but to reimplement the CLI from scratch. I think this is a common pattern and should be supported.

For static-site generation purposes, it's required to provide combinators such as the following:

chunks :: Task m Int -> Task m [a] -> Task m [[a]]

(We have the above already, although change info may be incorrect).

But something along those lines would be nice:

paginate :: Task m [a] -> Task m [(a, These a a)]

paginate
  :: Task m [a] 
  -> (Task m a -> Task m (i, b))
  -> (Task m b -> Task m (These i i) -> c)
  -> Task m [c]

Again, more thinking should go into this.

From my own personal use, achille has been pretty consistently fast. However, if I intend more people to use it, some time should be spent actually benchmarking the library and identifying causes for improvement.

Namely:

• The global cache is read fully, turned into a lazy bytestring and then propagated through tasks.
  Caches are typically small, but still maybe something like Conduit should be used to have more control over the space usage.

• Logging implementation is very naive so there is definitely room for improvement. I haven't looked into it yet as it's not critical, but it would be nice.

Failing tasks shouldn't influence the success of independent tasks.

achille should reexport Haskell's prelude free of ambiguity, plus common types for static-site generation (UTCTime, Day, Text).

Because of the internal abstraction of build tasks (some kind of cartesian category),
dependencies between them is fully explicit, and thus we know already which things can be run in parallel.

Putting this in the icebox for the next version, but should be fairly straightforward to implement.

Because the build graph is fully static, we could build some kind of Merkle tree
before running the generator. If all the build tasks append their hash to their local cache (by convention), we should be able to detect whether a task (or its children) has changed since the last run, and thus possibly force recompilation.

May or may not happen before the next version, but definitely for the one after that.