Have I sadfished you? Baited! Despite the overprotection, I was wicked! Conor Mcgregor must’ve copied my childhood strut. I was Boy-Scout-Russelling all these adults out here

with a Chinese riddle booklet in hand and a silly cap on head, I quizzed down the adults I met. I had the best grades but was disruptive enough to be kicked out of the classroom. Peeking through the warped windows, I kept making silly faces at my friends much to the groan of my teachers. I also believed through proper breathing, one can obtain superpowers through instanteous transfer of energy from the Dan Tian mid section. That’s what they wrote in the WuXia novels, so, sometimes I was caught medidating (and I had to play stupid because that’s what the main characters with special talent had to do to avoid earlh ).

Once, my school hosted a storytelling competition. We were supposed to prepare a story to deliver in class, the winner of each class tells it in front of the whole school. I forgot to prepare. My greatest improvisation ensued: In my story, I would fall into a pig pen and get out of it bullfighter style. I got to the school competition by unanimous vote. That day, I danced like a bullfighter with my dad’s red windbreaker as I delivered the story crisply. In that sauce red auditorium, I caught my crush’s gaze somewhere from the upper left corner as my friends were keeling over with laughter a few rows down. She was sitting at the edge of her seat, staring at me brightly. So I peacocked.

For my mischief, my mother sent me to military training for a summer, much to my grandmother’s objection. At the camp, everyone had to memorize the entirety of San Zi Jing, a Confucian classic. I still caused trouble and subjected my dorm of eight-year-olds to hold planks for an hour during post-lunch nap time. I came back from the camp propagandized and enlightened. I only walked in military steps around the house for a few months and begged my grandmother to let me wash her feet, citing Confucian ideals.

But my mischief went on. All the adults talked about the same stuff. I was so bored of it, and I decided their time could be better spent participating in my games. From reading a crap ton—I stayed up until 4am some nights to read and even wrote some Wuxia chapters with a flashlight under the blanket—I smuggled in a serious vocabulary that I would use to terrorize the adults. For the Chinese language, this means you know a lot of four-word idioms. Everyone knows a few hundred idioms and poetry stanzas from Chinese classes, but they don’t use them much in the vernacular. Instead of saying something is shocking, you could say that something “splits the stone and startles the heavens” (石破天惊). I dragged adults into unskippable games of connect-the-idioms: I say an idiom, you say an idiom whose first letter starts with my last, and so on.

I never beat the taxi drivers though. Not even when I am all grown. Last year when I visited, I played it with a taxi driver. Soon enough, he started skipping my turns, riffing off of his idioms, then barrelling into poetry lines and pop song lyrics, all while navigating busy Shanghai streets under the downpour.

#1: At 乌鹊 restaurant

As kayne thanks god for Jay Electra for being “down with the mission” in the hit piece “Saint Pablo”, I thank the ogs of CCP - the class of 1921 - for the same. Je’Ri was piping out that New Shit, looping Eternal Sunshine raw no drums no hook. CCP was printing that New Idea, and youth was the first bloom amongst a hundred flowers.

Then one started an affair with a Rothchild while the other started killing the Rothschildren and the doctors and teachers of the People’s Republic of China.

2/19/26, At Nanhu (the South Lake), where the first CCP meeting took place securely in a boat.

#2: At Nha Trang Restaurant, Falls Church, Virginia

Where the line formed for the tofu place, take a left, around the corner. A store. Can’t see from outside. Oils and Chinese produce. Walk in, an Asian at the register, it’s a weighted register. It’s sectioned off, facing the window. Weird. The Asian has vaneers. Colin compliments her teeth, Colin receives thanks. I scan around: Guan Yu statue, lunar new years calendar in traditional Chinese. Weird. I make conversation; I ask about the store, hands in my pockets. She responds vaguely - “An agency”. I think I know. Is it the hands in the pockets? i walk away. We all know we’re not the customer.

#3: At Breeze Bakery Cafe, Anndale, Virginia

The creature America: its head strip malls, its belly interstate highways, and its fat ass the overall rectangular but internally 65 degrees parking lots. You eat on top of the creature as it feasts on itself.

Researchers are interested in similar properties:

1. For parser generators, researchers verify that the parser generator is sound, complete, and unambiguous.
2. For parser combinators, researchers verify that the combinators are total, prefix-secure, and satisfy roundtrip (for binary parsing).

I start this review with an intro to formal methods, then I explain traditional parser generation. Finally, I dive into the source code and present what the verification code looks like under the hood. In particular, I show how to prove that the Vermillion LL(1) parser generator, written in Rocq, must not parse left-recursive grammars. In the next post, I explain parser combinators and show how the Vest library proves roundtrip for specific binary parser combinators.

This post is meant for everyone. If you have experience in Coq, you should be able to understand the concept of abstract, inductive specification that I keep repeating in the verification section. If you don’t, just focus on getting the big ideas. But don’t feel defeated if you don’t understand the proofs themselves — they are mechanized according to complex inductive definitions. I, for one, don’t understand them completely.

Background: Formal Methods

In a simplified view, formal methods is about expanding your unit tests to cover the entire input domain.

But how?

It is computationally infeasible to run tests for every plausible input. Instead, to reason about infinity, we have to be inductive. The philosophy of induction is woven into the programming languages of formal methods (most of which can be called proof assistants):

1. Structures are defined inductively.

This goes from natural numbers to lists to domain-specific languages embedded within proof assistants. To elaborate, natural numbers are defined in their Peano form: 0 is a nat, and given n: nat, n + 1 is a nat. For lists, [1, 2, 3] is represented as Cons 1 (Cons 2 (Cons 3 Nil)). As for embedded languages, see the definition of com here. You are probably more familiar with the latter since we know that code gets parsed into trees that follow recursive grammar rules. But defining primitives inductively might be the bigger surprise.

1. Proofs can be inductive.

When every structure in your proof is defined inductively, your proofs can make use of induction!

The other important part about formal methods to mention, in an introduction, is the concept of totality, which means “provably terminating” and “covers entire input domain”, i.e., not partial. Functions in Turing-complete languages, on the other hand, are partial. Haskell will give a warning for functions not covering the entire input domain, but it’s just a warning.

When I started learning about formal methods a few months ago, it took me a few days to realize that these “formal method languages” (e.g., Coq, Idris, Isabelle) are adding a lot of constraints to programming languages. That is to say, there exist programs in Turing-complete languages that you can’t write in these “formal methods languages”.

But it took me a while to understand why, and why such constraints give power. First, there’s this thing called the Curry-Howard Correspondence that makes algebra, logic, and type theory isomorphic. Software folks will find type theory intuitive, but it is more logic and math flavored.

The Curry-Howard Correspondence leads to the isomorphism between programs and proofs. In proof assistants, propositions are types, and proofs are terms (programs). To prove a proposition, construct a proof program whose type is that proposition.

Here’s the key: Proofs must be provably terminating. This makes sense - a proof that loops isn’t a proof; a proof must terminate. Since proofs are programs, programs are provably terminating as well. But if our programs are total, our language can’t be Turing-complete, since Turing machines are allowed to go into the “loop” state!

So, by adding constraints (totality) to our language, we have made it more powerful (our language can prove things). Developers often first experience this in their encounter with Haskell’s type system or Rust’s borrow checker: You wage a series of mini-wars against the compiler. But when the linter goes green, you have many more guarantees about the correctness of your program.

Structures, strictures, though they bind,

Strangely liberate the mind.

Background: Parsing

Parsing is the process of attempting to ingest a raw string into some structured format, according to some rules. The structured format is often a tree, but it need not be. Even the act of lifting the phone number (123)-456-7899 into a Haskell record PhoneNum { area: "123", mid: "456", rest: "7899" } is considered parsing. But traditionally, parsing is focused on parsing programming languages, so the structured format is a tree. I focus on traditional parsing in this post.

In traditional parsing, parsing follows the definition of a context-free grammar (CFG). A parser generator takes in the grammar and outputs a parser, which often comes in the form of some lookup table: The parsing procedure is general and utilize the specific table.

A context-free grammar is a set of (recursive) generation rules, often written in the Backus-Naur form. For example, here is the CFG for arithmetic:

E -> E + E
E -> E - E
E -> E * E
E -> E / E
E -> (E)
E -> Number

The leftmost elements are nonterminals. E is the only nonterminal. The right-hand side to the -> is called the gamma. Symbols that aren’t on the left-hand side are terminals. For example, +, -, and even ( and ) are terminals.

Each line naturally shows a production, a valid expansion for a nonterminal. You could choose to write all of the productions for a nonterminal together:

E -> E + E | E - E | E * E | E / E | (E) | Number

Here is how we can expand an E into 3 + 5 + 8:

E -> E + E
E -> E + E + E
E -> Number + Number + Number
E -> 3 + 5 + 8

Currently, to check if an input is expandable by the grammar, we mentally create heuristics to choose the correct productions at each step. But a computer needs something more deterministic. In the ideal case, the computer knows which production to expand into just by looking at the next input token and remembering the context we are in, i.e., which nonterminal we are parsing. This is called top-down, predictive parsing.

This ideal case is possible if our grammar is LL(1). Most parser generators support LR(1), or some stronger versions of it. LR(1) is strictly stronger than LL(1). But LL(1) is faster, choosing productions right away, as opposed to shifting and reducing in LR(1).

A grammar is LL(1) if it satisfies one property:

1. No productions for the same nonterminal have coinciding first terminals.

E does not satisfy this property. For example, two productions for E, E + E and E - E, both have ( as their first terminal.

But, since productions can be nullable (written as A -> epsilon), there needs to be one additional criterion:

1. For any nullable nonterminal A, the set of candidate first terminals of A, denoted FIRST(A), cannot intersect with FOLLOW(A), which lists, from all productions, the first token of the symbols that follows A.

After computing FIRST and FOLLOW sets for each nonterminal (which can be done through a straightforward fixed-point algorithm), we can construct the parsing lookup table. The lookup table is a map between (nonterminal, lookahead token) and a production, since the goal is to know which production to choose next.

For each production A -> α:

• For each terminal t in FIRST(α), add the production to table(A,t).
• If α is nullable, for each terminal t in FOLLOW(A), add A -> α to table(A,t)

The construction of the FIRST and FOLLOW maps never throws. The errors are handled as we add entries: If we try to add a production to a table cell that already contains one, there is ambiguity. Hence, the grammar is not LL(1) and we throw an error.

During parsing, we maintain a stack of expected symbols (initialized with the start symbol) and an input stream of terminals. At each step:

• If the top of stack is a terminal, match it with input or error
• If top of stack is nonterminal A and next input is t, look up table(A,t):
  • If empty, syntax error
  • If production A → α exists, pop A and push α (reversed) onto stack
• Repeat until stack is empty (accept) or error occurs

An LL(1) grammar is unambiguous: We know exactly which production to choose when we are expanding a nonterminal. This implies that a string can only have one parse tree. Our arithmetic language above doesn’t satisfy this property; we can expand E + E into E + E + E either through expanding the first E or the second, which results in two parse trees.

Unambiguity is important for programming languages: A program should have exactly one tree! For natural language, it doesn’t matter as much.

Vermillion, the certified LL(1) parser generator

The general workflow of verifying a parser generator is composed of four parts:

1. Provide an inductive specification for definitions and behaviors in our parser
2. Implement the concrete fixpoints that constructs the parsing table
3. Show the equivalence of the concrete implementation and the inductive specification
4. Prove properties about parsers. These properties are exactly the verified surface of our parsers.

Then, since the concrete implementation is 1-to-1 with the inductive specification, it implies that our concrete parsers satisfy the properties proved in 4.

I show real code for each part. You should digest a few of the inductive definitions but skim the proofs.

Using Vermillion

Before going under the hood and studying the verification code, let’s first look at how we can use the certified parser generator.

The input to the generator is a grammar encoded in Coq. Here’s Grammar 3.11 from Appel’s “Modern Compiler Implementation in ML”:

S -> if E then S else S
S -> begin S L
S -> print E

L -> end
L -> ; S L

E -> num = num 

To encode this grammar, we must first supply the nonterminals, terminals, and the “semantic actions”. The semantic actions are mappings between symbols (nonterminals and terminals) and data types in Coq. For example, the terminal Num will map to the built-in type nat, and the nonterminal S (a sentence) will map to a stmt data type (stmt must be defined). After parsing a string, the resulting tree nodes are semantic actions.

Here are the encodings of nonterminals, terminals, and semantic actions:

Inductive exp :=
| Cmp_exp : nat -> nat -> exp.

Inductive stmt :=
| If_stmt    : exp -> stmt -> stmt -> stmt
| Begin_stmt : list stmt -> stmt
| Print_stmt : exp -> stmt.

Inductive terminal' :=
| If | Then | Else | Begin | Print | End | Semi | Num | Eq.
  
Inductive nonterminal' :=
| S | L | E.

Definition t_semty (a : terminal) : Type :=
  match a with
  | Num => nat
  | _   => unit
  end.

Definition nt_semty (x : nonterminal) : Type :=
  match x with
  | S => stmt
  | L => list stmt
  | E => exp
  end.

Note that stmt has three constructors, which corresponds to the number of productions S has.

So far, we have only defined the elements of the grammar; we have not yet encoded the productions:

Definition g311 : grammar :=
  {| start := S ;
     prods := [existT action_ty
                      (S, [T If; NT E; T Then; NT S; T Else; NT S])
                      (fun tup =>
                         match tup with
                         | (_, (e, (_, (s1, (_, (s2, _)))))) =>
                           If_stmt e s1 s2
                         end);
                 
               existT action_ty
                      (S, [T Begin; NT S; NT L])
                      (fun tup =>
                         match tup with
                         | (_, (s, (ss, _))) =>
                           Begin_stmt (s :: ss)
                         end);

               existT action_ty
                      (S, [T Print; NT E])
                      (fun tup =>
                         match tup with
                         | (_, (e, _)) =>
                           Print_stmt e
                         end);
               ... you get the idea
  ]|}

The 3.11 grammar has no nullable productions. If you have a nullable production, it will look like:

existT action_ty
      (A, []) (* Empty list! *)
      (fun tup =>
          match tup with
          | _ => AStruct
          end);

Check out this example in my Vermillion fork where I encode the following grammar, which has nullable productions:

E  -> TE'
E' -> +TE' | epsilon
T  -> FT'
T' -> *FT' | epsilon
F  -> (E)  | Num

Now, we can use the parser generator to build a parser (more precisely, the parsing tables), and then invoke the parse procedure (with the tables) on our inputs.

(* tt is the unit type *)
Definition example_prog : list token :=
  [tok If tt; tok Num 2; tok Eq tt; tok Num 5; tok Then tt;
     tok Print tt; tok Num 2; tok Eq tt; tok Num 5;
   tok Else tt;
     tok Print tt; tok Num 42; tok Eq tt; tok Num 42].

Compute (match parseTableOf g311 with
         | inl msg => inl msg
         | inr tbl => inr (parse tbl (NT S) example_prog)
         end).

(* You will see a tree made up of semantic action nodes! *)

If your grammar is not LL(1), then it will be rejected at parseTableOf. If your input is not recognizable by the parser, then it will give an inl error message within parse.

1. Inductive specifications

Let’s start light: Recall, what does it mean for a symbol to be nullable?

A symbol is nullable if it has a production that can go to epsilon. For example, A is nullable:

A -> b | c | d | epsilon

but A is also nullable here:

A -> B | c
B -> d | epsilon

In Coq, we translate the natural language description of “a production can go to epsilon” as:

Inductive nullable_sym (g : grammar) : symbol -> Prop :=
| NullableSym : forall x ys f,
    In (existT _ (x, ys) f) g.(prods)
    -> nullable_gamma g ys
    -> nullable_sym g (NT x)
with nullable_gamma (g : grammar) : list symbol -> Prop :=
      | NullableNil  : nullable_gamma g []
      | NullableCons : forall hd tl,
          nullable_sym g hd
          -> nullable_gamma g tl
          -> nullable_gamma g (hd :: tl).

You are looking at the definition of an inductive proposition. This defines how to create proofs of a symbol s to be a nullable_sym: You must supply a nullable gamma ys where (s, ys) is a valid pairing in the grammar’s production.

Mutually, nullable_gamma must be defined: An empty production is trivially a nullable_gamma through the NullableNil constructor. More interestingly, a gamma’s nullability can be determined by the nullability of its head and tail. In summary, the nullable_sym inductive prop allows us to “choose a gamma” to show nullability from, and the nullable_gamma inductive prop allows us to break up the symbols in the gamma and recurse into nullable_sym.

Similar specifications are defined for what it means to be a first_sym, a follow_sym, then a lookahead_for, and at last culminating in sys_derives_prefix:

    Inductive sym_derives_prefix (g : grammar) : Prop :=  
    | T_sdp :
          (* A terminal can derive an element of the corresponding type (determined with t_semty), *)
          sym_derives_prefix g (T a) [existT _ a v] v r
    | NT_sdp :
        (* A nonterminal can derive a sequence of tokens if:
           1) There exists a production rule for this nonterminal in the grammar
           2) The next token in the input stream is a valid lookahead for this production
           3) The right-hand side of the production (gamma) can derive the token sequence
           The semantic value is computed by applying the production's action to the derived values *)
        In (existT _ (x, gamma) f) g.(prods) (* Multiple productions allowed *)
        -> lookahead_for (peek (w ++ r)) x gamma g
        -> gamma_derives_prefix g gamma w vs r
        -> sym_derives_prefix g (NT x) w (f vs) r
    with gamma_derives_prefix (g : grammar) : Prop :=
         | Nil_gdp :
             (* An empty sequence of symbols derives an empty sequence of tokens *)
             gamma_derives_prefix g [] [] tt r
         | Cons_gdp :
             (* A sequence of symbols derives a token sequence if:
                1) The first symbol derives some prefix of tokens
                2) The rest of the symbols derive the remaining tokens
                The semantic values are paired together as we go *)
             sym_derives_prefix g s wpre v (wsuf ++ r)
             -> gamma_derives_prefix g ss wsuf vs r
             -> gamma_derives_prefix g (s :: ss) (wpre ++ wsuf) (v, vs) r.

I omitted the parameters to save space. It might be better to see the git diff view between my fork and original; I have the same comments there.

sym_derives_prefix g s w v r means: Symbol s can derive a sequence of tokens w (producing semantic value v) with any remaining tokens r, all according to grammar g.

The definition sym_derives_prefix is used, for example, in Corollary LL1_derivation_deterministic. Determinism is encoded as: If we can fathom two derivations, i.e., sym_derives_prefix g s w v r and sym_derives_prefix g s w' v' r', then actually, w = w' /\ r = r'.

2. The table construction algorithm

The table construction algorithm is implemented as a series of Rocq fixpoints (total functions). Each fixpoint computation builds a different set/map needed for the final parse table. These are essentially the Coq implementations of the LL(1) table construction algorithm as described in the parsing background section.

1. NULLABLE set (via mkNullableSet)

In Vermillion, the FIRST map cannot contain epsilons, instead, emptiness is tracked with a separate, NULLABLE set.

Program Fixpoint mkNullableSet' 
        (ps : list production) 
        (nu : NtSet.t)
        { measure (countNullCands ps nu) } :=
  let nu' := nullablePass ps nu in
  if NtSet.eq_dec nu nu' then
    nu
  else
    mkNullableSet' ps nu'.

Each nullablePass adds nonterminals to the set if their productions can be nullable. The measure countNullCands ensures termination by counting how many candidates remain.

1. FIRST, FOLLOW map

Similarly, the FIRST and FOLLOW maps are constructed by individual passes until we reach the fixpoint. We keep a count on the remaining candidates to determine the fixpoint.

1. Parsing table Using the NULLABLE set, the FIRST and FOLLOW maps, we compute the list of entries to add. Then, we fold over the list of entries, adding them one by one to the table, throwing when there are duplicates (by returning an inl).

Definition mkParseTable (ps : list table_entry) :
  Datatypes.sum string parse_table :=
  fold_right addEntry (inr empty_table) ps. (* addEntry throws when we encounter duplicate! *)

Definition parseTableOf (g : grammar) : Datatypes.sum string parse_table :=
  match findDup _ base_production_eq_dec (baseProductions g) with
  | Some b => inl (dupMessage b)
  | None   => 
  let nu    := mkNullableSet g in
    let nu_pf := mkNullableSet_correct g in
    let fi    := mkFirstMap g nu in
    let fi_pf := mkFirstMap_correct g nu nu_pf in
    let fo    := mkFollowMap g nu fi fi_pf in
    let es    := mkEntries nu fi fo g in
    mkParseTable es
  end.

3. Table construction algorithm makes correct parse tables

And now, we bridge the implementation with the specification. The bridging theorems are parseTableOf_sound and parseTableOf_complete:

Theorem parseTableOf_sound : 
  forall (g : grammar) (tbl : parse_table),
    parseTableOf g = inr tbl
    -> parse_table_correct tbl g.

Theorem parseTableOf_complete :
  forall (g : grammar) (tbl : parse_table),
    unique_productions g
    -> parse_table_correct tbl g 
    -> exists (tbl' : parse_table),
      ParseTable.Equal tbl tbl' /\ parseTableOf g = inr tbl'.

The first says: If our table construction fixpoint successfully makes a table, then that table satisfies parse_table_correct, meaning:

1. (Soundness) If there is a nonterminal and lookahead (nt, la) pair that finds a certain gamma in the table, then nt -> gamma must be a production in the grammar with la as the lookahead_for (inductively defined) nt in the gamma production.
2. (Completeness) For all nonterminal -> gamma productions, if a lookahead la is the lookahead_for (inductively defined) for the gamma, then (nonterminal, la) is in the table.

Conversely, if there exists a table satisfying parse_table_correct, then there exists a grammar that makes this exact table under parseTableOf.

How can these be proved? Correctness is defined as soundness + completeness, let’s zoom in on completeness:

Lemma mkParseTable_complete :
  forall (es  : list table_entry)
          (g   : grammar)
          (tbl : parse_table),
    unique_productions g
    -> entries_correct es g
    -> parse_table_correct tbl g
    -> exists tbl',
        ParseTable.Equal tbl tbl'
        /\ mkParseTable es = inr tbl'.

Theorem parseTableOf_complete :
  forall (g : grammar) (tbl : parse_table),
    unique_productions g
    -> parse_table_correct tbl g 
    -> exists (tbl' : parse_table),
      ParseTable.Equal tbl tbl' /\ parseTableOf g = inr tbl'.
Proof.
  intros g tbl Hu Ht.
  unfold unique_productions in Hu; unfold parseTableOf.
  pose proof Hu as Hu'; eapply NoDup_findDup_None_iff in Hu'; rewrite Hu'.
  eapply mkParseTable_complete; eauto.
  eapply mkEntries_correct; eauto.
  - apply mkNullableSet_correct; auto.
  - apply mkFirstMap_correct.
    apply mkNullableSet_correct; auto.
  - apply mkFollowMap_correct; auto.
    apply mkNullableSet_correct; auto.
Qed.

The completeness of the final parse table is encoded in parseTableOf_complete. parseTableOf_complete depends on mkParseTable_complete, which reduces the goal of showing completeness of parseTableOf (constructed by adding entries individually and throwing on duplicates) to showing mkEntries_correct.

This reduction is possible due to this important, bridging lemma:

Lemma invariant_iff_parse_table_correct :
  forall (g : grammar) (es : list table_entry) (tbl : parse_table),
    entries_correct es g
    -> table_correct_wrt_entries tbl es
        <-> parse_table_correct tbl g.

To show mkEntries_correct, we ought to show each construction procedure for each substructure is correct. The key to these proofs is well-founded induction on the number of candidates. For example, on each nullablePass (implementational), the number of null candidates decreases, which coincides with the null candidates increasing in an inductively built nullable.

I don’t fully understand the mechanics of these proofs — there are pieces I haven’t explained, but I hope this gives a big enough picture.

4. Proving properties about parsers

I present the theorem LL1_parse_table_impl_no_left_recursion and its proof. The theorem is written with inductive definitions. But because we have connected the implementational parseTableOf to the inductive definitions, our real algorithms will also enjoy LL1_parse_table_impl_no_left_recursion.

Here is the location of the proof in the grand proof tree:

└── LL1_derivation_deterministic 
    (Unambiguity)
    ├── parse_terminates_without_error 
    │   └── LL1_parse_table_impl_no_left_recursion <--------------------------------------------- We are here!
    |       (Proves that a correct LL(1) parse table cannot have left recursion)
    │       ├── sized_first_sym_det 
    |           (Shows that the size of first set derivations is deterministic)
    │           └── first_sym_rhs_eqs 
    |               (Proves that if two productions for same nonterminal can derive same first token, they must be identical)
    │               └── no_first_follow_conflict 
    |                   (A symbol cannot have same token in both FIRST and FOLLOW sets if nullable)

And here is the theorem and proof:

Lemma LL1_parse_table_impl_no_left_recursion :
  forall (g : grammar) (tbl : parse_table) 
          (x : nonterminal) (la : lookahead),
    parse_table_correct tbl g
    -> ~ left_recursive g (NT x) la.

where left_recursive is defined as an inductive proposition:

Inductive nullable_path (g : grammar) (la : lookahead) :
  symbol -> symbol -> Prop :=
| DirectPath : forall x z gamma f pre suf,
    In (existT _ (x, gamma) f) g.(prods)
    -> gamma = pre ++ NT z :: suf
    -> nullable_gamma g pre
    -> lookahead_for la x gamma g
    -> nullable_path g la (NT x) (NT z)
| IndirectPath : forall x y z gamma f pre suf,
    In (existT _ (x, gamma) f) g.(prods)
    -> gamma = pre ++ NT y :: suf
    -> nullable_gamma g pre
    -> lookahead_for la x gamma g
    -> nullable_path g la (NT y) (NT z)
    -> nullable_path g la (NT x) (NT z).

Definition left_recursive g sym la :=
  nullable_path g la sym sym.

For example, in

A → ε B c
B → ε C d 
C → e

there is a direct nullable path from A to B and from B to C. Therefore, transitively, there is an indirect path from A to C.

The proof works by contradiction. It assumes left recursion exists and derives a contradiction in two cases. There are two cases because left recursion can be built with DirectPath and IndirectPath.

Proof.
  intros g t x la Ht; unfold not; intros Hlr; red in Hlr.
  (* Get the production that starts the left recursion *)
  assert (Hex : exists gamma f,
             In (existT _ (x, gamma) f) g.(prods)
             /\ lookahead_for la x gamma g).
  { apply nullable_path_exists_production in Hlr; auto. }
  destruct Hex as [gamma [f [Hi Hl]]].
  
  (* Split into two cases based on how the lookahead is derived *)
  destruct Hl as [Hfg | [Hng Hfo]].

  ... to be continued

For both cases, the general approach is to say that the length of the nullable path must strictly decrease as we go down the path.

For example, in

A --nullable-path--> B --nullable-path--> C

A’s nullable path is 3, B’s is 2, and C’s is 1.

But since we have left recursion, the path length doesn’t decrease once we get back to the same nonterminal, so we contradict this:

  (* Case 1: DirectPath *)
  - assert (Hf : first_sym g la (NT x)) by (inv Hfg; eauto).
    eapply sized_first_sym_np in Hf; eauto.
    destruct Hf as [n [n' [Hf [Hf' Hlt]]]].
    eapply sized_first_sym_det in Hf; eauto.
    lia.

  (* Case 2: IndirectPath *)  
  - assert (Hns : nullable_sym g (NT x)) by eauto.
    eapply exist_decreasing_nullable_sym_sizes_in_null_path in Hns; eauto.
    destruct Hns as [n [n' [Hs [Hs' Hlt]]]].
    eapply sized_nullable_sym_det in Hs; eauto.
    lia.

For both branches, before the final lia, there are these two hypotheses in the proof state:

Hlt : n' < n
Hf : n' = n

lia automatically observes a contradiction, solving our goal.

1. Encourage you to marinate on problems,
2. Prelude a practical information organization framework,
3. Give you my problems.

I will occasionally update this post with new problems.

Encouragement

I have observed, smart people can explain intricate, problems succinctly and can fluidly back up their points with examples and stories.

They seem to communicate and store information in a natural problem-solution, cause-effect framework. Their brain can constantly juggle numerous problems. Their neural connectivity between concepts are strong.

My thesis: It is the exact act of constantly juggling problems over a long period of time, connecting them with other concepts, infusing them with stories, that makes you smart. It also helps you appear smart, as that information is lucid and ready.

And while the geniuses might be unconsciously doing this, there is nothing preventing us from consciously adapting this practice. Feynman was the first I know to suggest this —

“[To be a genius], you have to keep a dozen of your favorite problems constantly present in your mind, although by and large they will lay in a dormant state. Every time you hear or read a new trick or a new result, test it against each of your twelve problems to see whether it helps.”

Richard Hamming exclaimed the same —

[Most great scientists] have something between 10 and 20 important problems for which they are looking for an attack. And when they see a new idea come up, one hears them say “Well that bears on this problem.”

Pick your problems and set a daily reminder to resurface them.

Organizing Information At Large

There are big problems, small ideas, quick sketches… How do we organize all of these? How do we ingest information? Can we become fluid with all of them? Should the problems we pick only be big challenges?

I present some thoughts and untested hypotheses on these but leave this section partial. Developing a total framework for genius science thinking deserves a whole book.

1. You only know what you can teach. Before you pick your problems, discover what you know by heart: What can you teach a class on, right now? What are you confident in writing a textbook on?

2. There are two tiers of information: Fundamental and junk. Information you deem fundamental make up what you know. Since what you know is a good chunk of who you are, these information make up your identity. Therefore, they are very, very important. After ingestion, they should be queued for prepping into a format ready for scientific communication. They are composed into stories or written in prose. They should be revisited intermittently (active recall). You should consciously classify information as either fundamental or junk. Most information lie in the no mans land of “might be useful”. But, you aren’t going to retrieve or use the “might be useful” unless you need it, so, with time, they are as good as garbage.

3. Your big problems are your super fundamental information. They are your organs, your chakras. When enlisting new fundamental information, you should consider how it relates to your big problems.

4. It may be useful to embark on your “Great Reconstruction”. I will experiment with this. I plan to go through my obsidian app and delete all information that “might be useful”. I will then label each note as uningested, slowly go through them, reingesting them with the rules I posed in 2).

5. Information can be recalled easier if it maintains casual relationships with other information. When I studied Algebra last year, I justified the algebraic rules for an “ideal” as the precise constraints that allow rings to quotient over during canonical decomposition. This is not the way it’s taught, but the two hours I spent finding this casual relationship allowed me to still remember this fact.

My Big Problems

I am formulating my initial problem list as of writing (Dec 2024). I stumbled upon these through personal curiosities, but expect future listings to be inspired by my colleagues, or by you, my reader.

The Expression Problem.

Category: Software engineering.

Enlisted: Dec 2024.

Intro: How can you expand the datatype and extend the functionality orthogonally? As of right now, I know effect systems in Haskell to make for the cleanest approach. But I need to investigate other languages and type-level programming.

Extent of the Curry-Howard correspondence.

Category: Type theory.

Enlisted: Dec 2024.

Intro: Curry-Howard correspondance envelopes proof-as-programs. For example, exists n. n = 0, a proposition, is considered a type. When you construct a term with this type, you have provided a proof for the proposition.

But the correspondance runs deeper than proof-as-programs. The polymorphic lambda calculus is the same as System-F; Many lambda calculi have equivalent power with certain logics; Logic can be encoded in lambda calculi.

Where is the boundary of this interpretation?

Integrating formal verifications in Turing-complete languages.

Category: Type theory.

Enlisted: Dec 2024.

Intro: How can I prove that forall n: nat, n + 0 = n, in say, Python? The coq approach would be to define nat inductively, and prove statement with induction. But what if we just hook this to a SMT solver? Or, maybe forall n: nat, n + 0 doesn’t matter, it’s not something real software writes? I first came across this problem in June 2023 through the magmide repo. I actually conversed with the author through emails as a complete noob at the time. Coincidentally, I am employed on a program that deals precisely with this.

Building a microscope and microbiology for LLMs.

Category: LLM interpretability.

Enlisted: Dec 2024.

Intro: I first came across the field in Dec 2023 through the transformer circuits thread.

Providing more rigor for LLMs.

Category: Category theory, LLM, neurosymbolism.

Intro: We are at a limit with transformers. Can we provide more rigor for the next generation of LLMs? Can you encode logic into them?

Something Quantum.

Category: Quantum.

I know nothing right now. But I’ll slowly develop this. I’m definitely more interested on the algorithmic application side.

and I was already stumped by the code! What in the lens are these snippets —

-- r :: Robot, 
-- robotProgram :: Lens' Robot [Command]
-- p :: Command
(r & robotProgram .~ p)

-- world :: Lens' GameState [[Char]]
-- row, col :: Int
preuse $ world . ix row . ix col

-- inventory :: Lens' GameState (Map Item Int)
inventory . at (Resource h) . non 0 += 1

What’re the functions the fancy symbols like .~? And what do combinators such as preuse and ix do? Hopefully you can understand these after this piece. Kmett’s lenses library is focused around the Lens type, so I first give you a whirlwind tour of Lens (part 1). But to understand the snippet, we need to explore a more general Traversal type, and, how Lens/Traversal interact with State (mtl-ified with MonadState). That will be part 2.

A Tour of Lens

A Lens is basically type synonym for

type Lens s a = forall f. Functor f => (a -> f a) -> s -> f s

Function-wise, a Lens can be thought of as both a getter and a setter. We can transform a Lens s a both into a getter and a setter by applying the Lens with the right functor. s is the larger object that should contain some a.

get :: Lens s a -> (s -> a)
get l s = getConst $ l Const s

over :: Lens s a -> (a -> a) -> (s -> s)
over l f a = runIdentity $ l (\b -> Identity (f b)) a

I explicitly wrapped the (s -> a) in get to emphasize the high-order form. I.e., get is a transformation from Lens s a to a (s -> a). A getter gives you an a from a s. In get’s definition, f is specialized to Const to make everything work.

A setter typically has the form s -> a -> s. I.e., set takes in object s and a constant a to update some inner field with, and gives you back the updated s. Instead of set, we naturally get a more general over here, allowing us to consider the previous a in the update.

The following crucial point will wrap up the background: A Lens s a contains the concrete logic to “hit” an a from a s. For example,

data Person  = Person { age :: Int, address :: Address }
data Address = Address { streetName :: String }

-- Contains the logic to hit the address from a person 
ex1 :: Lens' Person String
ex1 f s = (\streetName' -> s { address = (address s) { streetName = streetName'} }) <$> f ((streetName . address ) s)

-- Contains the logic to hit a Char from a [Char]. The only way to have a valid definition is if 
-- we choose a specific index
ex2 :: Lens' [Char] Char
ex2 f s = (\a' -> setAt 3 a' s) <$> f (s !! 3)

Note, we can also make nonsensical Lens, for example

ex3 :: Lens' String Int
ex3 f s = s <$ f 0

ex4 :: Lens' [Char] Char
ex4 f s = s <$ f 'a'

ex1 :: Lens' String Int should provide a means to get/set an Int in a String, but that’s absurd — String doesn’t contain an Int. However, Lens' allow us to write such a vacuous Lens' String Int. We provide a concrete Int (0 in this case) in order to lift it into f Int via f 0. Once we are in the functor, we apply fmap (const s) :: Int -> String to build a f String (simplified with <$). In fact, we can vacuously write a value of type Lens' s Int.

What about ex2? It should be possible to (unsafely) get/set a Char inside of a [Char]. However, our implementation does not update our s :: [Char] at all. We are again providing a concrete value ('a' :: Char in this case) just to get into f Char, which s <$ latches onto.

For all concrete s and a, Lens' s a can be written vacuously. It is up to you to provide a reasonable definition. After applying its 3 arguments, a sensible Lens' s a should update some a within the given s.

Practice, practice, practice.

or,

Write a lot. And read a lot.

or, for maximum effectiveness,

Start.

Well… Write what? And draw what? Or compose what? I get the gist though, since, once you are serious about learning the craft and start putting in serious time, you naturally and gradually tune to a better learning process. But, I want to alleviate some of that initial anxiety. Some good constraints can liberate.

I’ll propose a linear learning methods that works for many arts. First, an interlude on how machines learn.

The Machine

Heuristic and inductive biases for the machine’s learning process is purposefully designed, sourcing the records of the human mind. Even the most standard algorithm, self-supervised learning, rationally models how we learn. The machine is initially dumb (it is initialized with random weights), but it gets good at, for example drawing, by repeating the following, many, many times:

The machine generates an image. The machine now looks a real artpiece and contrasts its generation with the artpiece (calculating loss). The machine updates itself to better adapt to the artpiece.

Artists are told to do master studies; writers are told to read. But these processes are inert. I think, what is missing, is the original generation preceding the adaptation.

The Adversarial Method

Instead of reading, or plain copying, I do this:

1. Select a passage from an author whose style intrigues you. The granularity I experimented with are the early chapters in Mo Yan’s Big Breasts and Wide Hips (3-4 pages long).
2. Skim the passage. If you have good short term recall of details, return when they vanish. Alternatively, you could skip the skim and elect AI to summarize.
3. The key step: Instead of attempting at your rendition of the entire passage, localize to things that matters using AI. For example, I want to train my “show not tell”, so I paste the passage to Claude, and ask it to replace paragraphs of descriptions with <summary of paragraph>.
4. I fill in the <>s.
5. I critically analyze my work to the authors.

See my prompt and an example conversation here.

Mech Interp is super cool! I’m gonna set aside 13 weeks to study it. In these 13 weeks, I plan to master basic ML math, master transformers, read a couple mech interp papers in depth, and hopefully carry out some small-scaled, original mech interp exploration.

Note, this is a direct mirror of my personal log in my Obsidian vault, and some formatting might not be appropriate (I will format everything at the end).

Timeline

Target: 10/28/2023 to 1/26/2023 (end of my winter break)

Undated Day 1

• Read some basic definitions of Linear Algebra Done Right.

  Undated Day 2

• Finished Linear Algebra Done Right Chapter 1. Re-learnt subspaces, sums of subspaces, direct sums.
• Looking ahead, to solidfy my linear algebra for MI, I should master Chapter 1-3, 5-6, and 7d. More importantly, I need to spend some time everyday in finding connections of the niche linear algebra techniques are used for ML.
• I found one such connection today (querying ChatGPT): Gradients should be initialized with orthonormal matrices in order to preserve the magnitude of gradients.

Day 1

• Read Linear Algebra Done Right Chapter 2 up until the last definition. I think basis and theorems regarding bases drilled in the definition of linear independence and span.
• Tomorrow, I just want to finish up the definition, do a few problems. Then, I want to skim some high-level material on why bases matters for machine learning; in particular, I hear a lot about “orthonormal” bases in ML, when and why do they come up?
• Why bases matter for machine learning - high level view. 📅 2023-10-28 ✅ 2023-10-28

Day 2

• Yesterday i assigned the “why bases matters” task, I have a high-level answer: To address the curse of dimensionality and other dimension related issues. Keywords are privileged, non-privileged bases, PCA, SVD.
  • Resources: https://harrisonpim.com/blog/privileged-vs-non-privileged-bases-in-machine-learning

Day 3

Skipped

Day 4

• Did 15 exercises for [[Chapter 2]]. I didn’t try too hard, I looked at the solution if I can’t solve in 5 mins.

Day 5

Skipped

Day 6

Skipped

Day 7 (11-03-2023)

Wrote MLP forward stuff.

Watched this great video by WhyML on Skip connection and residual blocks.

• Review Batch Normaliztaion, Optimizers, Regularization, Gradient Clipping, Weight Constraints, Weight Normalization, Layer Normalization 📅 2023-11-04 ✅ 2023-11-09
• What is Skip Connections and Residual Blocks? 📅 2023-11-03 ✅ 2023-11-04
• Understand the gradients that are taken. 📅 2023-11-12 ✅ 2023-11-15

Day 8 (11-04-2023)

Studied backpropagation. I used multiple resources: The original sparse encoder article, some random article by ML-dawn, and Brilliant Wiki. But, when I revisited 3b1b’s video, that’s the one that made it all click. Tomorrow, I plan to rewatch the video and take a lot of notes.

Day 9 (11-05-2023)

Rewatched 3b1b’s video and I think all the formulae individually makes sense. Tomorrow, I’ll try to

• Derive the gradients from scratch
• If I get them right, give a shot at drawing derivative diagrams for a MLP
• Implement backprop in MLP.

Day 10-18 (11-06-2023 to 11-14-2023)

Skipped. Not gonna lie, played a little too much minesweeper.

Day 19

• Deleted my online minesweeper account. Started 2 weeks ago and sunk 35 hours into it, no good, those hours will now be redirected to mech interp.
• Watched Neel Nanda’s MI and Math talk and annotated it. The slides are here
• 40 mins into ML street talk episode with Neel Nanda. Take aways:
  • A biologist’s getting hands dirty view might be more appropriate than a mathematician’s view. A good quality of a mech interp researcher is someone who can handle a surprise.

My goals this week is to start understanding transformers well, read this paper, and get a sense of the other techniques I gotta study (dimensionality reduction, Fourier transform even?).

Idea: Analyze transformers that implement simple regexes / text manipulation patterns?

Day 20

• Read the Attention blog post, it is a prior of the Illustrated Transformers guide.

Some knowledge tasks.

• Understand: What is the Curse of Dimensionality? 📅 2023-11-17
• Master PCA 📅 2023-11-19

Inspired by Neel’s talks yesterday, I will run a mech interp notebook this week to get a feel of the tools.

• Run, completely, one mech interp notebook 📅 2023-11-17

生处的坐标，位置不同，头扬的角度不同，思考的事情也必然不同。躺在一只肥猪下看天空，小猪似乎也变成了天蓬元帅。 我写中文时，就容易变得文艺。在搞科研时，只有在户外才引入潮水一般涌来的思路。 通常来讲，文言是文言，数学是数学。可是，哲学家们似乎非常喜欢在黑板上谈心。他们用着 “first principle” 的借口轰炸着 由艺术，由生命而生的伦理。

依我见，伦理不是哲学应所侵犯的领域。伦理是生命，是苦难，是我们哭泣的理由，是人情味。这种味道，还是不要过多去”taxonomize”的好。

您读我刚才写着的时候可能脑海里闪过一些画面：呆板，毫无勃起力的哲学家，数学家，挂个老老的眼镜，低着头，慢吞吞得在黑板上画着圆圈。假若您的确思其画面，那么抱歉，您入了我写这一段篇的圈套。搞纯理论的数学家也可以让我们的生命细胞脉动。

所有的一切推着我们前进

昨天重返了《功夫熊猫1》。其中有一场景十分有趣。

乌龟师傅:

人违逆不了命运。

浣熊师傅:

[猛踹了大树] 但，我可控制桃子什么时候掉落，也可控制它在哪里生长。

乌龟师傅:

对，但无论怎样，一颗桃核总会繁衍一棵桃树。

记得美国脱口秀之王George Carlin说过，气候维护者们总是声称，全球变暖破坏了地球。瞎搞，以前陨石撞地球时对于地球来说不过是挠个痒。其实，我们只是怕气候变暖搞糟了人类。所以，虽然可能有一天，人类会停止繁衍与前进。但这个宇宙永远不会，滴答滴答，微生物又在另一个星球上诞生了。

中文是抽象的

我其实总觉得，我们的中文是抽象的。举个例子，道德经说的“一生二，二生三，三生万物”，似乎概括了数学里“induction”的这个概念。这一点我得留至十一月去多想想。

论“Madman”

十一月再说吧。

I have come to a point in my Haskell journey where I should start learning about other programming languages (PL) fields. Towards the end of my FP journal, I started diving into Category Theory and formal verifications, endeavours that shouldn’t be documented in a “FP Journal”. As such, I’ve decided to start a PL journal, documenting all of my PL ventures. Unlike the previous journal, I do not plan to elaborate on the concepts I made sense of, as these elaborations often turn into word rambles in the moment.

2023

June

28th

Understanding the relationships between LTL (Linear Temporal Logic), Haskell, model-checkers, and proof assistants. Conclusion: TLA+ (model checker) can be used to model LTL statements and verify them. There exists LTL libraries in Haskell but they appear to be more data modelling purposes.

29th

• Chris (from work) sent me two papers:
  • Runtime Verification for LTL and TLTL
  • Alternating Automata and Program Verification These papers supposedly describe how LTL statements can really be translated (down?) to a FSM (Finite State Machine). From there, any language can be used to implement this FSM (since a simple FSM is just a while loop + switch statements). I will zoom in on these tomorrow.
• Watched a video on linear logic. Everyday I’m hearing 5 new jargons, at the end of this week I ought to layout a taxonomy of the topics.

July

1st to 14th

• Read the first 10 pages of the Lamport’s TLA paper that covers TLA motivation and semantics.
• Watched the first lecture of RWTH Aachen University’s Model Checking course.
• Talked to ChatGPT a lot to derive a taxonomy of formal verifications technique. Lectures do better jobs covering these types of information though — ChatGPT don’t really come up with memorable sayings.
• Came across Linear Types, didn’t understand much.
• Submitted my first paper ever (it’s on program analysis) to SCAM’23! I can reveal more if it gets accepted.
• Read the intro of Pierce’s Software Foundations.
• Read the first two chapter of Pierce’s TAPL — currently, I don’t find type theory as interesting as formal verifications. Though, I do believe that enjoyment is a linear combinations of the interestingness of the topic’s pure abstractions, the topic’s applicability, and one’s current understanding of the field. When it comes to type theory, I don’t have any of these.

15th to 19th

• Read the docs of the servant library thoroughly: It’s the first library I encountered that uses DataKinds.
• Read up on the expression problem (encountered through servant’s paper). Supposedly, Object Algebras of OOP or advanced Haskell type features can address it.
• Going back to reading Milewski’s Category Theory for Programmers because I should be knowing what Kelsili Arrow and natural transformations are at this point.
  • Finished Chapter 3. Interesting idea: Think of functions in their uncurried form more. If I think of mappend as m -> (m -> m), I can see it as a mapping between an element of a monoid set to a function acting on that set!

Week 4

• Listened to two episodes of the Haskell Interlude podcast: One with Gabriella Gonzalez, and one with Graham Hutton. Professor Hutton’s honesty and passion was, simply put, inspiring. The also-inspiring Gabriella mentioned two interesting things I’ll look into: Monad Reader and Dhall.
• Listened to Conal Elliot talking about the lost elegance of computation. Unique and poignant philosophy, inspired by Conal’s passion, I ought to read John Backus’s famou 1977 Turing award lecture and read into FRP.
• Read Monad Reader issue 19; learned about the Coroutine monad; I was able to use Iteratee and Generator to successfully implement a basic sketch of a program for work.

August

Week 1

• Spent a weekend in FRP via Heinrich’s guide. Big idea: Behaviors are continous and Events are discrete, but, they can be easily composed and transformed to one another.
• React-banana uses MonadMoment, which is also a MonadFix. I tried reading MonadFix is Time Travel. I only partially understood what’s going on even with after reading another article because I lack a complete understanding of laziness, thunks, and seq, so, I started reading Haskell wikibook’s laziness article.

Week 2

• Finished my internship at TwoSix technologies, looking forward in returning as a formal methods researcher next summer!
• Coming across the following for the first time: Refinement types, cubic type theory, the K framework.
• I want to dedicate my time fully to reading 2 materials: Software Foundations (SF) and the Milewski’s Category Theory handbook, until school begins.
• Finished the Basics chapter of SF’s Logical Foundations (LF) book. Good old functional programming!
• Read Chapter 5-8 of the category theory book. I need to spend some time to gather more examples…

2024

August

Holy snap! I haven’t updated this in year. In the past year I got a lot more comfortable with Haskell —

• I am implementing a clone of hearthstone-battlegrounds in Haskell. I learned mtl-style typeclasses through this.
• I got 60% through the Thinking In Types book.
• I am actively picking up little tricks and gems. For example, in the past month, I discovered the “semantic editor combinator” composition trick and the concept of “algebra blindness” per the recommendation of this list

Week 2

• Biggest problem I resolved this week is writing tests for battlegrounds. In particular, how does one control random behaviors in tests without modifying the game logic (the stuff that is random)? For my case, I find the solution to be twofold —

  • For randomness in high-level functions, e.g., turn :: (MonadRandom m) => CombatState -> m CombatState, take the random values in as argument. So, if the attacker and defender each turn is random, then refactor to turn :: AttackIndex -> DefendIndex -> CombatState -> CombatState.

  • For randomness in card effects, e.g., I wish to control the coiler (which summons 2 random deathrattles) to summon specific deathrattles, build a DSL. Initially, I thought I can do away without a DSL — I delayed the summon effect by changing Summon Card to Summon (MonadRandom m => \combatState -> m Card). But, functions can’t implement Eq. So, I built a DSL that covers all the needs: data CardEffect = Summon Criteria and data Criteria = SpecificCard Card | ByTier Card | ByKeyword Card.

Week 3

• Thought: Be ware of the ambiguity of “power”. I feel no problem phrasing, “A square is more powerful than a Rectangle”, because, a square is a rectangle, and not vice versa. However, consider the fact that “A Lens is a Traversal”. Observing that while a Lens hits one target, Traversal can hit zero or many targets; so, I conclude that while Lens is more powerful from the type perspective, Traversal instead feels more powerful. Perhaps, the better phrasing is using “is a” for specifying type system hierarchy, and “generalizing” instead of “powerful” for operational capability.
• I feel unqualified in many decisions while coding hearthstone-battlegrounds, this pushed me to read a successful Haskell game: swarm, a resource gathering and programming game.
  • swarm uses lens beautifully. I dug deeply into lens and can understand most of the lens code in swarm.
  • swarm comes with its robot programming language. To get theorectically underpinned for understanding swarm-lang, I started WYAH and finished the parsing chapter. But, I believe I need to read the type-system chapter to be ready.

Below lies the original blog: *** Opinion: Ancient mathematicians are smarter.  

But, the Mesopotamians, or ancient Greeks, or Renaissance-undergoing Prussians weren’t just genetically smart: What’re some fundamental principles that fostered such an intellectual environment?

1. Totally Diminishing Marginal Utility

Marginal utility, an Econ jargon, is the satisfaction derived from consuming a product. Diminishing marginal utility observes marginal utilities over all products consumed, and rules that Consuming the (N+1)th item derives less pleasure than consuming the Nth.

But, I’m afraid, due to the abundance of information, ALL marginal utilities on academic materials have decreased: Consuming Euler's Elements of Algebra in the 2000s derives less pleasure than consuming it in the 1600s.

The consequence of abundance is the lost of scarcity, the lost of the human nature to care for vulnerable, precious things.

1. Diminishing Focus

Neil Postman wrote that whole Amusing Ourselves to Death book that I remember reading in high school for actually, self-help purposes. However, what he observed in 1985 about the dangers of TV and media must’ve tripled by today. His main theory was that television reduces important things to mere entertainment, therefore diluting focus and purpose.

1. Less Purpose

On the note of less purpose: Mathematicians were really smart during war times. Alan Turing and his colleagues recruited through crossword puzzle contests cracked the enigma, and the whole space race thing was another level of spectacle (Oh gosh, spectacle, did I just reduce the space race to mere entertainment?).

Although us contemporary folks can still find purpose without war and religion, those purposes were embedded in our systems and simple to follow. Today, we are out of luck, our lives are comparably easier, which ironically makes living a purposeful life harder.