RE: Literate Computer Programming, Document Science and the Web

W3C Web Applications Working Group,

The following sketch of a hypothetical new “code-element” element and its attributes is offered for discussion and to clarify upon the contents of the previous letter.

The following sketch intends to informally describe a new element, some of its attributes and a JavaScript API towards advancing Web documents for scenarios including: literate computer programming, computer-aided reasoning, computer-aided mathematical proofs, computer-aided argumentation, computer-aided fact-checking and computational journalism.



Element and Attributes

<code-element service="https://…" service-type="xml-rpc" session="…" index="…" state="…" message="…">…</code-element>

service – A URL for a service with which to process the code elements in a document session or scope. An XML-RPC service, for example, could receive an XML-based request containing a number of code elements’ contents and return an XML-based response with a state and message(s) for each code element.

service-type – The type of or protocol for the service, e.g. XML-RPC.

session – A unique text string identifying the document session or scope that a code element is in. A Web document can contain multiple document sessions or scopes and each of those can contain multiple code elements.

index – The index of a code element in the sequence of code elements within a session or scope (defaults to auto-incrementing the code elements as they occur in document order).

state – A service-specific text value returned by a service for the code element and automatically placed into the attribute’s value for purposes of scripting and styling.

body[data-visible-feedback='true'] code-element[state='ok']:after { content:url('ok.png') }

body[data-visible-feedback='true'] code-element[state='not-ok']:after { content:url('not-ok.png') }

or

body[data-visible-feedback='true'] code-element[state='not-ok'] { text-decoration:underline; text-decoration-style:wavy; text-decoration-color:red }

message – An array of service-specific text string values returned by a service for a specific element and automatically placed into the attribute’s value for purposes of scripting. Where the state attribute could indicate an error, the value(s) of a message attribute could describe the error.

content-editable – Can the user edit the content of the element.



Javascript API

A code-element element would also have a JavaScript API.

Such an API for a code-element element could have a JavaScript property “sessionObject” with which to obtain a session object common to all code elements in a document session or scope and with which to (re)invoke the specified service. Features such as automatic line numbering of the contents of a document session or scope, syntax highlighting for arbitrary syntaxes, intellisense, and so on, are also topical and could be implemented via JavaScript.


Best regards,
Adam Sobieski


________________________________
From: Adam Sobieski <adamsobieski@hotmail.com>
Sent: Friday, October 18, 2019 5:02:23 PM
To: public-webapps@w3.org <public-webapps@w3.org>
Subject: Literate Computer Programming, Document Science and the Web

W3C Web Applications Working Group,

I would like to share some ideas with the group. The ideas pertain to connections between literate computer programming, computer-aided reasoning, computer-aided mathematical proofs, computer-aided argumentation, computer-aided fact-checking and computational journalism.

A summary of the ideas is that documents can include code regions for content in programming languages, machine-readable syntaxes, or natural languages. These code regions in word processors or IDE’s connect to back end systems, via extensions, to provide features including presenting users with visual hints and feedback. Such visual hints and feedback could pertain to the correctness of programming language portions, to epistemological factors pertaining to fact-checking, or to the verification and correctness of reasoning or argumentation.

While scenarios for both word processors and IDE’s are described, these document-related ideas also pertain to Web documents.

I hope that you find the ideas to be interesting. They are indicated below and are available at: https://www.linkedin.com/pulse/general-purpose-literate-programming-environments-adam-sobieski/ .

If you do find these ideas to be interesting, please take a minute to vote for them in the Microsoft Word and Microsoft Visual Studio feature request areas.

Microsoft Word feature request area: https://word.uservoice.com/forums/304924-word-for-windows-desktop-application/suggestions/38803918-general-purpose-literate-programming-environments .

Microsoft Visual Studio feature request area: https://developercommunity.visualstudio.com/idea/775100/general-purpose-literate-programming-environments.html .

Thank you.


Introduction

Literate programming is a programming paradigm first introduced by Donald Knuth. In literate programming, a computer program is accompanied by a natural language explanation of its logic. In literate programming, a natural-language document contains a number of code regions.

Expanding upon the literate programming paradigm, we can envision rich, full-fledged word-processing documents which contain code regions. Such code regions could connect to back-end systems via extensions to literate document authoring or viewing software. Such code regions could be adorned with visual hints and feedback items depending upon the contents of the code regions.

Potential uses of general-purpose literate programming environments include: literate computer programming, computer-aided reasoning, computer-aided mathematical proofs, computer-aided argumentation, computer-aided fact-checking and computational journalism.

Potential benefits of such environments include: the advancement of artificial intelligence, the advancement of scholarly and scientific communication, and the advancement of science, technology, engineering and mathematics.

Code Regions

Code regions are document elements which contain content in programming languages, other machine-readable languages, or natural languages. Code regions could be either inline or block elements in documents, flowing within regions of text or positioned between regions of text.

Via extensions to general-purpose literate programming environments, collections of code regions can be connected to back-end software. Code regions are envisioned as participating in document-based sessions or scopes. Such sessions or scopes would allow for content from multiple code regions to be processed as a sequential collection, for code region content to be processed in contexts, and for meaningful visual hints and feedback to be provided.

General-purpose literate programming environments could provide users with visual hints and feedback upon code regions as well as entire documents. Code regions connected to back ends pertaining to programming languages could provide users with help, information, warnings and errors. Code regions connected to back ends pertaining to fact-checking could provide users with a number of epistemological visual hints and feedback items. Code regions connected to back ends pertaining to automated reasoning or automated theorem proving could provide users with visual hints and feedback related to verification or correctness.

Back Ends

A back end is any compiler, interpreter, runtime environment, automated theorem prover, automated reasoner, fact-checking system, or other software system which can be encapsulated via an extension to provide a set of features to a literate document authoring or viewing environment.

As envisioned, general-purpose literate programming environments could connect to any number of back ends via extensions.

Back ends could be hosted locally on the machines presenting documents to users, hosted on remote servers, or hosted on the cloud.

One can envision literate documents which have multiple document-based sessions or scopes and one can envision literate documents which connect to multiple back ends simultaneously.

Document Portability

Literate documents could either be authored via a new software, e.g. Visual Studio Notebook, or from a versioned or extended existing software, e.g. Microsoft Word or Visual Studio. As envisioned, literate documents could also be viewed with word processing software, e.g. Microsoft Word, which would ensure the portability of literate documents and ease the sharing of such documents.

One file format or a small set of file formats common across back ends would also ensure the portability of literate documents and ease the sharing of such documents. A literate document could be, for example, a .docx file, an .odt file, or exportable to such file formats, regardless of which extensions it utilizes to connect to arbitrary back ends.

The Advancement of Artificial Intelligence

Beyond literate computer programming scenarios, extensible general-purpose literate programming environments could function as universal front ends for artificial intelligence systems such as fact-checking systems, automated theorem provers, and automated reasoners.

Users could, for instance, author argumentative essays and utilize code regions to show that their arguments were valid and machine-verifiable.

The ease of authoring, viewing and sharing literate documents which utilize artificial intelligence back ends could invigorate artificial intelligence research and development.

Conclusion

Extensible word processors or code editors, general-purpose literate programming environments, were described and some of the many uses and benefits of such environments were indicated.


Best regards,
Adam Sobieski