Anonymous user
Talk:User defined pipe and redirection operators: Difference between revisions
Talk:User defined pipe and redirection operators (view source)
Revision as of 22:24, 13 September 2011
, 12 years ago→more ambitious than unix: my thoughts, sketched in python code
(→more ambitious than unix: new section) |
(→more ambitious than unix: my thoughts, sketched in python code) |
||
Line 98:
Also, there's an implicit task "requirement" here, that output be characters. And a secondary implicit task "requirement" here that files be supported (since that what redirection means) which would also suggest that the task needs to support file reference by name. And, finally, in unix, the commands are (as a general rule) external programs, but it's not clear if this task allows for that kind of implementation. --[[User:Rdm|Rdm]] 13:17, 13 September 2011 (UTC)
== more ambitious than unix ==
The task currently says "Pass each record on as soon possible running all filters/procedures concurrently."
But unix does not know anything about records and passes blocks of characters which typically do not represent complete records or complete lines (except in non-portable contexts where the programs have records which match the OS buffer block size). Meanwhile, in a non-multi-tasking language "as soon [as] possible" conflicts with the task requirement "Specifically do not cache the entire stream before the subsequent filter/procedure start".
Also, there's an implicit task "requirement" here, that output be characters. And a secondary implicit task "requirement" here that files be supported (since that what redirection means) which would also suggest that the task needs to support file reference by name. And, finally, in unix, the commands are (as a general rule) external programs, but it's not clear if this task allows for that kind of implementation. --[[User:Rdm|Rdm]] 13:17, 13 September 2011 (UTC)
I think the confusion is that the task is using "shell" terminology such as "pipe" & "redirect". This "terminology" created the expectation that the task ''needs'' to use actual OS based "pipes", "processes" and shell commands. Basically the appearance that "shell like stuff" is being done ''creates'' the expectation that the task ''mandates'' the code to create some king of "CLI" (command line interpreter). This is not the actuality.
In essence that is required is the creation of the operators "<", "|", ">", "<<" & ">>", with the basic plumbing such as "cat" & "tee".
Here are my thoughts, sketched in python code, not the code ''does not'' require OS pipes, neither does it require OS multitasking. Note also: data is being passed as "rec", this could be a string, but the key point is that (essentially) in this sketch only a one record buffer is required, and this is actually only the argument list itself.
<lang python>#!/usr/bin/env python
class Filter(function):
def __init__(self, code):
self.code=code
def __or__(self, next_cmd):
for rec in self.code():
yield(next_cmd(self))
def __gt__(self, filename):
file = open(filename, "w")
for rec in self.code:
print >> file, rec
def __rshift__(self, filename):
file = open(filename, "a")
for rec in self.code:
print >> file, rec
# some more subclass attributes require to actually call "code" by proxy #
def cat_code(args):
for file in args:
for rec in open(file,"r"):
yield(rec)
cat = Filter(cat)
def grep_code(pattern, args):
for arg in args:
for rec in arg:
if pattern in rec:
yield rec
grep = Filter(grep_code)
cat("List_of_computer_scientists.lst") | grep("ALGOL") > "ALGOL_pioneers.lst"</lang>
I hope that helps.
[[User:NevilleDNZ|NevilleDNZ]] 22:24, 13 September 2011 (UTC)
| |||