W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2019

Re: Literate Computer Programming, Document Science and the Web

From: Léonie Watson <lwatson@tetralogical.com>
Date: Mon, 21 Oct 2019 12:53:33 +0100
To: Adam Sobieski <adamsobieski@hotmail.com>, "public-webapps@w3.org" <public-webapps@w3.org>
Message-ID: <d53ac22e-0ec2-07f4-c961-f7a299e41d4c@tetralogical.com>
Adam,

Thanks for posting your ideas to the WebApps WG.

New ideas and proposals are typically raised in the Web Incubator 
Community Group (WICG):
https://discourse.wicg.io/t/welcome-to-wicg-discourse/6



If an idea gains traction and support, it may then transfer into a WG 
like WebApps, but the goal is for it to be incubated before that happens.

Hope this helps.
Léonie - WebApps co-chair.


On 21/10/2019 00:08, Adam Sobieski wrote:
> 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
> 

-- 
Director @TetraLogical
Received on Monday, 21 October 2019 12:10:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:15:26 UTC