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.com<mailto: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:_JavaScr…
[2]
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Plan#Task_P1.15:_Lua-bas…
[3]
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Plan#Task_O6:_Python-bas…
[4]
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Plan#Task_O7:_Implementa…
[5]
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Plan#Task_O25:_Integrate…
[6]
http://cohmetrix.com/
From: Amirouche Boubekki<mailto: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<mailto: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<mailto:Abstract-Wikipedia@lists.wikimedia.org>
https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
_______________________________________________
Abstract-Wikipedia mailing list
Abstract-Wikipedia@lists.wikimedia.org<mailto:Abstract-Wikipedia@lists.wikimedia.org>
https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia