
Robert Jones wrote:
On Thu, Jan 6, 2011 at 11:57 PM, Neil Groves
mailto:neil@grovescomputing.com> wrote: Ignoring the implementation issues for a moment I would like to explain my rationale for the current syntax. I consider the range adaptors to be orthogonal to algorithms. I therefore perceive a syntactic difference between the application of algorithms and adaptors to be an advantage. With your example above I find the first version of the code more instantly understandable since the most-significant operation (copy) is at the start of the line. Therefore my personal opinion is that it is undesirable to extend the pipe syntax to the application of algorithms.
I'm not entirely convinced by the 'orthogonality' view - it is certainly one way of looking at adaptors vs algorithms, and is not without merit, but I do find the fully piped syntax a very natural expression of design intent. If the implementation difficulties were not prohibitive it is a syntax I'd like supported.
-1 Neil's range rationale derives from the origins of (Thorsten's)range library and David Abrahams' interator adaptor library, all of which IIRC derive from Gary Powell's View Template Library. This history has probably biased my viewpoint. In my mind a(n adapted) range is a view onto some sequence of items. That 'view' may include filters, orders, item-transforms, etc. The operator| appends a transform to the view to left of the '|' returning another view. None of this actually creates/modifies/destroys any of the left most sequence's items. It's akin to creating a function object. Changing the meaning of operator| in this context to also 'execute' that function object would muddy the IMHO existing clearly defined meaning of such expressions. Jeff