Closed snowleopard closed 6 years ago
I’m not bothered by the task descriptions. To me it seems great to say
sprsh1 = mkTasks [ (“B1”, formulaB1)
, “B2”, formulaB2), …]
I don’t know what to make of the Buck thing though.
I like it!
recursive
etc. to pass a Task
to the process
function. That will bring further simplifications and generalisations (e.g. you can write cloud Excel, which currently reordering
can't express). I think this is the big reason we're doing the refactor.c
Applicative/Monad with a ReaderT, and then you'd not need to care about fetch
once more.What about the Buck business?
There are two formulations of Buck:
Our current formulation can only do 2, and we had hoped Task would let us do 1 as well, but we now know it won't, it will be the same power as we currently have. In reality Buck does 2, so 1 is perhaps a more academic exercise anyway (it would have bad O complexity if implemented in real life).
I think Buck is a case of a hoped-for benefit not materialising, but not a big deal overall.
Thanks for the comments! I can see you're both in favour of going ahead with this change. I'm still not convinced -- for me, the Buck story was really convincing, but it's gone now.
To respond to some of your comments:
@simonpj:
To me it seems great to say
sprsh1 = mkTasks ...
You can still say this with type Tasks c k v = forall f. c f => (k -> f v) -> k -> Maybe (f v)
. You just need to pick a different mkTasks :: [k, Task c k v] -> Tasks c k v
. So, this doesn't seem to be a factor here: you can keep the current implementation (and the paper!), and define a SingleTask
-- we might also call it Formula
or Compute
-- with mkTask :: [k, Compute c k v] -> Task c k v
. This doesn't require changing any of the existing abstractions.
@ndmitchell:
The new formulation is more direct.
Yes, I agree with this.
This is step 1 - we haven't switched
recursive
etc. to pass aTask
to theprocess
function. That will bring further simplifications and generalisations
But there is an alternative: pass Tasks
to process
, which essentially turns it into another build system and our algorithms simply transform one build system into another, as in #2. This approach allows to handle both Buck formulations, so it is more general. It might also be simpler, since we don't need to introduce new types for process
(but I haven't yet checked that this works for reordering
).
if we did focus on them I'm sure we'd combine the
c
Applicative/Monad with aReaderT
, and then you'd not need to care about fetch once more.
I'm not sure I know exactly what you mean. Can you show how this would work with sprsh1
?
Also, don't forget that if we go ahead with this switch, we'll probably have to translate it to the paper, which might just be a too large revision for reviewers to agree with it. This is hardly a good argument for a technical discussion, but is more of an 'engineering concern' :-)
@snowleopard - shall we discuss over lunch? I'm free from now on.
@ndmitchell Good idea -- I'm ready!
OK, given the promise of glorious task transformers I'm merging this :)
@ndmitchell @simonpj I have mixed feelings about this.
Here are the new types:
Good:
Some functions got simplified. For example:
Bad:
In many cases the simplification is somewhat misleading. For the above example, we still need to fiddle with
Maybe
, but just in a different place -- here is a snippet fromtopological
:Task descriptions became noisier. One could introduce a combinator for
Just . Task
but still it seems harder to read/understand the resulting code because of lambdas withfetch
:Task
to Buck'sprocess
function and hope that it can extract transitive inputs (sources) from it: it really needsTasks
for this! A singleTask
only allows you to extract information about your immediate dependencies. So if we really want to be able to perform global analysis of the dependency graph insideprocess
we need to passTasks
to it. And maybe this is what we should do: see #2.In summary, I'm leaning towards keeping the old abstraction. I don't think splitting into
Tasks
andTask
brings us much, and -- on average -- it seems to lead to less elegant code.