[vtkusers] Operational overload?

[Pat LeSmithe]

Has there been work to enable the composition of VTK pipelines using
generic and/or functional techniques, e.g., something along the lines of

[ ... bunch of declarations ... ]

// Simple stuff
renWin += renderer * sphereActor * sphereMapper * sphere;

// Intermediate stuff
otherMapper += toast(slice(bagel));
renderer += otherActor * otherMapper;

// If operator+() can substitute for append():
otherMapper += polydata + \
		probe(gradmag(source1), contour(source1));
// Otherwise:
otherMapper += append(polydata, \
		probe(gradmag(source1), contour(source1)));

// Other stuff
renderer += camera;
renderer += axes;
axes += tprop;
renWin += iren;

// Bad stuff
renWin += sphere;
otherActor *= gradient(renWin) - slice(toast(bagel));

[ ... plus customizations using operator->() ... ],

which automatically connects ports, adds props, etc.  Ideally, an
implementation should "do the right thing" unless there's ambiguity and
check for logical consistency to the extent possible at compile time.
It should also complain if a particular filter can't accept an
unstructured grid, say, as input.  With a somewhat more expressive
syntax, this could make it easier to outline/determine at a high level
what a piece of code does.  This is not trivial even for many VTK examples.

It's probably obvious that I haven't thought it all through, and I
definitely don't claim originality.  It does seem that with the
appropriate constructs --- multiple inheritance, templates, traits,
maps, policies, concepts? --- the C++ preprocessor could enforce a
consistent and powerful "algebra" on the "category" of VTK objects and
the filters acting on them.  I'm even less familiar with Python, Tcl,
and Java, but Python, at least, appears to be more than capable.

If VTK's demand-driven pipeline is essentially a form of lazy
evaluation, is a Haskell wrapper worth pursuing? :)