Re: merging “processes” and “restrictions”

[zimoun <zimon.toutoune@gmail.com>]

Hi Ricardo,

I have just updated the repo.
Wouawou !!

For example, I run:

 guix gc
 GUILE_AUTO_COMPILE=0 GUIX_WORKFLOW_PATH=./doc/examples/ \
  ./pre-inst-env guix workflow -r simple

and all the dance with the store shows up. Beautiful! :-)

Is it possible to turn off the test (make check) when building hello ?


Cosmetic comment. :-)
About the `A -> B' which means A depends on B.
To me, the arrow is counterintuitive, notationally speaking. :-)
Because the data flow is going from B to A.
Even if this notation is usual when speaking of dependencies and graph.


> >> Or like this assuming that all of the processes declare inputs and
> >> outputs *somehow*:
> >>
> >>   (workflow
> >>    (name "simple")
> >>    (processes
> >>      (eat "fruit") (eat "veges") greet sleep bye))
> >
> > With this, I do not see how the graph could be deduced; without
> > specifying the inputs-outputs relationship and without specifying the
> > processes relationship.
>
> This will only work if these processes declare inputs and outputs and
> they can be matched up.  Otherwise all of these processes would be
> deemed independent.
>
> I still wonder how processes should declare inputs.  The easiest and
> possibly least useful way I can think of is to have them declare
> abstract symbols.
>
> --8<---------------cut here---------------start------------->8---
> (process: 'bake
>   (data-inputs '(flour eggs))
>   (procedure '(display "baking"))
>   (outputs '(cake)))
>
> (process: fry
>   (data-inputs '(flour eggs))
>   (procedure '(display "frying"))
>   (outputs '(pancake)))
>
> (process: (take thing)
>   (procedure '(format #t "taking ~a." thing))
>   (outputs (list thing)))
>
> (workflow: dinner
>   (processes
>     (list (take 'flour) (take 'eggs) fry bake)))
> --8<---------------cut here---------------end--------------->8---
>
[...]
> Given this information we can deduce the adjacency list:
>
>   (graph
>    (fry  -> (take 'flour) (take 'eggs))
>    (bake -> (take 'flour) (take 'eggs)))
>
[...]
> I’m not sure how useful this is as a *generic* mechanism, though.  One
> could also use this as a very specific mechanism, for example to have a
> process declare that it outputs a certain file, and another that it
> takes this very same file as an input.

>From a simple user perspective, I find more readable the current
version with `graph'. Because I am able to see the flow even if I do
not know about the processes fry, bake and take.
With:
 (graph
   (fry -> (take 'flour) (take 'eggs))
   (bake -> (take 'flour) (take 'cheese)))
the dependency graph is clear even if I have no idea about all the processes.
With:
  (list (take 'flour) (take 'eggs) fry bake)))
I need to know how the process `fry' is built to deduce what this
workflow will do.

>From my point of view, the `let' part fixes the entry point or some
specific location of outputs (for debugging purpose?).

(define (eat input output)
 (process
  (name "Eat")
  (data-inputs input)
  (outputs output)))

(define (cook input output)
 (process
  (name "Cook")
  (data-inputs input)
  (outputs output)))

(define (take input output)
 (process
  (name "Take")
  (data-inputs input)
  (outputs output)))

(workflow
  (processes
    (let ((take-choc (inputs take "/path/to/chocolate"))
          (take-cake (outputs take "/path/to/store/cake"))
          (miam (outputs eat "/path/to/my/mouth")))
    (graph
       (cook -> take-choc)
       (take-cake -> cook)
       (miam -> take-cake)))

If the inputs/outputs are not specified in the `let' part, then they
are automatically stored somewhere in /tmp/ or elsewhere and then
(optionally) removed when all the workflow is done.

I imagine `inputs'/`outputs' returning a curryfied process, somehow.

And similarly about options, e.g,
 (define* (cook input output #:optional temp-woven)
     blah)


Does it make sense ?


> (I don’t know how this would relate to the content addressable data
> store.  Maybe it doesn’t at all.)

I do not know neither. :-)


All the best,
simon