Clean `<<` and `>>` implementation
The implementation of <<
and >>
is split across the multiple files and is
consistent. Need to review it, clean and remove unnecessary abstraction layers,
structural pattern matching may be used to simplify matching.
The following usage cases should be supported. The list is redundant as complex rules automatically include baseic ones.
-
>>
— connects left to right, strict (does not skip inconsistent pairs)-
Main: -
Output >> Input
- 1→1 -
Output >> Node
- 1→1, node may create new inputs -
(!) Sequence[Output] >> Node
— N→1 has a specific meaning for BlockToOneNode and corresponding input handler. Need to carefully coordinate this option with others.
-
-
Sequences: -
Output >> Sequence[Input]
- 1→N -
Sequence[Output] >> Sequence[Input | Sequence[Input]]
- N→N -
Output >> Sequence[Node]
- 1→N -
Sequence[Output] >> Sequence[Node | Sequence[Node]]
- N→N
-
-
NestedMkDict: -
Output >> NestedMkDict[Input | Sequence[Input]]
- 1→N, nested -
Output >> NestedMkDict[Node | Sequence[Node]]
- 1→N, nested -
NestedMkDict[Output] >> NestedMkDict[Input | Sequence[Input]]
- M→N, nested, matching -
NestedMkDict[Output] >> NestedMkDict[Node | Sequence[Node]]
- M→N, nested, matching
-
-
-
<<
connects to inputs, that are on the left, corresponding outputs from the right. Skips missing outputs, ignores extra outputs.-
With NestedMkDict: -
a. Node << NestedMkDict[Output]
-
Sequence[Node] << NestedMkDict[Output]
— repeat a. for each Node. -
NestedMkDict[Node] << NestedMkDict[Output]
— repeat a. for each Node.
-
-
With Mapping: -
a. Node << Mapping[Output]
-
Sequence[Node] << Mapping[Output]
— repeat a. for each Node. -
Mapping[Node] << Mapping[Output]
— repeat a. for each Node.
-
-
Other considerations:
-
Processing of Mapping
may be done by wrapping it by theNestedMkDict
. Therefore an option for Mapping may be used in all options when NestedMkDict are used. -
Currently the allowed syntax includes Output >> Input >> Input
and similar constructs. I think this should be deprecated for the visual simplicity and simplicity of implementation. -
I think we do not need to support iterables instead of Sequences, also for simplicity.
Edited by Tsegelnik Nikita