[Taoscript-lang] rot13.tao reveals Tao (or documentation?) shortcoming :-<
Status: Beta
Brought to you by:
phoolimin
|
From: Josef 'J. S. <ju...@gm...> - 2005-06-02 08:41:59
|
Hi!
At the end of this message I added rot13 written in Tao. If you do not
know it: rot13 is a Cesar encoding; an implementation of rot13 using
standard Unix tools is
tr '[a-zA-Z]' '[n-za-mN-ZA-M]'
The Tao script works flawlessly - for a single line. I am an old Linux
hand so I have two questions not answered by the documentation.
- How to make the program iterate over all input provided via
standard input unless EOF is encountered?
- How to access command line arguments?
The reason is obvious: Without these two means it is impossible to
write Unix style tools in Tao that are capable of both processing
input streams and files. Bad.
I am pretty sure most people who know why this is bad but perhaps not
all do. I therefore describe my motivation for having such
capabilities.
A typical problem when dealing with data is this:
You have to implement operation F on data of the same type that is
provided by different sources and need to be provided to other people.
While the data are in principle always of the same type you have to
deal with input formats i1, i2, i3, ..., iN and output formats o1, o2,
o3, ... oM. If you implement all functionality in one program you end
up with always modifying the program whenever a new source is added.
Bad. A data processing program should only be modified if the
information it processes, the information it extracts or the way in
which the information input is transformed into the information output
(i.e. the algorithm) changes but it should *never* need to be modified
if the representation of the data is changed without actually
modifying the informational content. It's simply the "never change a
winning team" (aka "never touch a running system") issue. It is much
better to have filters that transform i1, i2, i3, ..., iN into a
generic input format I, then process this input with a program that
produces some generic output format O and have this output then
transformed by other filters into any of o1, o2, o3, ..., oM.
A great example of tools that follow this style is netpbm that comes
with filters that transform an awful lot of graphics formats into a
PBM (a trivial graphics format) and others that transform PBM into an
awful lot of output formats (there are also programs that can do
quantization and the like so F is known to exist as well :-). If
netpbm does not support your format simply write two tools: One that
transforms the format to PBM and one for the opposite direction. Now
netpbm supports your format.
Enough motivation, here's code (note that it does not work on EBCDIC
systems!):
a = read();
orig = unpack(a);
rot = { };
foreach(orig:x) {
if (x >= unpack("a")[0] && x <= unpack("z")[0]) {
x = (x + 13 - unpack("a")[0]) % 26 + unpack("a")[0];
} else if (x >= unpack("A")[0] && x <= unpack("Z")[0]) {
x = (x + 13 - unpack("A")[0]) % 26 + unpack("A")[0];
}
rot.insert(x);
}
print (pack(rot), "\n");
Before I forget to ask: Does "rot[rot.#] = x" fail on purpose instead
of meaning the same as "rot.insert(x)"?
Josef 'Jupp' SCHUGT
--
"NO" to the European constitution means "YES" to democracy, not "NO" to
Europe - presently Europe as a whole is governed by a central committee
while the parliament only has very limited power. Thank you, France.
|