<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    W,<br>
    Thank you for saying that!<br>
    I was paid $3,000 in 1979 by Three Rivers Computer to implement a
    Unix shell with pipes.<br>
    I did that on a <a
      href="https://en.wikipedia.org/wiki/Terak_8510/a">Terak</a>
    machine written in Pascal.<br>
    I never want to go back to that form of "linear thinking". <br>
    I greatly prefer the GUI Oberon approach.<br>
    -Doug Danforth<br>
    <br>
    <div class="moz-cite-prefix">On 12/6/2016 7:44 PM, Skulski, Wojciech
      wrote:<br>
    </div>
    <blockquote
cite="mid:CY1PR07MB2213F8759FD6F5DAE29F85F0FF850@CY1PR07MB2213.namprd07.prod.outlook.com"
      type="cite">
      <blockquote type="cite">
        <pre wrap="">But it's not as modular/simple/safe as the canonical piping syntax:
  InputFile |Filter1 |Filter2....|FilterN > OutputFile
</pre>
      </blockquote>
      <pre wrap="">
Unix pipes are based on a certain programming paradigm which is different from the Oberon System and from GUI-based systems in general. The piping paradigm is based on the notion of a program transforming input into output, which was inspired by the chain "card reader --> computer --> card punch". You may recall:

PROGRAM CALC (INPUT, OUTPUT)

In Unix input is named stdin, output is named stdout, but the idea is the same. Piping means that the output of one program becomes the input to another one. It can be achieved with punched card decks, files on disk, or FIFO in memory. The technical details are secondary. The key to understanding is the word "sequential". Unix pipes can give you an illusion of concurrent execution, but the data is in in fact transformed sequentially.

The GUI paradigm is a different one. GUI systems do not have one input and one output. GUI can take its input from anywhere and it can put the output anywhere. The GUI is manifestly parallel, even though under the hood all the processing is performed sequentially. But here the sequential processing becomes a secondary implementation detail. The paradigm itself is parallel.

After saying all this I would declare that you are advocating a paradigm which Oberon System (and any other GUI system) has explicitly disposed of. Your piping can be implemented in Oberon with an executable program whose interface would explicitly say PROGRAM (input, output) or "function main (stdin, stdout)", or something compatible. There are Oberon compilers which will produce this kind on an executable. Oberon System is not one of of them.

W.
--
<a class="moz-txt-link-abbreviated" href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems
<a class="moz-txt-link-freetext" href="https://lists.inf.ethz.ch/mailman/listinfo/oberon">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a>

</pre>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Danforth of the Greenwood</pre>
  </body>
</html>