Julius @jules , Thank You very much for this RFC around enhancing the previous Linux/Unix Pipe syntax which is a very helpful foundation and a natural fit for distributed processing, but in this iteration I hope we can elevate (or is that continue ? See below **) the language syntax to a slightly higher abstraction layer using mathematical notation, while simultaneously keeping the super fast and efficient Automatic vectorization gears hidden/encapsulated to achieve this >> Automatic vectorization - Wikipedia
So also request support syntax for Function Composition (computer science) described here >>
" The ability to easily compose functions encourages factoring (breaking apart) functions for maintainability and code reuse. More generally, big systems might be built by composing whole programs ."
And so here is another example in a similar proposal that seems to have come out of some previous RFC / design work :
It’s especially important ( to provide an alternative to current |> syntax ) when you are using Julia for data analysis, where you commonly have data transformation pipelines.
In particular, Pandas in Python is convenient to use because you can write things like df.groupby(“something”).aggregate(sum).std().reset_index() , which is a nightmare to write with the current |> syntax.
@@ Function chaining · Issue #5571 · JuliaLang/julia · GitHub
**(or continue ? See this >> ) IF this >> My mental load using Julia is much higher than, e.g., in Python. How to reduce it? - #5 by rdeits << is already implemented as it appears to be , it would already address what I’m requesting here per this statement :
I think what you’re talking about is “fluent interfaces”, and it’s true that we don’t really do that in Julia, at least not in the same way. You might find the |> operator useful, since you can do:
> x |> f |> g
as an alternative notation for g(f(x)) .
.
However as @rdeits has previously NOTED there is a “missing” functionality >> Notably, in a fluent interface, there is no way to chain a function that isn’t a method of the returned object. So if sort() is a generic function (and not a method of whatever drawInContext returns), then you can’t do:
line.mirror.drawIncontext(ctx).sort()
So if all ^the above^ has been said and done and the g(f(x)) notation is
in place , then for this RFC I’d like the proposed new PipelessPipes.jl Package Design to be mostly about Julia compiler / LLVM optimizations similar to JuliaFolds · GitHub for optimizing compilation of the new functional composition syntax to automatically evaluate how to /if can SIMD / Vectorize ** / Parallelize / Thread the Nested functions – As a starter for more background consider searching reading about SIMD designs >>
The hardware handles all alignment issues and “strip-mining” of loops. Machines with different vector sizes would be able to run the same code.[6] Clang LLVM ( used by Julia which ) calls this vector type “vscale”.
-and-
https://discourse.julialang.org/search?q=SIMD
Re: Existing Vectorize syntax ** ( highly desirable to keep compatible with proposed new functional composition syntax Package Design )
https://docs.julialang.org/en/v1/manual/functions/#man-vectorized
HTH
Ps > CCing Some others in for possible interest or additional insight (like is this possible ? LOL ; and would it help them ) :
@rdeits @MikeInnes @tkf