Re: merging “processes” and “restrictions”

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

Dear Ricardo,

I agree with your "graph proposal".

I have the same conclusion as you, that there is unconvenient duplication.

As we discussed elsewhere, I see the process as "pure functions" and
the aim of the workflow  is to glue them together by writing the
graph. I am not clear yet about how to manage the inputs/outputs
(fixed in the definition of the process or fixed in the workflow) and
from my point of view your proposal is better than the restriction
way.

I am still failing to write a macro that inplements my "view":
 - write the graph
 - collect the inputs/outputs
which somehow is similar to your proposal. I pick the name `dataflow'
for this not-yet-immplemented macro name.

Well, instead of your graph name, I propose dataflow or stream or datastream.


What do you think?


All the best,
simon

On Sat, 19 Jan 2019 at 09:56, Ricardo Wurmus <rekado@elephly.net> wrote:
>
> Hi,
>
> I think it is unfortunate that workflows have two fields for specifying
> processes: one is “processes” the other is “restrictions”.  It seems to
> me that we can do without “restrictions” by relaxing the requirements
> for the “processes” value.
>
> The use of both fields sometimes makes it necessary to wrap the whole
> workflow definition in a let binding so that both fields can access
> identical values:
>
>   (let ((eat-fruit (eat "fruit"))
>         (eat-veges (eat "vegetables")))
>     (workflow
>      (name "simple")
>      (processes
>       (list greet
>             eat-fruit
>             eat-veges
>             sleep
>             bye))
>      (restrictions
>       `((,eat-fruit ,greet)
>         (,eat-veges ,greet)
>         (,sleep ,eat-fruit ,eat-veges)
>         (,bye ,sleep)))))
>
> This looks like a minor improvement to me because the let can be where
> it’s needed:
>
>     (workflow
>      (name "simple")
>      (processes
>       (let ((eat-fruit (eat "fruit"))
>             (eat-veges (eat "veges")))
>         (list (list eat-fruit greet)
>               (list eat-veges greet)
>               (list sleep eat-fruit eat-veges)
>               (list bye sleep)))))
>
> All of the elements of the list together is equivalent to the list of
> processes.  The “processes” field now also doubles as a “restrictions”
> field as the value can be an adjacency list of processes to their
> dependencies.
>
> For trivial processes where none of the processes depend on each other
> it would look like this:
>
>     (workflow
>      (name "simple")
>      (processes
>        (list (list A)
>              (list B)
>              (list C))))
>
> With just a little bit of extra processing before storing the value it
> could become this instead:
>
>     (workflow
>      (name "simple")
>      (processes A B C))
>
> If you’re like me you’ll find that the restrictions syntax looks rather
> verbose with all those “list”s.  Using quoting doesn’t make this any
> more readable, unfortunately:
>
>     (workflow
>      (name "simple")
>      (processes
>       (let ((eat-fruit (eat "fruit"))
>             (eat-veges (eat "veges")))
>         `((,eat-fruit ,greet)
>           (,eat-veges ,greet)
>           (,sleep ,eat-fruit ,eat-veges)
>           (,bye ,sleep)))))
>
> Can we use macros to clarify the syntax?
>
>     (workflow
>      (name "simple")
>      (processes
>       (let ((eat-fruit (eat "fruit"))
>             (eat-veges (eat "veges")))
>         (graph (eat-fruit -> greet)
>                (eat-veges -> greet)
>                (sleep     -> eat-fruit eat-veges)
>                (bye       -> sleep)))))
>
> “graph” would be a macro that takes any number of node to node
> associations, each of which are expected to be in the form
>
>     (node -> nodes …)
>
> “graph” isn’t a great name.  Maybe you can suggest a different name or
> even a character…
>
> What do you think?
>
> --
> Ricardo
>
>