[Oberon] Need V4 Code for trivial task.

[Chris Burrows]

Just to clarify: "The shell syntax for pipelines forces them to be linear,
although the operating system permits processes to be connected by pipes in
a general graph." My understanding is that, in general, processes further
down the pipeline do not have to wait for the previous processes to finish
before they can start. 

The process is described further in the following document written by Dennis
Ritchie in 1978: 

"The UNIX Timesharing System - A Retrospective"

https://www.bell-labs.com/usr/dmr/www/retro.pdf

@Chris Glur: MS-DOS from version 2.0 onwards also has a limited piping
system. You can still use this in a Windows 10 system via the "command
prompt" e.g. try the following command sequence to get a directory listing
sorted by descending date and then paged to the screen:

cmd
dir /O-D | more

Regards,
Chris Burrows
CFB Software
http://www.cfbsoftware.com



> -----Original Message-----
> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of
> Skulski, Wojciech
> Sent: Wednesday, 7 December 2016 2:15 PM
> To: ETH Oberon and related systems
> Subject: Re: [Oberon] Need V4 Code for trivial task.
> 
> > But it's not as modular/simple/safe as the canonical piping syntax:
> >   InputFile |Filter1 |Filter2....|FilterN > OutputFile
> 
> 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.
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related
> systems https://lists.inf.ethz.ch/mailman/listinfo/oberon