Abstract Wikipedia Mailing List,
Hello. Congratulations on launching the new and exciting Wikilambda and Abstract Wikipedia projects.
Which Programming Languages?
Which programming languages are to be developed with on Wikilambda for use with Abstract Wikipedia? Might a new programming language be useful? Might it be useful to transpile a new programming language into an existing one (e.g. resembling TypeScript and JavaScript)?
Models of Function Definitions
On the topics of programming language design, while we most often consider functions as being comprised of signatures and bodies, might it be useful to consider models of functions with more components? We could express such things with multiple, nested “{}” brackets or scopes.
In some models, a function definition might include a guard, preconditions, a body, and effects.
Inspired by PDDL:
function foo(…) { guard { /* … */ } preconditions { /* … */ } body { /* … */ } effects { /* … */ } }
In other models, a function definition might include requires, a body, and ensures.
Inspired by code contracts:
function foo(…) { requires { /* … */ } body { /* … */ } ensures { /* … */ } }
Such models can be phrased as transformations or mappings from existing languages which separate and organize varieties of content which frequently occur in function body definitions.
Structured Comments, Metadata and Versioning
Structured content (e.g. XML) in comments is both useful and increasingly popular. Structured comments can provide extensible metadata for functions, ease the searching for functions in large collections, and make possible the automatic generation of documentation.
Structured comments could be processed and utilized by the Wikilambda project to provide features.
Also, some programming languages (e.g. C#, Java) have the expressiveness of metadata attributes which can adorn methods and their parameters. A useful attribute is [Obsolete] which supports the use of messages to make use of a newer version of a function, e.g. [Obsolete(“Consider use of foo_2 instead.”)].
Via structured comments, attributes, or other means, the capability of adorning functions with versioning-related metadata would simplify versioning scenarios on evolving crowdsourced resources.
Namespaces and Modules
Namespaces and modules can be useful when organizing large collections of functions. With namespaces or modules, multiple paradigms or ecosystems of functions could coexist in a crowdsourced resource for use in natural language generation scenarios.
Global Variables and Runtime Environment API
Global variables, such as the currently desired natural language for output, could be provided by the runtime environment. An API could be specified for the runtime environment.
Output Streams, Logging and Diagnostic Events
When editing / developing Wikilambda content for use on Abstract Wikipedia, it would be convenient to be able to output to multiple streams, to log, or to raise typed events. It would also be useful to be able to aggregate, organize and view these diagnostic outputs with a configurable granularity or verbosity.
Developer Experiences with the Rendering of Natural Language
A possible user experience for Wikilambda editors / developers is having a means of toggling a developer mode or debugging mode on Abstract Wikipedia such that one could view rendered articles and hover over natural language output to view relevant diagnostic messages in hoverboxes.
Another possible user experience for Wikilambda editors / developers is having a means of toggling a developer mode or debugging mode on Abstract Wikipedia such that visual indicators for diagnostic messages would be placed in a margin to the side of rendered natural language output.
Best regards, Adam Sobieski
Le ven. 3 juil. 2020 à 18:50, Adam Sobieski adamsobieski@hotmail.com a écrit :
Abstract Wikipedia Mailing List,
Hello. Congratulations on launching the new and exciting Wikilambda and Abstract Wikipedia projects.
I am very excited by wikilambda and abstract wikipedia because it intersects with several of my projects.
Which Programming Languages?
Which programming languages are to be developed with on Wikilambda for use with Abstract Wikipedia?
Might a new programming language be useful?
A new programming language will be a mistake because it will increase friction and reduce the ease of adoption, also it will require to rebuild the wealth of documentation that exists for existing programming languages. It is sure that people do not love to learn new languages. wikilambda should be a trampoline toward regular (?) programming hence if / when possible not re-invent the wheel.
I already did that research for myself and find that scheme hits a sweet spot (even if there is a lot of parentheses). Wikilambda will probably not need call/cc (but might require exceptions) and macros. So, it will make the implementation much much easier. I mentioned the parentheses, well there are sugar syntaxes that allow you to work around it. In particular, Racket is working on a wanna-be mainstream language that will be the best of all worlds... See https://github.com/racket/rhombus-brainstorming/blob/master/resources/goals.....
Might it be useful to transpile a new programming language into an existing one (e.g. resembling TypeScript and JavaScript)?
That will be great, for sure. I think the best target will be Web Assembly.
Models of Function Definitions
On the topics of programming language design, while we most often consider functions as being comprised of signatures and bodies, might it be useful to consider models of functions with more components? We could express such things with multiple, nested “{}” brackets or scopes.
In some models, a function definition might include a guard, preconditions, a body, and effects.
Inspired by PDDL:
function foo(…) { guard { /* … */ } preconditions { /* … */ } body { /* … */ } effects { /* … */ } }
It seems to me it is similar to Racket contracts. I am not very familiar with those. I will prefer that complexity to be opt-in, unlike the previous generation of statically typed programming language (C, C++, Java) and which is to some extent still the case (Rust, in particular, is not very friendly to the newbie even seasoned developer).
My idea about the subject of "specifying" the expected behavior of the program inside the program is to rely on "asserts" which are opt-in and can be disabled. The idea is to infer types from asserts. Remain the question of who to specify exceptions (which is missing from Python's gradual/optional typing facility).
In other models, a function definition might include requires, a body, and ensures.
Inspired by code contracts:
function foo(…) { requires { /* … */ } body { /* … */ } ensures { /* … */ } }
Such models can be phrased as transformations or mappings from existing languages that separate and organize varieties of content that frequently occur in function body definitions.
I prefer to imagine a programing language as a sandbox. And document patterns and designs.
Structured Comments, Metadata and Versioning
Structured content (e.g. XML) in comments is both useful and increasingly popular. Structured comments can provide extensible metadata for functions, ease the searching for functions in large collections, and make possible the automatic generation of documentation.
I am not against the idea of comments. That said, I am not sure what structured means in this contexte. XML to document functions? Seriously? Again, I think I prefer complexity to be opt-in, and help spread good practice through IDE, linter and other toolings.
Structured comments could be processed and utilized by the Wikilambda project to provide features.
Certainly comments will be useful.
Also, some programming languages (e.g. C#, Java) have the expressiveness of metadata attributes which can adorn methods and their parameters. A useful attribute is [Obsolete] which supports the use of messages to make use of a newer version of a function, e.g. [Obsolete(“Consider use of foo_2 instead.”)].
That can be scraped from code... Adding "adornement" would complicate the syntax and increase the surface and required knowledge necessary to play with the language. I imagine that simply having a function that is "log.warning("deprecated", ...)" is good enough.
Namespaces and Modules
Namespaces and modules can be useful when organizing large collections of functions. With namespaces or modules, multiple paradigms or ecosystems of functions could coexist in a crowdsourced resource for use in natural language generation scenarios.
Not necessarily, content-addressable code does not require namespaces.
Global Variables and Runtime Environment API
Global variables, such as the currently desired natural language for output, could be provided by the runtime environment. An API could be specified for the runtime environment.
I was under the impression that global variables were evil!
Output Streams, Logging and Diagnostic Events
When editing / developing Wikilambda content for use on Abstract Wikipedia, it would be convenient to be able to output to multiple streams, to log, or to raise typed events. It would also be useful to be able to aggregate, organize and view these diagnostic outputs with a configurable granularity or verbosity.
Developer Experiences with the Rendering of Natural Language
A possible user experience for Wikilambda editors / developers is having a means of toggling a developer mode or debugging mode on Abstract Wikipedia such that one could view rendered articles and hover over natural language output to view relevant diagnostic messages in hoverboxes.
Another possible user experience for Wikilambda editors / developers is having a means of toggling a developer mode or debugging mode on Abstract Wikipedia such that visual indicators for diagnostic messages would be placed in a margin to the side of rendered natural language output.
Best regards,
Adam Sobieski
Amirouche,
I see your points about a new programming language potentially causing friction and reducing ease of adoption.
I found this useful document: https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Plan . It appears that JavaScript [1] and Lua [2] are in a group of languages for initial consideration for Wikilambda and that Python [3] as well as Web Assembler, PHP, Rust, C/C++, R, Swift, Go, and others [4] are planned for later, eventual consideration.
We seem to agree that structured comments could be useful for providing features including: extensible metadata for functions, ease the searching for functions in large collections, and make possible the automatic generation of documentation.
I disagree that global objects are evil; after searching the Web for concerns, I do see that they should be used with care. Without global variables, global objects or global scripting environment API, many functions would have the same, arguably redundant, parameters – for example the output natural language. We could broaden that set of parameters which describe NLG output by adding reading level and verbosity. There could, then, be a set of global parameters which describes desired NLG output which would, otherwise, have to be passed to numerous functions as arguments.
I’m brainstorming on how to provide convenience for NLG developers. An envisioned developer experience is having a means of toggling a developer mode or debugging mode when viewing the hypertext NLG output on Abstract Wikipedia to then be able to hover over content to view relevant diagnostic messages in hoverboxes. Another envisioned developer experience is having a means of toggling a developer mode or debugging mode to view visual indicators for diagnostic messages in a margin to the side of rendered natural language hypertext output.
I wonder what you and others in the group envision in terms of developer experiences while working on Wikilambda and inspecting natural language hypertext outputs on Abstract Wikipedia?
I’m also starting to think about the many topics broached in the plan document: https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Plan , e.g. IDE integration features [5].
A topic that I didn’t see mentioned yet in the plan document is automatic natural language measurement or evaluation. Software tools in the categories of automatic essay scoring, grammar checking, readability measurement, or natural language evaluation, e.g. Coh-Metrix [6], could be of use for automatically measuring articles in a number of ways. Perhaps bots could measure articles as they are updated and report their data the developer community.
Best regards, Adam
[1] https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Plan#Task_P1.12:_JavaScri... [2] https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Plan#Task_P1.15:_Lua-base... [3] https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Plan#Task_O6:_Python-base... [4] https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Plan#Task_O7:_Implementat... [5] https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Plan#Task_O25:_Integrate_... [6] http://cohmetrix.com/
From: Amirouche Boubekkimailto:amirouche.boubekki@gmail.com Sent: Friday, July 3, 2020 2:19 PM To: General public mailing list for the discussion of Abstract Wikipedia (aka Wikilambda)mailto:abstract-wikipedia@lists.wikimedia.org Subject: Re: [Abstract-wikipedia] Wikilambda and Abstract Wikipedia
Le ven. 3 juil. 2020 à 18:50, Adam Sobieski adamsobieski@hotmail.com a écrit :
Abstract Wikipedia Mailing List,
Hello. Congratulations on launching the new and exciting Wikilambda and Abstract Wikipedia projects.
I am very excited by wikilambda and abstract wikipedia because it intersects with several of my projects.
Which Programming Languages?
Which programming languages are to be developed with on Wikilambda for use with Abstract Wikipedia?
Might a new programming language be useful?
A new programming language will be a mistake because it will increase friction and reduce the ease of adoption, also it will require to rebuild the wealth of documentation that exists for existing programming languages. It is sure that people do not love to learn new languages. wikilambda should be a trampoline toward regular (?) programming hence if / when possible not re-invent the wheel.
I already did that research for myself and find that scheme hits a sweet spot (even if there is a lot of parentheses). Wikilambda will probably not need call/cc (but might require exceptions) and macros. So, it will make the implementation much much easier. I mentioned the parentheses, well there are sugar syntaxes that allow you to work around it. In particular, Racket is working on a wanna-be mainstream language that will be the best of all worlds... See https://github.com/racket/rhombus-brainstorming/blob/master/resources/goals.....
Might it be useful to transpile a new programming language into an existing one (e.g. resembling TypeScript and JavaScript)?
That will be great, for sure. I think the best target will be Web Assembly.
Models of Function Definitions
On the topics of programming language design, while we most often consider functions as being comprised of signatures and bodies, might it be useful to consider models of functions with more components? We could express such things with multiple, nested “{}” brackets or scopes.
In some models, a function definition might include a guard, preconditions, a body, and effects.
Inspired by PDDL:
function foo(…) { guard { /* … */ } preconditions { /* … */ } body { /* … */ } effects { /* … */ } }
It seems to me it is similar to Racket contracts. I am not very familiar with those. I will prefer that complexity to be opt-in, unlike the previous generation of statically typed programming language (C, C++, Java) and which is to some extent still the case (Rust, in particular, is not very friendly to the newbie even seasoned developer).
My idea about the subject of "specifying" the expected behavior of the program inside the program is to rely on "asserts" which are opt-in and can be disabled. The idea is to infer types from asserts. Remain the question of who to specify exceptions (which is missing from Python's gradual/optional typing facility).
In other models, a function definition might include requires, a body, and ensures.
Inspired by code contracts:
function foo(…) { requires { /* … */ } body { /* … */ } ensures { /* … */ } }
Such models can be phrased as transformations or mappings from existing languages that separate and organize varieties of content that frequently occur in function body definitions.
I prefer to imagine a programing language as a sandbox. And document patterns and designs.
Structured Comments, Metadata and Versioning
Structured content (e.g. XML) in comments is both useful and increasingly popular. Structured comments can provide extensible metadata for functions, ease the searching for functions in large collections, and make possible the automatic generation of documentation.
I am not against the idea of comments. That said, I am not sure what structured means in this contexte. XML to document functions? Seriously? Again, I think I prefer complexity to be opt-in, and help spread good practice through IDE, linter and other toolings.
Structured comments could be processed and utilized by the Wikilambda project to provide features.
Certainly comments will be useful.
Also, some programming languages (e.g. C#, Java) have the expressiveness of metadata attributes which can adorn methods and their parameters. A useful attribute is [Obsolete] which supports the use of messages to make use of a newer version of a function, e.g. [Obsolete(“Consider use of foo_2 instead.”)].
That can be scraped from code... Adding "adornement" would complicate the syntax and increase the surface and required knowledge necessary to play with the language. I imagine that simply having a function that is "log.warning("deprecated", ...)" is good enough.
Namespaces and Modules
Namespaces and modules can be useful when organizing large collections of functions. With namespaces or modules, multiple paradigms or ecosystems of functions could coexist in a crowdsourced resource for use in natural language generation scenarios.
Not necessarily, content-addressable code does not require namespaces.
Global Variables and Runtime Environment API
Global variables, such as the currently desired natural language for output, could be provided by the runtime environment. An API could be specified for the runtime environment.
I was under the impression that global variables were evil!
Output Streams, Logging and Diagnostic Events
When editing / developing Wikilambda content for use on Abstract Wikipedia, it would be convenient to be able to output to multiple streams, to log, or to raise typed events. It would also be useful to be able to aggregate, organize and view these diagnostic outputs with a configurable granularity or verbosity.
Developer Experiences with the Rendering of Natural Language
A possible user experience for Wikilambda editors / developers is having a means of toggling a developer mode or debugging mode on Abstract Wikipedia such that one could view rendered articles and hover over natural language output to view relevant diagnostic messages in hoverboxes.
Another possible user experience for Wikilambda editors / developers is having a means of toggling a developer mode or debugging mode on Abstract Wikipedia such that visual indicators for diagnostic messages would be placed in a margin to the side of rendered natural language output.
Best regards,
Adam Sobieski
_______________________________________________ Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
Hi Adam, Hi Amirouche,
thank you for this interesting exchange!
Just one thing - you touch on a lot of different topics, and I love that because it shows how excited you are about the project. Thank you for that excitement and energy! It also makes it hard to make sure that ideas are captured and properly discussed.
For longer texts and essays and design notes, it may be easier to have them on wiki - emails might not be the ideal format for that. I plan to put a few more texts on the wiki in the next few days. This will allow to break the texts down and make sure the discussion is actionable. For the mailing list, I think it will make sense to have more focussed discussions.
In that spirit, I'll just grab a single topic out of the many that are touched upon in this thread: programming languages. One suggestion was to introduce a new programming language. And I have to say, I am not against this, but there are a number of considerations with that. - designing a new programming language is quite a bit of work - implementing a new programming language is a little work - socializing a new programming language is a huge amount of work
The goal for the Wiki of Functions is to provide a catalog of function definitions / interfaces, which in turn can have several implementations, and these implementations can be in different programming languages.
My assumption is that the community that runs the function wiki will have the responsibility to decide which programming languages to allow for implementations, and what needs to be in place to support a programming language (e.g. a syntax checker? a parser? an evaluator?). This will be discussions we will have in the future.
Now when the actual functions are being evaluated, the evaluation engine can only use implementations that it knows how to run. And I expect that different evaluation engines will support different programming languages. This is why we listed JavaScript as the first language - this allows us to have evaluation engines in the browser as well on the server side with comparably less effort. But not all programming languages that the Function wiki supports have to be supported by all evaluation engines.
So, if a new programming language is to be developed and integrated, sure! In fact, as I wrote in the technical paper, I think that the function wiki might be a boon for bootstrapping new programming languages. But unless there is a compelling reason, I would not regard it in scope of the core team to design and implement a new programming language.
I hope that makes sense, Denny
On Fri, Jul 3, 2020 at 4:12 PM Adam Sobieski adamsobieski@hotmail.com wrote:
Amirouche,
I see your points about a new programming language potentially causing friction and reducing ease of adoption.
I found this useful document: https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Plan . It appears that JavaScript [1] and Lua [2] are in a group of languages for initial consideration for Wikilambda and that Python [3] as well as Web Assembler, PHP, Rust, C/C++, R, Swift, Go, and others [4] are planned for later, eventual consideration.
We seem to agree that structured comments could be useful for providing features including: extensible metadata for functions, ease the searching for functions in large collections, and make possible the automatic generation of documentation.
I disagree that global objects are evil; after searching the Web for concerns, I do see that they should be used with care. Without global variables, global objects or global scripting environment API, many functions would have the same, arguably redundant, parameters – for example the output natural language. We could broaden that set of parameters which describe NLG output by adding reading level and verbosity. There could, then, be a set of global parameters which describes desired NLG output which would, otherwise, have to be passed to numerous functions as arguments.
I’m brainstorming on how to provide convenience for NLG developers. An envisioned developer experience is having a means of toggling a developer mode or debugging mode when viewing the hypertext NLG output on Abstract Wikipedia to then be able to hover over content to view relevant diagnostic messages in hoverboxes. Another envisioned developer experience is having a means of toggling a developer mode or debugging mode to view visual indicators for diagnostic messages in a margin to the side of rendered natural language hypertext output.
I wonder what you and others in the group envision in terms of developer experiences while working on Wikilambda and inspecting natural language hypertext outputs on Abstract Wikipedia?
I’m also starting to think about the many topics broached in the plan document: https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Plan , e.g. IDE integration features [5].
A topic that I didn’t see mentioned yet in the plan document is automatic natural language measurement or evaluation. Software tools in the categories of automatic essay scoring, grammar checking, readability measurement, or natural language evaluation, e.g. Coh-Metrix [6], could be of use for automatically measuring articles in a number of ways. Perhaps bots could measure articles as they are updated and report their data the developer community.
Best regards,
Adam
[1] https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Plan#Task_P1.12:_JavaScri...
[2] https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Plan#Task_P1.15:_Lua-base...
[3] https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Plan#Task_O6:_Python-base...
[4] https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Plan#Task_O7:_Implementat...
[5] https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Plan#Task_O25:_Integrate_...
*From: *Amirouche Boubekki amirouche.boubekki@gmail.com *Sent: *Friday, July 3, 2020 2:19 PM *To: *General public mailing list for the discussion of Abstract Wikipedia (aka Wikilambda) abstract-wikipedia@lists.wikimedia.org *Subject: *Re: [Abstract-wikipedia] Wikilambda and Abstract Wikipedia
Le ven. 3 juil. 2020 à 18:50, Adam Sobieski adamsobieski@hotmail.com a écrit :
Abstract Wikipedia Mailing List,
Hello. Congratulations on launching the new and exciting Wikilambda and
Abstract Wikipedia projects.
I am very excited by wikilambda and abstract wikipedia because it intersects with several of my projects.
Which Programming Languages?
Which programming languages are to be developed with on Wikilambda for
use with Abstract Wikipedia?
Might a new programming language be useful?
A new programming language will be a mistake because it will increase friction and reduce the ease of adoption, also it will require to rebuild the wealth of documentation that exists for existing programming languages. It is sure that people do not love to learn new languages. wikilambda should be a trampoline toward regular (?) programming hence if / when possible not re-invent the wheel.
I already did that research for myself and find that scheme hits a sweet spot (even if there is a lot of parentheses). Wikilambda will probably not need call/cc (but might require exceptions) and macros. So, it will make the implementation much much easier. I mentioned the parentheses, well there are sugar syntaxes that allow you to work around it. In particular, Racket is working on a wanna-be mainstream language that will be the best of all worlds... See
https://github.com/racket/rhombus-brainstorming/blob/master/resources/goals.... .
Might it be useful to transpile a new programming language into an
existing one (e.g. resembling TypeScript and JavaScript)?
That will be great, for sure. I think the best target will be Web Assembly.
Models of Function Definitions
On the topics of programming language design, while we most often
consider functions as being comprised of signatures and bodies, might it be useful to consider models of functions with more components? We could express such things with multiple, nested “{}” brackets or scopes.
In some models, a function definition might include a guard,
preconditions, a body, and effects.
Inspired by PDDL:
function foo(…) { guard { /* … */ } preconditions { /* … */ } body { /* … */ } effects { /* … */ } }
It seems to me it is similar to Racket contracts. I am not very familiar with those. I will prefer that complexity to be opt-in, unlike the previous generation of statically typed programming language (C, C++, Java) and which is to some extent still the case (Rust, in particular, is not very friendly to the newbie even seasoned developer).
My idea about the subject of "specifying" the expected behavior of the program inside the program is to rely on "asserts" which are opt-in and can be disabled. The idea is to infer types from asserts. Remain the question of who to specify exceptions (which is missing from Python's gradual/optional typing facility).
In other models, a function definition might include requires, a body,
and ensures.
Inspired by code contracts:
function foo(…) { requires { /* … */ } body { /* … */ } ensures { /* … */ } }
Such models can be phrased as transformations or mappings from existing
languages that separate and organize varieties of content that frequently occur in function body definitions.
I prefer to imagine a programing language as a sandbox. And document patterns and designs.
Structured Comments, Metadata and Versioning
Structured content (e.g. XML) in comments is both useful and
increasingly popular. Structured comments can provide extensible metadata for functions, ease the searching for functions in large collections, and make possible the automatic generation of documentation.
I am not against the idea of comments. That said, I am not sure what structured means in this contexte. XML to document functions? Seriously? Again, I think I prefer complexity to be opt-in, and help spread good practice through IDE, linter and other toolings.
Structured comments could be processed and utilized by the Wikilambda
project to provide features.
Certainly comments will be useful.
Also, some programming languages (e.g. C#, Java) have the expressiveness
of metadata attributes which can adorn methods and their parameters. A useful attribute is [Obsolete] which supports the use of messages to make use of a newer version of a function, e.g. [Obsolete(“Consider use of foo_2 instead.”)].
That can be scraped from code... Adding "adornement" would complicate the syntax and increase the surface and required knowledge necessary to play with the language. I imagine that simply having a function that is "log.warning("deprecated", ...)" is good enough.
Namespaces and Modules
Namespaces and modules can be useful when organizing large collections
of functions. With namespaces or modules, multiple paradigms or ecosystems of functions could coexist in a crowdsourced resource for use in natural language generation scenarios.
Not necessarily, content-addressable code does not require namespaces.
Global Variables and Runtime Environment API
Global variables, such as the currently desired natural language for
output, could be provided by the runtime environment. An API could be specified for the runtime environment.
I was under the impression that global variables were evil!
Output Streams, Logging and Diagnostic Events
When editing / developing Wikilambda content for use on Abstract
Wikipedia, it would be convenient to be able to output to multiple streams, to log, or to raise typed events. It would also be useful to be able to aggregate, organize and view these diagnostic outputs with a configurable granularity or verbosity.
Developer Experiences with the Rendering of Natural Language
A possible user experience for Wikilambda editors / developers is having
a means of toggling a developer mode or debugging mode on Abstract Wikipedia such that one could view rendered articles and hover over natural language output to view relevant diagnostic messages in hoverboxes.
Another possible user experience for Wikilambda editors / developers is
having a means of toggling a developer mode or debugging mode on Abstract Wikipedia such that visual indicators for diagnostic messages would be placed in a margin to the side of rendered natural language output.
Best regards,
Adam Sobieski
Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
Denny,
That makes sense. I’m expanding upon and revising a list of ideas and design notes to add to a wiki page for discussion.
The topics include:
1. Structured Comments, Attributes and Decorators 2. Versioning 3. Namespaces and Modules 4. Scripting Environments for Natural Language Generation 5. Output Streams, Logging and Diagnostic Events 6. Developer Experiences 7. Reader Experiences 8. The Automatic Evaluation of Natural Language
Best regards, Adam
From: Denny Vrandečićmailto:dvrandecic@wikimedia.org Sent: Tuesday, July 7, 2020 2:39 PM To: General public mailing list for the discussion of Abstract Wikipedia (aka Wikilambda)mailto:abstract-wikipedia@lists.wikimedia.org Subject: Re: [Abstract-wikipedia] Wikilambda and Abstract Wikipedia
Hi Adam, Hi Amirouche,
thank you for this interesting exchange!
Just one thing - you touch on a lot of different topics, and I love that because it shows how excited you are about the project. Thank you for that excitement and energy! It also makes it hard to make sure that ideas are captured and properly discussed.
For longer texts and essays and design notes, it may be easier to have them on wiki - emails might not be the ideal format for that. I plan to put a few more texts on the wiki in the next few days. This will allow to break the texts down and make sure the discussion is actionable. For the mailing list, I think it will make sense to have more focussed discussions.
In that spirit, I'll just grab a single topic out of the many that are touched upon in this thread: programming languages. One suggestion was to introduce a new programming language. And I have to say, I am not against this, but there are a number of considerations with that. - designing a new programming language is quite a bit of work - implementing a new programming language is a little work - socializing a new programming language is a huge amount of work
The goal for the Wiki of Functions is to provide a catalog of function definitions / interfaces, which in turn can have several implementations, and these implementations can be in different programming languages.
My assumption is that the community that runs the function wiki will have the responsibility to decide which programming languages to allow for implementations, and what needs to be in place to support a programming language (e.g. a syntax checker? a parser? an evaluator?). This will be discussions we will have in the future.
Now when the actual functions are being evaluated, the evaluation engine can only use implementations that it knows how to run. And I expect that different evaluation engines will support different programming languages. This is why we listed JavaScript as the first language - this allows us to have evaluation engines in the browser as well on the server side with comparably less effort. But not all programming languages that the Function wiki supports have to be supported by all evaluation engines.
So, if a new programming language is to be developed and integrated, sure! In fact, as I wrote in the technical paper, I think that the function wiki might be a boon for bootstrapping new programming languages. But unless there is a compelling reason, I would not regard it in scope of the core team to design and implement a new programming language.
I hope that makes sense, Denny
On Fri, Jul 3, 2020 at 4:12 PM Adam Sobieski <adamsobieski@hotmail.commailto:adamsobieski@hotmail.com> wrote: Amirouche,
I see your points about a new programming language potentially causing friction and reducing ease of adoption.
I found this useful document: https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Plan . It appears that JavaScript [1] and Lua [2] are in a group of languages for initial consideration for Wikilambda and that Python [3] as well as Web Assembler, PHP, Rust, C/C++, R, Swift, Go, and others [4] are planned for later, eventual consideration.
We seem to agree that structured comments could be useful for providing features including: extensible metadata for functions, ease the searching for functions in large collections, and make possible the automatic generation of documentation.
I disagree that global objects are evil; after searching the Web for concerns, I do see that they should be used with care. Without global variables, global objects or global scripting environment API, many functions would have the same, arguably redundant, parameters – for example the output natural language. We could broaden that set of parameters which describe NLG output by adding reading level and verbosity. There could, then, be a set of global parameters which describes desired NLG output which would, otherwise, have to be passed to numerous functions as arguments.
I’m brainstorming on how to provide convenience for NLG developers. An envisioned developer experience is having a means of toggling a developer mode or debugging mode when viewing the hypertext NLG output on Abstract Wikipedia to then be able to hover over content to view relevant diagnostic messages in hoverboxes. Another envisioned developer experience is having a means of toggling a developer mode or debugging mode to view visual indicators for diagnostic messages in a margin to the side of rendered natural language hypertext output.
I wonder what you and others in the group envision in terms of developer experiences while working on Wikilambda and inspecting natural language hypertext outputs on Abstract Wikipedia?
I’m also starting to think about the many topics broached in the plan document: https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Plan , e.g. IDE integration features [5].
A topic that I didn’t see mentioned yet in the plan document is automatic natural language measurement or evaluation. Software tools in the categories of automatic essay scoring, grammar checking, readability measurement, or natural language evaluation, e.g. Coh-Metrix [6], could be of use for automatically measuring articles in a number of ways. Perhaps bots could measure articles as they are updated and report their data the developer community.
Best regards, Adam
[1] https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Plan#Task_P1.12:_JavaScri... [2] https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Plan#Task_P1.15:_Lua-base... [3] https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Plan#Task_O6:_Python-base... [4] https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Plan#Task_O7:_Implementat... [5] https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Plan#Task_O25:_Integrate_... [6] http://cohmetrix.com/
From: Amirouche Boubekkimailto:amirouche.boubekki@gmail.com Sent: Friday, July 3, 2020 2:19 PM To: General public mailing list for the discussion of Abstract Wikipedia (aka Wikilambda)mailto:abstract-wikipedia@lists.wikimedia.org Subject: Re: [Abstract-wikipedia] Wikilambda and Abstract Wikipedia
Le ven. 3 juil. 2020 à 18:50, Adam Sobieski <adamsobieski@hotmail.commailto:adamsobieski@hotmail.com> a écrit :
Abstract Wikipedia Mailing List,
Hello. Congratulations on launching the new and exciting Wikilambda and Abstract Wikipedia projects.
I am very excited by wikilambda and abstract wikipedia because it intersects with several of my projects.
Which Programming Languages?
Which programming languages are to be developed with on Wikilambda for use with Abstract Wikipedia?
Might a new programming language be useful?
A new programming language will be a mistake because it will increase friction and reduce the ease of adoption, also it will require to rebuild the wealth of documentation that exists for existing programming languages. It is sure that people do not love to learn new languages. wikilambda should be a trampoline toward regular (?) programming hence if / when possible not re-invent the wheel.
I already did that research for myself and find that scheme hits a sweet spot (even if there is a lot of parentheses). Wikilambda will probably not need call/cc (but might require exceptions) and macros. So, it will make the implementation much much easier. I mentioned the parentheses, well there are sugar syntaxes that allow you to work around it. In particular, Racket is working on a wanna-be mainstream language that will be the best of all worlds... See https://github.com/racket/rhombus-brainstorming/blob/master/resources/goals.....
Might it be useful to transpile a new programming language into an existing one (e.g. resembling TypeScript and JavaScript)?
That will be great, for sure. I think the best target will be Web Assembly.
Models of Function Definitions
On the topics of programming language design, while we most often consider functions as being comprised of signatures and bodies, might it be useful to consider models of functions with more components? We could express such things with multiple, nested “{}” brackets or scopes.
In some models, a function definition might include a guard, preconditions, a body, and effects.
Inspired by PDDL:
function foo(…) { guard { /* … */ } preconditions { /* … */ } body { /* … */ } effects { /* … */ } }
It seems to me it is similar to Racket contracts. I am not very familiar with those. I will prefer that complexity to be opt-in, unlike the previous generation of statically typed programming language (C, C++, Java) and which is to some extent still the case (Rust, in particular, is not very friendly to the newbie even seasoned developer).
My idea about the subject of "specifying" the expected behavior of the program inside the program is to rely on "asserts" which are opt-in and can be disabled. The idea is to infer types from asserts. Remain the question of who to specify exceptions (which is missing from Python's gradual/optional typing facility).
In other models, a function definition might include requires, a body, and ensures.
Inspired by code contracts:
function foo(…) { requires { /* … */ } body { /* … */ } ensures { /* … */ } }
Such models can be phrased as transformations or mappings from existing languages that separate and organize varieties of content that frequently occur in function body definitions.
I prefer to imagine a programing language as a sandbox. And document patterns and designs.
Structured Comments, Metadata and Versioning
Structured content (e.g. XML) in comments is both useful and increasingly popular. Structured comments can provide extensible metadata for functions, ease the searching for functions in large collections, and make possible the automatic generation of documentation.
I am not against the idea of comments. That said, I am not sure what structured means in this contexte. XML to document functions? Seriously? Again, I think I prefer complexity to be opt-in, and help spread good practice through IDE, linter and other toolings.
Structured comments could be processed and utilized by the Wikilambda project to provide features.
Certainly comments will be useful.
Also, some programming languages (e.g. C#, Java) have the expressiveness of metadata attributes which can adorn methods and their parameters. A useful attribute is [Obsolete] which supports the use of messages to make use of a newer version of a function, e.g. [Obsolete(“Consider use of foo_2 instead.”)].
That can be scraped from code... Adding "adornement" would complicate the syntax and increase the surface and required knowledge necessary to play with the language. I imagine that simply having a function that is "log.warning("deprecated", ...)" is good enough.
Namespaces and Modules
Namespaces and modules can be useful when organizing large collections of functions. With namespaces or modules, multiple paradigms or ecosystems of functions could coexist in a crowdsourced resource for use in natural language generation scenarios.
Not necessarily, content-addressable code does not require namespaces.
Global Variables and Runtime Environment API
Global variables, such as the currently desired natural language for output, could be provided by the runtime environment. An API could be specified for the runtime environment.
I was under the impression that global variables were evil!
Output Streams, Logging and Diagnostic Events
When editing / developing Wikilambda content for use on Abstract Wikipedia, it would be convenient to be able to output to multiple streams, to log, or to raise typed events. It would also be useful to be able to aggregate, organize and view these diagnostic outputs with a configurable granularity or verbosity.
Developer Experiences with the Rendering of Natural Language
A possible user experience for Wikilambda editors / developers is having a means of toggling a developer mode or debugging mode on Abstract Wikipedia such that one could view rendered articles and hover over natural language output to view relevant diagnostic messages in hoverboxes.
Another possible user experience for Wikilambda editors / developers is having a means of toggling a developer mode or debugging mode on Abstract Wikipedia such that visual indicators for diagnostic messages would be placed in a margin to the side of rendered natural language output.
Best regards,
Adam Sobieski
_______________________________________________ Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.orgmailto:Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
_______________________________________________ Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.orgmailto:Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
abstract-wikipedia@lists.wikimedia.org