Global $n$-compact Validation Engine

Module

Parsing

Parse a string to convert it to an LC and process Shorthands that appear in an LC.

Methods

static

makeParser(parserstr) → {Array.<function()>}

Make both a normal and tracing peggy parser from the given string and capture and customize the error formatting, then return both parsers and the original parser (which throws errors but doesn't trace) in an array.

Parameters

  • parserstr string

    the peggy parser definition string

Returns

  • Array.<function()>
    • the normal, tracing, and raw parsers

Source

static

processShorthands(L) → {LogicConcept}

Process Shorthands

In order to make it convenient to enter large documents in putdown notation, it is convenient to use fromPutdown to enter some reserved content in the document that is preprocessed before evaluating the document.

The following are what we have for Shorthands. More might be added later.

  • Scan a document looking for any of the following Shorthands and convert the next (>) or previous (<) sibling to the corresponding type in the asA column.

    Shorthand mark asA
    'BIH>' 'BIH'
    'declare>' 'Declare'
    'rule>' 'Rule'
    'cases>' 'Cases'
    'subs>' 'Subs'
    'thm>' 'Theorem'
    '<thm' 'Theorem'
    'proof>' 'Proof'
    'proof>' 'Proof'
  • Scan for occurrences of the symbol rules>. Its next sibling should be an environment containing given Environments. Mark each child of the next sibling as a Rule and delete both the rules> symbol and the outer environment containing the newly marked Rules. This allows us to use an Environment to mark a lot of consecutive Rulesall at once and then ignore the wrapper Environment. For libraries this is cleaner than trying to mark every Rule withrule>` individually.

  • Scan for occurrences of the symbol λ (or @ for backwards compatibility) and replace that with the symbol "LDE EFA" (which then will still print as '𝜆' but it's what is needed under the hood).

  • Scan for occurrences of the symbol . They are intended to be a shorthand way to enter IFF rules (equivalences). The '≡' should be a child of a Rule environment, and should not be the first or last child. The Rule will then be replaced by the expanded version and the symbols removed, following the cyclic TFAE style of implications. For example, if the Rule has the form :{ a ≡ b c ≡ d } then it will be replaced by :{ {:a {b c}} {:{b c} d } {:d a} }.

  • Scan for occurrences of the symbol . If found it should be the first child of an Application whose second child is a symbol whose text is the text of the comment. Mark that Application with .ignore=true so it is ignored propositionally.

  • Scan for occurrences of the symbol by and mark its previous sibling's .by attribute with the text of its next sibling, which must be a LurchSymbol. Then delete both the by and it's next sibling. Currently used by the Cases tool and the CAS tool.

  • Scan for occurrences of the symbol ✔︎, , and ⁉︎ and mark its previous sibling with .expectedResult 'valid', 'indeterminate', and 'invalid' respectively.

  • Scan a document looking for the symbol <<, which we call a 'marker'. For every marker,

    • if the preceding sibling is an environment, attribute it as a BIH.

    • if the preceding sibling is a declaration, attribute it as a Declare,

    • in either case, finally, delete the marker.

Naturally we have to run this FIRST before anything else. These changes are made in-place - they don't return a copy of the document.

This does no error checking, so << has to be an outermost expression with a previous sibling and λ has to appear in some sensible location and so on.

Parameters

Returns

  • LogicConcept
    • the modified document

Source