Skip to content

Latest commit

 

History

History
102 lines (64 loc) · 8.89 KB

to_refactor.md

File metadata and controls

102 lines (64 loc) · 8.89 KB

The various fragments / sub-languages of Mini L4

The type declarations / data modelling sub-language

This differs from the current JSON transpiler in that

  • it has more support for metadata, whether as 'general,' schema-global metadata, or metadata that's specific to a property
  • it supports open sums and union types
  • it's textual
  • it's not afraid to look a bit more like a conventional PL, since the people writing the data models will typically have programming experience, and since it wouldn't be hard to add support for things that help explain the data model -- e.g. intuitive visualizations and a 'preview mode' that explains the data model in more ordinary natural language terms
    • [TODO] plug into visualizations / a diagrammatic UI that'll help with understanding the data model
    • [MAYBE] along with a GUI for editing or crafting a data model from scratch?

Langium notes

To factor a grammar into multiple sub-grammars: https://github.com/eclipse-langium/langium/tree/main/examples/requirements

Things to think about

IDE protocol / synchronizing state between, e.g., a textual editor and a diagrammatic one

Concrete syntax

  • Tonto's syntax choices are helpful -- they seemed to have put quite a bit of effort into finding intuitive names, and their language was "designed to allow transformation to a number of languages including UML (more specifically OntoUML), OWL (for gUFO-based ontologies), Alloy" etc

Visualizations and Explainability

Useful links:

Explainability

Visual diagramming languages

How to get interop --- in particular, how to enabling interfacing with L4 from other languages

  1. Have one L4 runtime; put it behind a REST API or use some sort of RPC (and maybe also offer more ergonomic wrappers around http or rpc clients, e.g. in the same way that the OpenAPI python lib basically wraps their REST API; c.f. also things like vscode rpc)

  2. If the runtime is in Haskell: use the FFI (e.g. go through C).

Using automated reasoning to help simplifying statues / legalese, via checking equivalences

An example of a convoluted piece of regulation: the US Tax Code, in particular I.R.C. § 163, which is about the deductibility of interest.

Quote from "Constituencies and Control in Statuory Drafting":

That statute states a broad general rule: “[t]here shall be allowed as a deduction all interest paid or accrued within the taxable year on indebtedness.”56 But, much farther down in the statute, it creates a large exception: § 163(h)(1) states that “personal interest” is not deductible, thereby excepting personal interest from the ambit of the general rule. Making matters more complicated, § 163(h)(2) then creates an exception to that exception: It defines “personal interest” to exclude certain items including, significantly, “qualified residence interest." This is the basis for the home mortgage interest deduction.

The entire disallowance of personal interest in §163(h) threatens to swallow the broad general rule in § 163(a) that all interest is deductible, and in fact substantially changes the principle stated in the general rule to the point where one wonders why the broad general rule was necessary. Moreover, the exception to the exception in § 163(h)(2) buries the intricate and important rules allowing home mortgage interest deductions deep within the statute

The statute could, alternatively, be written using a much narrower rule that is circumscribed using a defined term, while achieving the same substantive outcome. For example:

Narrow Rule: Approved Business Interest and Approved Personal Interest are deductible.

Defined Term 1: Approved Business Interest includes ___.

Defined Term 2: Approved Personal Interest includes ___.

In short, rather than stating a broad general rule that all interest is deductible followed by large exceptions, the statute could have articulated a narrower rule stating that only certain “approved interest” is deductible, and then could have defined that term.

IDEA: Having a way to automatedly checking the logical (or 'practical / outcome') equivalence of these two formulations would presumbly be helpful, as it was with Forge. We should try to support that.

Inspiration / further reading

Deontic modality / expressing requirements

On keeping the underlying language grammar relatively constrained, but still understandable to non-professional-programmers via UI/UX

  • The Enso Language, a language for data processing, seems to also subscribe to a lot of the same tenets, e.g.
    • "Explicit Over Implicit: The design of Enso and its libraries should always account for making all behaviour explicit."
    • "Unified Syntax: The language syntax should be simple, concise, and be usable on both the type and term levels.
    • "Choice in a language inherently creates myriad ways to do things. This is singularly unhelpful in any programming language, let alone one intended to span all experience levels, as it increases the cognitive burden of using the language."