-
Notifications
You must be signed in to change notification settings - Fork 2
Frontend ideas
User has to create a flow diagram, using a set of operators. Data flows along the circuits to tasks which sit along straight lines.
Examples:
a
| -- apply f
b
a
/ \ -- use replicate operator to spread data across multiple tasks.
| | -- apply f and g. f :: a -> b, g :: a -> c
b c
\ / -- join output of b and c to form a tuple d=(b, c)
d
a d
/ \ | -- apply many identify tasks to d
| | |
b c |
\ / |
| | -- swap :: (a, b) -> (b, a)
/ \ | -- split operator, takes tuple (a, b) and splits the output.
| | |
| \|
| |
e f
Other operators could also be defined.
Would be a nice use of IFunctor.
Could be processed by computing a layer at a time and a series of tuples. As all data flows downwards, no graph would be needed.
E.g. final example could be given as
(a, d)
((a, a), d)
((f a, g a), d)
((b, c), d)
((c, b), d)
(c, b, d)
(c, (b, d))
(c, h (b, d))
(e, f)
Requires users to think about explicit flow between tasks. They would need to plan out the pipeline before coding up as it may be difficult to change once started.
Tasks are given names which can be used throughout the rest of defining the graph stucture.
Use a (:<-:) :: String -> Task a b -> Pipe a b operator. This would name a task with the given string.
Could then have a joining operator (>>>) :: String -> String -> Pipe a b. Analysis can then be completed on the AST formed to fill in the tasks.
Can be easily explained through an example:
example :: Pipe a b
example = do
a <- functionTask a'
b <- functionTask b'
c <- functionTask c'
d <- functionTask d'
e <- functionTask e'
return (
a >>> b >>> c
<&> d >>> c
<&> e >>> c
)This would form a graph like:
d
\
a -> b -> c
/
e
Pipeline does not need to know in advance all the tasks defined as a set of them can be inferred by inspecting the AST.
Tasks only need to state the type of the output, the input type can remain polymorphic. This is because the correct fetch method can be inferred at compile time.