In this linked document for Magritte, it describes its pipeline operator in a section called "Syntax Design - Linear Composition: Why Not Lisp?".<p><i>..The problem is the prefix-only calling convention that requires a back-and-forth movement of the cursor, and causes the expression to expand leftwards, opposite of the direction of the user’s typing.</i><p><i>While some languages have some support for linear composition using operators such as Clojure’s arrow macros or OCaml’s |> operator, the integration of these macros with the underlying subsystem is shallow.</i><p>I question this last statement.<p>Just this weekend I was reading about Hy's (based on Clojure's) threading macros:<p>"Threading macros, also known as arrow macros, convert nested function calls into a linear flow of function calls"<p><i>-> (or the threading macro) is used to avoid nesting of expressions. The threading macro inserts each expression into the next expression’s first argument place.</i><p><i>->> (or the threading tail macro) is similar to the threading macro, but instead of inserting each expression into the next expression’s first argument, it appends it as the last argument.</i><p>At least to me this seems far from "shallow" and even more useful/flexible than the pipeline operator.
This looks cool! I linked it on my wiki page of alternative shells:<p><a href="https://github.com/oilshell/oil/wiki/ExternalResources" rel="nofollow">https://github.com/oilshell/oil/wiki/ExternalResources</a><p>(which is cited on the first page of the thesis!)<p>I hope that Oil can a lot of these things in a backward compatible way, but I still have to read it and understand it more.
The twist here is that this language doesn't use actual pipes; it just creates representations of pipes that can be used by a different interpreter.
> The implementation is written in Ruby, and the source code is publicly available at <a href="https://github.com/prg‑titech/magritte" rel="nofollow">https://github.com/prg‑titech/magritte</a>.
<p><pre><code> 1.4 The Desktop-Scripting Problem
Related to the shell-language design problem is the desktop-scripting problem:
How should unrelated programs written in different languages be integrated—especially
in an ad-hoc manner in a desktop environment? Such a task can require a large
amount of glue code, written by users who are unfamiliar with the inner workings of
the programs they are using. Notable attempts at solving the desktop-scripting prob-
lem include the TCL language [Ousterhout, 1989] and Guile Scheme [Blandy, 1998].
However, while most of these approaches use a large, robust language, it still remains
difficult to integrate them with external programs—instead putting the burden on
those programs to integrate with their system. We believe a shell-based approach is
promising
</code></pre>
Hmm, Scheme as a large language? Well, I don't know much about the extensions Guile Scheme has over RxRS, would hope for someone to add info here.
It is mind boggling that despite the name, they did not (given the (I assume) joke with the name) say, "Ceci n'est pas une pipe" anywhere in the paper. Only once does the phrase, "This is not" occur, but completely out of context of Magritte's most famous painting.<p>I'm serious - this isn't Joke 101, but this is Marketing 101 in some respects.
I wrote clojure for a while. Forward chaining basically facilitates pipe based programming. When it fits it’s great, but when it doesn’t try code is ugly.<p>Some computations just want to be imperative. IMO, if you can avoid developing programming fetishes; power to you.
Looks interesting!<p>Side note: here's another "Magritte" from 1983: <a href="http://reports-archive.adm.cs.cmu.edu/anon/scan/CMU-CS-83-132.pdf" rel="nofollow">http://reports-archive.adm.cs.cmu.edu/anon/scan/CMU-CS-83-13...</a>. Is there a connection?
Reminds me of nushell, which pipes around 2D tables (which can instead store hierarchical structured data, for example when reading toml files): <a href="https://news.ycombinator.com/item?id=20783006" rel="nofollow">https://news.ycombinator.com/item?id=20783006</a>
Except for the comparisons with Lisp in the third section, I thought the idea of pipes with complex data structures to be a pretty neat idea. Also, this is for a Master’S Thesis from the University of Tokyo? That looks like a lot of work for a MS thesis.
Taking "pipe-based programming" to its logical conclusion results in <a href="http://www.linusakesson.net/programming/pipelogic/" rel="nofollow">http://www.linusakesson.net/programming/pipelogic/</a>
The problem as it's defined in this thesis sounds a lot like the problem of microservice architecture. I'm curious how something like protobufs would compare in solving this problem
Mario provides an implementation of shell pipes for Python.<p><a href="https://github.com/python-mario/mario" rel="nofollow">https://github.com/python-mario/mario</a>