August 5, 2020:
This was embarrassing: I learned what I should have known by day one: I could totally disable Jekyll to make it a static site. I knew that when Jekyll was run, GitHub automatically generated the site again in the server end. But I didn’t know that if there was an empty file .nojekyll, GitHub no longer ran Jekyll, but it simply recognized index.html, and serve the site accordingly. It suddenly looked feasible to design a custom format, and generate HTML-with-LaTeX myself.
August 6:
Surprisingly, as I tested for several simple cases, most browsers didn’t support MathML, including even Chrome and Safari. That crossed out MathML as the framework for my new notation.
If I used a more linear notation as Peano did, which fell in the realm of HTML and CSS, I might solve the problem by not creating it. OK, brace yourself for a even more unconventional notation.
If so, I only had to mimic fractions and matrices, possibly by drawing an inner horizontal line between items, and an outermost vertical line surrounding them all. Then I soon discovered that <p> didn’t allow block-level tags like <table> or <div> !
August 7:
Important realization! HTML <p> could contain several lines separated by <br> and stacked vertically, if grouped by a <span>. Moreover, the CSS border-left, border-right, border-top, and border-bottom could serve as traditional mathematical brackets. They could be colored, scaled, or thickened as I wished, by a suitable class. This would perhaps suffice for my revolution of notation.
August 8:
Implementing a Markdown parser wouldn’t be an easy task, since to me, Markdown wasn’t an elegant markup. The earliest version of Markdown by John Gruber was sometimes ambiguous. For example, *italic __bold*__ could be either an italic or a bold, depending on the precedence. Afterwards John MacFarlane proposed CommonMark, and implemented a PEG grammar. To complicate matters, I wasn’t sure whether GitHub-Flavored Markdown had a PEG (parsing expression grammar) or a BNF (Backus–Naur form). Recall that it was well known that whether a language was unambiguous was undecidable, in general.
Or it would be more reasonable to first design a subset of the markup, which was context-free, and should encompass Markdown with Kramdown. At this stage I would convert the source to Markdown, and generate via Jekyll. Then when I had a better grasp of computation theory, I would finish the rest of grammar, which might be recursively enumerable. When that was done, I would stop using Markdown and Jekyll altogether. Still, I didn’t know how to show rigorously that the two parts of the project are theoretically consistent, and I got confused.
August 12:
Came up with the artificial square brackets made of HTML spans. One Stack Overflow post explained that it could indeed be done. Nevertheless, CSS grids, which to me was superior to HTML tables, might be even more suited for this job.
.v, .v-b, .v-l, .v-r, .v-l-r {
display: inline-block;
vertical-align: middle;
}
.v-b { border-bottom: thin dotted black;}
.v-l { border-left: thin dotted black;}
.v-r { border-right: thin dotted black;}
.v-l-r { border-left: thin dotted black; border-right: thin dotted black;}
<span class="v-l-r">
<span class="v-b">
<span class="v-r">
<span class="v-b"> a </span> <br>
<span class="v"> b </span>
</span>
- <span class="v"> cd </span>
</span> <br>
<span class="v"> x+y+z </span>
</span>
August 14:
Realized that an expression was really a tree. If I chose prefix form always, there would be no parsing problem, as in Lisp. Later today, Facebook friend Dingqi coincidentally posted a link on prefix-infix-postfix transformation, because I brought up the topic of obelus sign. This helped me further clarify the tree picture The design of esoteric language Jelly, and its precursor J and APL, might become instructive as a reference of parser implementation.
❧ late August, 2020
References