mirror/ioccc
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

force use of pandoc version >= 3.1.12.2

Browse Source 
The `bin/pandoc-wrapper.sh` tool will verify that the ssytem
has a recent enough version of `pandoc(1)`.

We explain why we insist on `pandoc(1)`. version >= 3.1.12.2
in comments where the $PANDOC_MIN_VERSION is set.

Added `--wrap=preserve` as a default argument to `pandoc(1)`.
While this change will impact every HTML file generated,
we believe this will improve the ability of someone to look
at the generated HTML and correlate with the original markdown.

Changed `bin/pandoc-wrapper.sh` VERSION from "1.4.2 2024-03-17"
to "1.4.3 2024-03-18".

Performed `make www` to achieve all of the above and to generate
HTML using the new  `--wrap=preserve` `pandoc(1)` mode.
This commit is contained in:
Landon Curt Noll committed 2024-03-18 01:26:39 -07:00
1 parent 9eb7a54e9f
commit b0b212acb1
402 files changed
+37061 -55132
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

2019/lynn/index.html
+153 -226
View File
@@ -130,8 +130,8 @@
<h2 id="author"><a name="author"></a>Author:</h2>
<ul>
<li>Name: <a href="../../authors.html#Ben_Lynn">Ben Lynn</a><br>
Location: <a href="../../location.html#US">US</a> - <em>United States of
America</em> (<em>United States</em>) <br><br></li>
Location: <a href="../../location.html#US">US</a> - <em>United States of America</em> (<em>United States</em>)
<br><br></li>
</ul>
<!-- END: next line ends content generated by: bin/output-index-author.sh -->
@@ -144,32 +144,28 @@ America</em> (<em>United States</em>) <br><br></li>
<h3 id="bugs-and-misfeatures">Bugs and (Mis)features:</h3>
<p>The current status of this entry is:</p>
<pre><code>STATUS: INABIAF - please **DO NOT** fix</code></pre>
<p>For more detailed information see <a
href="../../bugs.html#2019_lynn">2019 lynn bugs</a>.</p>
<p>For more detailed information see <a href="../../bugs.html#2019_lynn">2019 lynn bugs</a>.</p>
<h2 id="to-use">To use:</h2>
<div class="sourceCode" id="cb3"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb3-1"><a href="#cb3-1" aria-hidden="true" tabindex="-1"></a><span class="ex">./prog</span></span></code></pre></div>
<h2 id="try">Try:</h2>
<div class="sourceCode" id="cb4"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb4-1"><a href="#cb4-1" aria-hidden="true" tabindex="-1"></a><span class="ex">./try.sh</span></span></code></pre></div>
<h2 id="judges-remarks">Judges’ remarks:</h2>
<p>A fully functional compiler. The example prints out the 30th <a
href="https://en.wikipedia.org/wiki/Fibonacci_sequence">Fibonacci
<p>A fully functional compiler. The example prints out the 30th <a href="https://en.wikipedia.org/wiki/Fibonacci_sequence">Fibonacci
number</a>.</p>
<h2 id="authors-remarks">Author’s remarks:</h2>
<h3 id="remarks">Remarks:</h3>
<p>A Haskell compiler. Supports a subset of Haskell more than large
enough to self-host. Like GHC with custom language extensions:</p>
<p>A Haskell compiler. Supports a subset of Haskell more than large enough to
self-host. Like GHC with custom language extensions:</p>
<ul>
<li><p><code>WeDontServeYourType</code>: Compilation failing because of
inscrutable type checking rules? Confused by the ever-growing mire of
extensions to the type system? The solution is simple: no type checking.
It also means no typeclasses. Just pass dictionaries
explicitly.</p></li>
<li><p><code>ZeroPauseGarbageCollection</code>: Instead of disruptive
stop-the-world garbage collection, we only tidy up when the world stops
on its own accord, that is, on program termination.</p></li>
<li><p><code>OneHundredPercentPure</code>: Gone is the catch-all lawless
IO monad. And no trace of those scary <code>unsafeThisAndThat</code>
functions. All functions must be pure.</p></li>
<li><p><code>WeDontServeYourType</code>: Compilation failing because of inscrutable type
checking rules? Confused by the ever-growing mire of extensions to the type
system? The solution is simple: no type checking. It also means no
typeclasses. Just pass dictionaries explicitly.</p></li>
<li><p><code>ZeroPauseGarbageCollection</code>: Instead of disruptive stop-the-world garbage
collection, we only tidy up when the world stops on its own accord, that is,
on program termination.</p></li>
<li><p><code>OneHundredPercentPure</code>: Gone is the catch-all lawless IO monad. And no
trace of those scary <code>unsafeThisAndThat</code> functions. All functions must be pure.</p></li>
<li><p><code>SyntaxForTheMasses</code>: See below.</p></li>
</ul>
<h3 id="building">Building:</h3>
@@ -179,102 +175,82 @@ functions. All functions must be pure.</p></li>
<h4 id="fibonacci-numbers">Fibonacci numbers:</h4>
<p>Test the compiler on <a href="fib.hs">fib.hs</a>:</p>
<div class="sourceCode" id="cb6"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb6-1"><a href="#cb6-1" aria-hidden="true" tabindex="-1"></a><span class="kw">(</span><span class="ex">./prog</span> <span class="op">&lt;</span> fib.hs <span class="kw">;</span> <span class="fu">cat</span> prog.c<span class="kw">)</span> <span class="op">&gt;</span> fib.c</span></code></pre></div>
<p>Compiling the output produces a binary that prints the 30th Fibonacci
number.</p>
<p>The file <a href="ghcfib.hs">ghcfib.hs</a> includes <a
href="fib.hs">fib.hs</a> with some glue code, and shows GHC also accepts
our subset of Haskell:</p>
<p>Compiling the output produces a binary that prints the 30th Fibonacci number.</p>
<p>The file <a href="ghcfib.hs">ghcfib.hs</a> includes <a href="fib.hs">fib.hs</a> with some glue code,
and shows GHC also accepts our subset of Haskell:</p>
<div class="sourceCode" id="cb7"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb7-1"><a href="#cb7-1" aria-hidden="true" tabindex="-1"></a><span class="ex">ghc</span> ghcfib.hs</span></code></pre></div>
<h4 id="self-hosting-compiler">Self-hosting compiler:</h4>
<p>To avoid spoiling this entry by revealing the original Haskell
source, we instead provide <a href="hint.hs">hint.hs</a>, the output of
a certain stage of the compiler when run on itself. This intermediate
output is hopefully difficult to understand, yet is accepted by our
compiler:</p>
<p>To avoid spoiling this entry by revealing the original Haskell source, we
instead provide <a href="hint.hs">hint.hs</a>, the output of a certain stage of the
compiler when run on itself. This intermediate output is hopefully difficult to
understand, yet is accepted by our compiler:</p>
<div class="sourceCode" id="cb8"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb8-1"><a href="#cb8-1" aria-hidden="true" tabindex="-1"></a><span class="kw">(</span><span class="ex">./prog</span> <span class="op">&lt;</span> hint.hs <span class="kw">;</span> <span class="fu">cat</span> prog.c<span class="kw">)</span> <span class="op">&gt;</span> hint.c</span>
<span id="cb8-2"><a href="#cb8-2" aria-hidden="true" tabindex="-1"></a><span class="fu">make</span> hint</span>
<span id="cb8-3"><a href="#cb8-3" aria-hidden="true" tabindex="-1"></a><span class="ex">./hint</span></span></code></pre></div>
<p>The output program behaves like the compiler itself.</p>
<p>Unlike the original source from which it is derived, GHC fails to
compile <a href="hint.hs">hint.hs</a>. This is because values have been
replaced with their <a
href="https://en.wikipedia.org/wiki/Mogensen-Scott_encoding">Scott
encodings</a> by this stage, which messes up type-checks; we’d need
<code>equirecursive</code> types for it to work.</p>
<p>Unlike the original source from which it is derived, GHC fails to compile
<a href="hint.hs">hint.hs</a>. This is because values have been replaced with their <a href="https://en.wikipedia.org/wiki/Mogensen-Scott_encoding">Scott
encodings</a>
by this stage, which messes up type-checks; we’d need <code>equirecursive</code> types for
it to work.</p>
<h4 id="regexes">Regexes:</h4>
<p>The file <a href="lol.hs">lol.hs</a> contains an adaptation of <a
href="https://www.cs.dartmouth.edu/~doug/nfa.pdf">Doug McIlroy’s elegant
code from “Enumerating the strings of regular languages”</a>. We
exercise it by showing the first entries of the length-ordered list of
all strings consisting of the characters <code>a</code> and
<code>b</code> that contain an even number of <code>a</code>s.</p>
<p>The file <a href="lol.hs">lol.hs</a> contains an adaptation of <a href="https://www.cs.dartmouth.edu/~doug/nfa.pdf">Doug McIlroy’s elegant code from
“Enumerating the strings of regular
languages”</a>. We exercise it by
showing the first entries of the length-ordered list of all strings consisting
of the characters <code>a</code> and <code>b</code> that contain an even number of <code>a</code>s.</p>
<div class="sourceCode" id="cb9"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb9-1"><a href="#cb9-1" aria-hidden="true" tabindex="-1"></a><span class="kw">(</span><span class="ex">./prog</span> <span class="op">&lt;</span> lol.hs <span class="kw">;</span> <span class="fu">cat</span> prog.c<span class="kw">)</span> <span class="op">&gt;</span> lol.c</span>
<span id="cb9-2"><a href="#cb9-2" aria-hidden="true" tabindex="-1"></a><span class="fu">make</span> lol</span>
<span id="cb9-3"><a href="#cb9-3" aria-hidden="true" tabindex="-1"></a><span class="ex">./lol</span></span></code></pre></div>
<p>A GHC wrapper is provided:</p>
<div class="sourceCode" id="cb10"><pre
class="sourceCode sh"><code class="sourceCode bash"><span id="cb10-1"><a href="#cb10-1" aria-hidden="true" tabindex="-1"></a><span class="ex">ghc</span> ghclol.hs</span></code></pre></div>
<h3 id="strongly-connected-components">Strongly-connected
components:</h3>
<p>See <a href="scc.hs">scc.hs</a> (and its GHC wrapper <a
href="ghcscc.hs">ghcscc.hs</a>) for an elegant way to print the
strongly-connected components of a graph in reverse topological
<div class="sourceCode" id="cb10"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb10-1"><a href="#cb10-1" aria-hidden="true" tabindex="-1"></a><span class="ex">ghc</span> ghclol.hs</span></code></pre></div>
<h3 id="strongly-connected-components">Strongly-connected components:</h3>
<p>See <a href="scc.hs">scc.hs</a> (and its GHC wrapper <a href="ghcscc.hs">ghcscc.hs</a>) for an elegant
way to print the strongly-connected components of a graph in reverse topological
order.</p>
<div class="sourceCode" id="cb11"><pre
class="sourceCode sh"><code class="sourceCode bash"><span id="cb11-1"><a href="#cb11-1" aria-hidden="true" tabindex="-1"></a><span class="kw">(</span><span class="ex">./prog</span> <span class="op">&lt;</span> scc.hs <span class="kw">;</span> <span class="fu">cat</span> prog.c<span class="kw">)</span> <span class="op">&gt;</span> scc.c</span></code></pre></div>
<div class="sourceCode" id="cb11"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb11-1"><a href="#cb11-1" aria-hidden="true" tabindex="-1"></a><span class="kw">(</span><span class="ex">./prog</span> <span class="op">&lt;</span> scc.hs <span class="kw">;</span> <span class="fu">cat</span> prog.c<span class="kw">)</span> <span class="op">&gt;</span> scc.c</span></code></pre></div>
<p>It expects the input to be in a similar format as a previous entry
(2018 vokes). For example:</p>
<div class="sourceCode" id="cb12"><pre
class="sourceCode sh"><code class="sourceCode bash"><span id="cb12-1"><a href="#cb12-1" aria-hidden="true" tabindex="-1"></a><span class="fu">make</span> scc</span>
<div class="sourceCode" id="cb12"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb12-1"><a href="#cb12-1" aria-hidden="true" tabindex="-1"></a><span class="fu">make</span> scc</span>
<span id="cb12-2"><a href="#cb12-2" aria-hidden="true" tabindex="-1"></a><span class="ex">./scc</span> <span class="op">&lt;</span> example-1.txt</span>
<span id="cb12-3"><a href="#cb12-3" aria-hidden="true" tabindex="-1"></a><span class="ex">./scc</span> <span class="op">&lt;</span> example-2.txt</span></code></pre></div>
<p>The output should agree, though our program omits line numbers and
does not sort entries within a line. (Also, our program only treats
spaces as whitespace, and supports any non-space character in a vertex
name.)</p>
<p>The output should agree, though our program omits line numbers and does not
sort entries within a line. (Also, our program only treats spaces as
whitespace, and supports any non-space character in a vertex name.)</p>
<h3 id="syntax">Syntax</h3>
<p>Some claim Haskell syntax is frightening because braces and
semicolons are optional. Some complain about a zoo of twisty little
operators, all alike. Our compiler addresses such concerns by making
braces and semicolons compulsory, disabling layout-based rules, making
every operator left-associative with same precedence, and only defining
6 primitive functions:</p>
<p>Some claim Haskell syntax is frightening because braces and semicolons are
optional. Some complain about a zoo of twisty little operators, all alike. Our
compiler addresses such concerns by making braces and semicolons compulsory,
disabling layout-based rules, making every operator left-associative with same
precedence, and only defining 6 primitive functions:</p>
<pre><code>: + - * / &lt;=</code></pre>
<p>The arithmetic operations behave as they do in C on
<code>unsigned int</code>s, and <code>(:)</code> is Haskell’s
<code>cons</code> function. Like Haskell and unlike C,
<code>(&lt;=)</code> returns a <code>Bool</code> (which are Church
booleans behind the scenes) and not an <code>Int</code>.</p>
<p>No ifs, ands, or buts. Define them yourself. No tuples. Who needs
them when algebraic data types delivers a better product? There is no
do. No where. No list comprehensions. No unary operators.</p>
<p>The arithmetic operations behave as they do in C on <code>unsigned int</code>s, and <code>(:)</code> is
Haskell’s <code>cons</code> function. Like Haskell and unlike C, <code>(&lt;=)</code> returns a <code>Bool</code>
(which are Church booleans behind the scenes) and not an <code>Int</code>.</p>
<p>No ifs, ands, or buts. Define them yourself. No tuples. Who needs them when
algebraic data types delivers a better product? There is no do. No where. No
list comprehensions. No unary operators.</p>
<p>Let expressions and operator sections are supported.</p>
<p>Within global scope or a let expression, each definition can only
refer to itself or previous definitions. This implies we can only
achieve mutual recursion by having one function pass itself to
others.</p>
<p>Within global scope or a let expression, each definition can only refer to
itself or previous definitions. This implies we can only achieve mutual
recursion by having one function pass itself to others.</p>
<h3 id="caveats">Caveats</h3>
<p>The only primitive type is <code>Int</code>. In particular, they
represent characters. To interoperate with GHC, our compiler treats any
undefined functions as the <code>identity</code> function, so that we
may freely use <code>ord</code> and <code>chr</code> (or
<code>fromEnum</code> and <code>toEnum</code>) to make our code
acceptable to both compilers.</p>
<p>The main function is the last function to successfully parse. It
should have type <code>[Int] -&gt; [Int]</code>, and our compiler treats
this like the function passed into <code>Prelude.interact</code>, that
is, the entire standard input is passed to this function, and the result
is printed to standard output.</p>
<p>The only primitive type is <code>Int</code>. In particular, they represent characters. To
interoperate with GHC, our compiler treats any undefined functions as the
<code>identity</code> function, so that we may freely use <code>ord</code> and <code>chr</code> (or <code>fromEnum</code> and
<code>toEnum</code>) to make our code acceptable to both compilers.</p>
<p>The main function is the last function to successfully parse. It should have
type <code>[Int] -&gt; [Int]</code>, and our compiler treats this like the function passed
into <code>Prelude.interact</code>, that is, the entire standard input is passed to this
function, and the result is printed to standard output.</p>
<p><code>Bool</code> must be defined as:</p>
<pre><code>data Bool = True | False;</code></pre>
<p>so that it matches the Scott-encoded booleans internally used by the
primitive function <code>(&lt;=)</code>.</p>
<p>The alternatives in a <code>case</code> expressions must list every
data constructor in the order they are defined. For example, if we
have:</p>
<p>so that it matches the Scott-encoded booleans internally used by the primitive
function <code>(&lt;=)</code>.</p>
<p>The alternatives in a <code>case</code> expressions must list every data constructor in
the order they are defined. For example, if we have:</p>
<pre><code>data Foo a b = Bar a | Baz | Qux Int [b]</code></pre>
<p>then a <code>case</code> expression that examines a term of this type
must have the form:</p>
<p>then a <code>case</code> expression that examines a term of this type must have the form:</p>
<pre><code>case x of
{ Bar a -&gt; ...
; Baz -&gt; ...
@@ -282,169 +258,120 @@ must have the form:</p>
}</code></pre>
<p>We stress braces and semicolons are required. Our fussy parser treats
semicolons as separators, not terminators.</p>
<p>The effect of erroneous input is undefined. It may be best to develop
with GHC, but even then, be mindful of changes needed because of issues
caused by the uniform operator precedence and the touchy format of
<code>case</code> alternatives.</p>
<p>The effect of erroneous input is undefined. It may be best to develop with GHC,
but even then, be mindful of changes needed because of issues caused by the
uniform operator precedence and the touchy format of <code>case</code> alternatives.</p>
<h3 id="why">Why?</h3>
<p>One-letter variable names abound in IOCCC entries, and for good
reason. These tiny pieces of confetti are hard to read, and leave room
for more code. Then why not go further and use zero-letter variable
names? That is, tacit programming or point-free style.</p>
<p>I had been playing with an algorithm devised by Oleg Kiselyov that
effortlessly and efficiently eliminates those pesky variables, leaving
behind terms composed from a small set of combinators. No need for
lambda lifting or supercombinators.</p>
<p>By adding a handful of lines of mostly parsing code, we get a Haskell
compiler, or rather, a compiler that accepts a subset of Haskell
sufficiently large to self-host. You might say I wrote a tool for this
contest, then ran it on itself to make an entry for it.</p>
<p>One-letter variable names abound in IOCCC entries, and for good reason. These
tiny pieces of confetti are hard to read, and leave room for more code. Then
why not go further and use zero-letter variable names? That is, tacit
programming or point-free style.</p>
<p>I had been playing with an algorithm devised by Oleg Kiselyov that effortlessly
and efficiently eliminates those pesky variables, leaving behind terms composed
from a small set of combinators. No need for lambda lifting or supercombinators.</p>
<p>By adding a handful of lines of mostly parsing code, we get a Haskell compiler,
or rather, a compiler that accepts a subset of Haskell sufficiently large to
self-host. You might say I wrote a tool for this contest, then ran it on itself
to make an entry for it.</p>
<h3 id="obfuscation-techniques">Obfuscation techniques:</h3>
<p>Even with Kiselyov’s algorithm and some term rewriting, the compiler
only fit after compression, which naturally obfuscates the code. More
tricks were needed to fit within the size limits.</p>
<p>Even with Kiselyov’s algorithm and some term rewriting, the compiler only fit
after compression, which naturally obfuscates the code. More tricks were needed
to fit within the size limits.</p>
<ul>
<li>One-letter variables, until enough is done to banish variables
completely.</li>
<li>Ipse dixit. Near the end, the code declares itself to be an
obfuscated program. (There is also an exhortation intended for the
judges in a similar format earlier in the source.)</li>
<li>Typical C mischief: pre- and post-increment, commutative array
indexing, ternary operators, and so on.</li>
<li>One-letter variables, until enough is done to banish variables completely.</li>
<li>Ipse dixit. Near the end, the code declares itself to be an obfuscated
program. (There is also an exhortation intended for the judges in a similar
format earlier in the source.)</li>
<li>Typical C mischief: pre- and post-increment, commutative array indexing,
ternary operators, and so on.</li>
<li>Huffman coding.</li>
<li>Base-85 because high bits are frowned upon.</li>
<li>Mixed radix encoding to game iocccsize. From a past entry (<a
href="../../2018/bellard/index.html">2018/bellard</a>), it seems 9 11 12
32 are the only whitespace octets that may appear verbatim in string
literals.</li>
<li>Choosing what to encode in Huffman/base-85 and what to encode in
mixed radix was a delicate balancing act. In the end, I only had a few
bytes to spare, which I spent on gratuitous confusion.</li>
<li>The effects of some functions depend on the order their arguments
are evaluated, yet the program works either way. Why?</li>
<li>Ugly macros for the runtime system’s jump table for lazy reduction.
A previous entry (<a
href="../../2013/endoh1/index.html">2013/endoh1</a>) has a cuter
solution, which I avoid because of originality concerns and also because
my combinators are compressed.</li>
<li>Mixed radix encoding to game iocccsize. From a past entry
(<a href="../../2018/bellard/index.html">2018/bellard</a>), it seems 9 11 12 32 are the only
whitespace octets that may appear verbatim in string literals.</li>
<li>Choosing what to encode in Huffman/base-85 and what to encode in mixed radix
was a delicate balancing act. In the end, I only had a few bytes to spare, which
I spent on gratuitous confusion.</li>
<li>The effects of some functions depend on the order their arguments are
evaluated, yet the program works either way. Why?</li>
<li>Ugly macros for the runtime system’s jump table for lazy reduction. A previous
entry (<a href="../../2013/endoh1/index.html">2013/endoh1</a>) has a cuter solution, which I
avoid because of originality concerns and also because my combinators are
compressed.</li>
<li>Relies on the inability of C comments to nest.</li>
<li>Cheaper and more complicated to print comma-separated
<code>int</code>s (and header and footer) in C.</li>
<li>Primitive functions use a trick described in depth by <a
href="https://www.cs.york.ac.uk/fp/reduceron/jfp-reduceron.pdf">Naylor
and Runciman, “The Reduceron reconfigured and re-evaluated”</a>. We
represent the integer <code>n</code> with a term equivalent to
<code>Y(BT)n</code>; it works because
<li>Cheaper and more complicated to print comma-separated <code>int</code>s (and header and
footer) in C.</li>
<li>Primitive functions use a trick described in depth by <a href="https://www.cs.york.ac.uk/fp/reduceron/jfp-reduceron.pdf">Naylor and Runciman,
“The Reduceron reconfigured and
re-evaluated”</a>. We
represent the integer <code>n</code> with a term equivalent to <code>Y(BT)n</code>; it works because
<code>Y(BT)ne = e(Y(BT)n)</code>.</li>
<li>A sentinel in the heap often confused me, so ought to confuse
others.</li>
<li>A sentinel in the heap often confused me, so ought to confuse others.</li>
</ul>
<p>Other obfuscation techniques are better appreciated after decoding
the compiler. See <a href="hint.hs">hint.hs</a>.</p>
<p>Other obfuscation techniques are better appreciated after decoding the
compiler. See <a href="hint.hs">hint.hs</a>.</p>
<ul>
<li>Mercilessly point-free. Everything is a combinator.</li>
<li>Scott encoding. Everything is a combinator.</li>
<li>Sum types are oddly ordered and may even contain unused data
constructors to reduce code duplication. (In C terms,
<code>union</code>s may have extra fields, and they’re ordered in such a
way so we can reuse code to access certain fields.)</li>
<li>The <code>undefined</code> function compiles to the <code>(.)</code>
function.</li>
<li>Replaced the only <code>(&amp;&amp;)</code> with <code>(||)</code>
and <code>not</code> using De Morgan’s law, which makes some comparisons
less comprehensible.</li>
<li><a href="http://okmij.org/ftp/tagless-final/ski.pdf">Kiselyov only
published “λ to SKI, Semantically” last year</a>.</li>
<li>Recursion via the fixpoint (<code>Y</code>) combinator, which is
represented by the variable <code>""</code> during one stage of
compilation.</li>
<li>Involves theory that may be less familiar to C programmers: maps,
folds, parser combinators, lambda calculus, bracket abstraction,
denotational semantics, etc.</li>
<li>Sum types are oddly ordered and may even contain unused data constructors to
reduce code duplication. (In C terms, <code>union</code>s may have extra fields, and they’re
ordered in such a way so we can reuse code to access certain fields.)</li>
<li>The <code>undefined</code> function compiles to the <code>(.)</code> function.</li>
<li>Replaced the only <code>(&amp;&amp;)</code> with <code>(||)</code> and <code>not</code> using De Morgan’s law, which
makes some comparisons less comprehensible.</li>
<li><a href="http://okmij.org/ftp/tagless-final/ski.pdf">Kiselyov only published “λ to SKI, Semantically” last
year</a>.</li>
<li>Recursion via the fixpoint (<code>Y</code>) combinator, which is represented by the
variable <code>""</code> during one stage of compilation.</li>
<li>Involves theory that may be less familiar to C programmers: maps, folds,
parser combinators, lambda calculus, bracket abstraction, denotational
semantics, etc.</li>
</ul>
<h3 id="warnings">Warnings:</h3>
<p>On my system, it compiles cleanly with <code>-Wall</code> with older
standards, e.g. <code>-std=c89</code>, but less cleanly if
<code>-pedantic</code> is also supplied.</p>
<p>Compiling the compiler output with <code>-Wall</code> triggers a
warning about a strange-looking comment.</p>
<p>On my system, it compiles cleanly with <code>-Wall</code> with older standards, e.g.
<code>-std=c89</code>, but less cleanly if <code>-pedantic</code> is also supplied.</p>
<p>Compiling the compiler output with <code>-Wall</code> triggers a warning about a
strange-looking comment.</p>
<h3 id="behind-the-scenes-commentary">Behind-the-scenes commentary:</h3>
<p><a href="https://crypto.stanford.edu/~blynn/compiler/ioccc.html">My
website reveals how this compiler works</a>.</p>
<h2 id="copyright-and-cc-by-sa-4.0-license">Copyright and CC BY-SA 4.0
License:</h2>
<p>This file is Copyright (c) 2023 by Landon Curt Noll. All Rights
Reserved. You are free to share and adapt this file under the terms of
this license:</p>
<p><a href="https://crypto.stanford.edu/~blynn/compiler/ioccc.html">My website reveals how this compiler
works</a>.</p>
<h2 id="copyright-and-cc-by-sa-4.0-license">Copyright and CC BY-SA 4.0 License:</h2>
<p>This file is Copyright (c) 2023 by Landon Curt Noll. All Rights Reserved.
You are free to share and adapt this file under the terms of this license:</p>
<pre><code>Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)</code></pre>
<p>For more information, see:
https://creativecommons.org/licenses/by-sa/4.0/</p>
<p>For more information, see: https://creativecommons.org/licenses/by-sa/4.0/</p>
<!-- END: this line ends content for HTML phase 21 by: bin/pandoc-wrapper.sh via bin/md2html.sh -->
<!-- START: this line starts content for HTML phase 22 by: bin/output-index-inventory.sh via bin/md2html.sh -->
<!-- START: this line starts content generated by: bin/output-index-inventory.sh -->
<h1 id="inventory-for-2019lynn"><a name="inventory"></a>Inventory for
2019/lynn</h1>
<h1 id="inventory-for-2019lynn"><a name="inventory"></a>Inventory for 2019/lynn</h1>
<p><a href="#top">Jump to top</a></p>
<h2 id="primary-files">Primary files</h2>
<ul>
<li><a
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2019/lynn/prog.c">prog.c</a>
- entry source</li>
<li><a
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2019/lynn/Makefile">Makefile</a>
- entry Makefile</li>
<li><a
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2019/lynn/prog.orig.c">prog.orig.c</a>
- original source</li>
<li><a
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2019/lynn/example-1.txt">example-1.txt</a>
- sample input</li>
<li><a
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2019/lynn/example-2.txt">example-2.txt</a>
- sample input</li>
<li><a
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2019/lynn/try.sh">try.sh</a>
- how to run</li>
<li><a
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2019/lynn/fib.hs">fib.hs</a>
- compiler macros</li>
<li><a
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2019/lynn/ghcfib.hs">ghcfib.hs</a>
- compiler macros</li>
<li><a
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2019/lynn/ghclol.hs">ghclol.hs</a>
- compiler macros</li>
<li><a
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2019/lynn/ghcscc.hs">ghcscc.hs</a>
- compiler macros</li>
<li><a
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2019/lynn/lol.hs">lol.hs</a>
- compiler macros</li>
<li><a
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2019/lynn/scc.hs">scc.hs</a>
- compiler macros</li>
<li><a
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2019/lynn/hint.hs">hint.hs</a>
- spoiler for compiler macros</li>
<li><a href="2019_lynn.tar.bz2">2019_lynn.tar.bz2</a> - download entry
source</li>
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2019/lynn/prog.c">prog.c</a> - entry source</li>
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2019/lynn/Makefile">Makefile</a> - entry Makefile</li>
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2019/lynn/prog.orig.c">prog.orig.c</a> - original source</li>
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2019/lynn/example-1.txt">example-1.txt</a> - sample input</li>
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2019/lynn/example-2.txt">example-2.txt</a> - sample input</li>
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2019/lynn/try.sh">try.sh</a> - how to run</li>
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2019/lynn/fib.hs">fib.hs</a> - compiler macros</li>
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2019/lynn/ghcfib.hs">ghcfib.hs</a> - compiler macros</li>
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2019/lynn/ghclol.hs">ghclol.hs</a> - compiler macros</li>
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2019/lynn/ghcscc.hs">ghcscc.hs</a> - compiler macros</li>
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2019/lynn/lol.hs">lol.hs</a> - compiler macros</li>
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2019/lynn/scc.hs">scc.hs</a> - compiler macros</li>
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2019/lynn/hint.hs">hint.hs</a> - spoiler for compiler macros</li>
<li><a href="2019_lynn.tar.bz2">2019_lynn.tar.bz2</a> - download entry source</li>
</ul>
<h2 id="secondary-files">Secondary files</h2>
<ul>
<li><a href="index.html">index.html</a> - entry home page</li>
<li><a
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2019/lynn/.entry.json">.entry.json</a>
- description of entry in JSON</li>
<li><a
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2019/lynn/.gitignore">.gitignore</a>
- list of files that should not be committed under git</li>
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2019/lynn/.entry.json">.entry.json</a> - description of entry in JSON</li>
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2019/lynn/.gitignore">.gitignore</a> - list of files that should not be committed under git</li>
<li><a href=".path">.path</a> - directory path from top directory</li>
<li><a
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2019/lynn/README.md">README.md</a>
- markdown source for index.html</li>
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2019/lynn/README.md">README.md</a> - markdown source for index.html</li>
</ul>
<!-- END: next line ends content generated by: bin/output-index-inventory.sh -->