Re: Literate Computer Programming, Document Science and the Web

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