Talk:User defined pipe and redirection operators

Yet another task without a task

this task has several potential areas of activity:

1. syntax (right to left infix notation)
2. serialization and deserialization
3. command chaining
4. dealing with external programs

Currently, it's not clear which of these areas of activity are desired, and there are at least 15 possibilities (considering only the inclusion or exclusion of each area of activity, and not considering variants within each area). --Rdm 01:45, 13 September 2011 (UTC)

I don't think the task wants any of the above. Seems the goal is to define stream-like objects where each one's output can be taken up by another as input, and the task's focus is to device a mechanism to drive data through such a chain. BTW, since data flows unidirectionally, it definitely does not require coroutines, all you need to do is have the object at the output end to pull data from upstream on-demand. The problem of the task: it's asking to much. Tail, head, uniq, sort, grep, wc, file io, subshell, redirect-in, redirect-out, pipe -- it's what, reliving 40 years of unix experience in a flash? --Ledrug 02:04, 13 September 2011 (UTC)

As a general rule, languages already implement routines where on object's output can be taken by another as input. In fact, it's hard to think of any language which implements objects which does not implement something like message passing. Even functional languages let you pass the output of one function to another function. So... that seems a bit trivial? And if you are going to require one of them starts before the other completes, that gets into time slicing or multiprocessing or co-routines? But some OS pipe implementations (*cough*windows*cough*) buffer the full output from one command before starting the next... --Rdm 10:43, 13 September 2011 (UTC)

I'm looking for "User defined pipe and redirection operators" in particular. However - you are right - how the actual commands are run (sequentially or concurrently) is relevant. {Naively I was thinking nobody would want to actually implement "MSDS" sequential (MSDOS caches intermediate result in a file, faking piping, without multitasking)... oh... Microsoft did and conquered the world.... sigh}

BTW you don't need to actually do any message passing, or multitasking. It can be done totally within one process using co-procedures.

However (I believe) the "&" operator requires at least threads. And... I just figured out how to define "&" in Algol68... cheers! :-) I'll make the "&" operator a language "kudos" if achieved.

This is starting to sound like an OS CLI implementation task... That said, yes, unix trailing & (as opposed to &&) requires either threading or coroutines. That said, & could be implemented as "defer this operation until you have nothing else to do", in a single threaded environment -- this is equivalent to a time-slice implementation where backgrounded tasks do not get any resources (or to a perceived behavior similar to that of a time slice implementation under heavy load). --Rdm 13:11, 13 September 2011 (UTC)

Adhere to the syntax of the specific language where required, eg the use of brackets and names of operators.

For example: I had to use the operator "=:" instead of the standard "|" pipe-char as the "|" char has a special (and fixed and unchangeable) meaning in Algol68. (I could have used Douglas McIlroy's "^" char for piping maybe? but =: reads better.)

Here is the "Sample shell script", but rewritten in Algol. <lang algol68>PR READ "prelude/general.a68" PR

MODE REC = STRING; FORMAT rec fmt = $g$;

PR READ "Coroutine_pipe_operators.a68" PR PR READ "Coroutine_pipe_utilities.a68" PR

FLEX[0]STRING aa;

cat (

   head(4,) < "List_of_computer_scientists.lst",
   cat("List_of_computer_scientists.lst") =: grep(ALGOL,) =: tee("ALGOL_pioneers.lst"),
   tail(4,"List_of_computer_scientists.lst")
 ) =: sort =: uniq =: tee("the_important_scientists.lst") =: grep "aa" >> aa;

printf(($"Pioneer: ", $" "g$, aa, $l$)) </lang> I have almost finished, and hope it will take less then 300 lines of code.

So far:

$ wc -l *Coroutine_pipe*s.a68
 174 Coroutine_pipe_operators.a68
  58 Coroutine_pipe_utilities.a68
  20 test_Coroutine_pipe_operators.a68
 252 total

This task should be OK in python, especially the operators, and also Ada. I figure the GNU C has a fair chance. C++ should be able to handle the operator overloading.

I'm not familiar enough with other languages to make any real comment. [Ocaml can do any thing! (apparently)] :-) ... Go should be real interesting!

BTW: Here is a complete implementation of "tail", notice it uses a sliding window: <lang algol68>PROC tail yield rec = (INT n, CONJUNCTION args, YIELDREC yield)VOID:

 FOR argn FROM LWB args TO UPB args DO
   INSTREAM rec gen = args[argn];
   CASE rec gen IN
     (FILENAME name): IF LWB args = UPB args THEN yield("==> "+name+" <==") FI
   ESAC;
   [0:n-1]REC window; INT window end := -1;
 # FOR REC rec IN # cat(rec gen)(#) DO #
 ##   (REC rec)VOID:
        window[(window end+:=1) MOD n]:= rec
 # OD #);
   done:
   FOR line FROM window end-n+1 TO window end DO
     IF line>=0 THEN
       yield(window[line MOD n])
     FI
   OD
 OD;

PROC tail = (INT n, CONJUNCTION args)GENREC:

 tail yield rec(n, args ,);

1. Define an optional monadic TAIL OPerator #

OP TAIL = (INT n)MANYTOONE: tail(n,);</lang>

Note that this "tail" implementation requires just one argument "n", keeping things simple to satisfy the use of tail in the "Sample shell script". The task is not asking for reinvention of head/tail etc. just enough to run the "sample shell script" while retaining the basic functionality of the cloned shell utility, basically just a proof of concept for a particular language.

Rationale: Pipes appear in a hoard of different languages. It always bugs me when a feature is cemented into a language and hence cannot enhanced. Being such a wide spread and useful concept, it would be nice to simply define a few new operators and have piping/redirection available in the new language.

Indeed, having to the ability to add pipes & redirections to a language means a coder can evolve the pipe/redirection definition to match the environment. For example the pipe/redirection operators defined above are "strong typed" (currently string), hence the compiler will detect data of the wrong type (currently string) being piped to the wrong "coprocedure" type and report with a compile time semantic error, hence one unit test script just wrote itself!! (joy).

NevilleDNZ 03:26, 13 September 2011 (UTC)