summaryrefslogtreecommitdiff
path: root/info/challenges/aro-bend/exercise.007
diff options
context:
space:
mode:
authorNorbert Preining <norbert@preining.info>2019-09-02 13:46:59 +0900
committerNorbert Preining <norbert@preining.info>2019-09-02 13:46:59 +0900
commite0c6872cf40896c7be36b11dcc744620f10adf1d (patch)
tree60335e10d2f4354b0674ec22d7b53f0f8abee672 /info/challenges/aro-bend/exercise.007
Initial commit
Diffstat (limited to 'info/challenges/aro-bend/exercise.007')
-rw-r--r--info/challenges/aro-bend/exercise.00750
1 files changed, 50 insertions, 0 deletions
diff --git a/info/challenges/aro-bend/exercise.007 b/info/challenges/aro-bend/exercise.007
new file mode 100644
index 0000000000..306f7e846f
--- /dev/null
+++ b/info/challenges/aro-bend/exercise.007
@@ -0,0 +1,50 @@
+[Posted to info-tex on 4 Nov 91; see exercise.004]
+**********************************************************************
+*** Exercise 7 (hard):
+
+In the September 1991 issue of Dr. Dobb's Journal, in an article
+`Little Languages, Big Questions' (pp. 16--25), Ray Vald\'es
+described a `little language' as a part of a more complex
+application that is
+
+ partitioned into two (or more) nested components: a core module
+ that provides a primitive set of services for an application area
+ (the ``engine''), and a surrounding module that provides
+ programmatic access to these services. The surrounding module is
+ typically a language interpreter for a simple, easily parsed
+ computer language--a ``little language''.
+
+Since TeX seems to fall into this category, I wonder if any Dr. Dobb's
+readers who know TeX tried their hand at the challenge given in a
+sidebar (`How Strong Is Your Little Language')?
+
+ [An] informal benchmark of a language's computational power is the
+ programming exercise that Ken Thompson (coauthor of Unix) used to
+ pass the time in college. ... The goal is to write the shortest
+ self-reproducing program: ``More precisely stated ... to write a
+ source program that, when compiled and executed, will produce as
+ output an exact copy of its source.''
+
+When I tried it it turned out to be a real challenge for me. In the
+Unix world, for conventional compiled languages, the problem as
+originally stated can assume output on the `standard output' stream;
+but TeX already clutters up standard output with some of its built-in
+messages. This leaves three alternatives in refining the statement of
+the problem to be meaningful for TeX:
+
+1. Write a TeX program that includes the built-in messages in its
+source in such a way that it exactly fulfills the the original problem
+statement with standard output as the output stream.
+
+2. Pretend the built-in messages don't exist and write a TeX program
+that reproduces an exact copy of itself (with no extra garbage)
+in the middle of the built-in messages.
+
+3. Write on a different output stream.
+
+Take your pick, any or all of the above, and see what you can come up
+with. I have solutions for 2 and 3 but have not gotten around to really
+thinking about 1 yet. I believe it will require at least a different
+algorithm than the other 2, if it is not impossible.
+
+**********************************************************************