Wondering how the community will be allowed to interop with function
definitions in their languages of choice...even extending functions with
other languages.
I didn't know about NAPI-RS <https://napi.rs/> existed until watching a
podcast today (33:00) <https://youtu.be/Aeij24E-jHI?t=1980> where `#[napi]`
macro was mentioned as an interesting PR
<https://github.com/napi-rs/napi-rs/pull/696> and thus bringing about a
very powerful feature of building pre-compiled Node.js add-ons in Rust.
And now even ThreadSafe functions
<https://napi.rs/docs/concepts/threadsafe-function>.
How this might be utilized in Wikifunctions later on is an interesting
thought experiment... imagine someone wanting to use a Node library that
already affords a great implementation but also needs to be adapted or
expanded for special fit and purpose... and in Wikifunctions by writing a
Node.js addon in Rust language.
Does anyone feel that the idea of extending functions with other languages
(even native) might be too edgy a task on Function Composition? Or will
this eventually be expected to be supported in whole or partially with
the Launch
requirements
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Launch_requirements>
,one of which is:
- "Switching from one language to the other"
Thoughts?
Thad
https://www.linkedin.com/in/thadguidry/https://calendly.com/thadguidry/
The on-wiki version of this newsletter can be found here:
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2022-02-11?venot…
--
Today we want to share three artifacts we have been building on our way to
Wikifunctions.
<https://meta.wikimedia.org/wiki/File:Wikifunctions_-_early_rough_mockup_-_E…>
<https://meta.wikimedia.org/wiki/File:Wikifunctions_-_early_rough_mockup_-_E…>
Early rough mockup of the edit function journey
Aishwarya, our designer, is currently working on the screen for viewing a
function. Viewing and understanding a function will be one of our central
experiences. It should invite the user to learn about the function, to use
the function, and to contribute to it.
Here is a video exploring the design of the page. Note that this is an
early exploration.
She created the following user flow chart. The chart captures what actions
can be done from the view function page.
<https://meta.wikimedia.org/wiki/File:Wikifunctions_flowchart_-_View_functio…>
<https://meta.wikimedia.org/wiki/File:Wikifunctions_flowchart_-_View_functio…>
Wikifunctions flow chart for viewing a function
You can click on it to get a higher resolution image.
We also published a list of launch requirements
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Launch_requirements> for
Wikifunctions. These will help us to not forget important steps as we get
ready for launch and as development progresses. As it is easy to get too
deep into the weeds of daily work, it is good to be able to step back and
see what other tasks still need to be done.
Enjoy exploring the artifacts! As always, feedback is very welcome.
Development update
- Phase η (covers the work of the actual Wikifunctions system) is still
in progress
- A lot of bugs have been fixed during the previous Fix-it week
- In parallel, the team is also focus on building the user interface.
The primary focus of the UX work is on things we expect most users to use.
The on-wiki version of this newsletter can be found here:
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2022-02-04
--
Originally, the proposal for Wikifunctions was made under the name
“Wikilambda”. After the community decided to use Wikifunctions as the name
for the project, we adopted WikiLambda as the name for the MediaWiki
extension that will allow the creation and maintenance of a library of
functions in a MediaWiki system.
But what’s up with the lambda? Lambda is the 11th letter of the Greek
alphabet, and was a predecessor to the letter L in the latin alphabet.
Lambda is written in uppercase as Λ, and in lowercase as λ.
But what does it have to do with Abstract Wikipedia and Wikifunctions?
The early prototypes to implement the idea of Abstract Wikipedia (from
2013-2017) were aiming for a much simpler system: one in which we could
directly create and edit “meanings”, and then have the system take care of
translating those meanings into natural language texts. An early draft
<https://meta.wikimedia.org/wiki/A_proposal_towards_a_multilingual_Wikipedia>
describes the implementation of the system with templates based on language.
But none of these simple systems worked, as they wouldn’t scale to the
needs of generating even simple fluent natural language texts in many
different languages. The resulting templates or modules would have quickly
become too complex, and so their editing and maintenance would have been
restricted to a far too small community to be viable in the languages that
need it the most. As the system implementing the natural language grew in
expected complexity, it became clear that a different approach would be
required: instead of building a system that tries to hide the complexity of
natural language generation from the community working on it, and having
the community get stuck in the limitations of that system, let’s design a
platform that would allow us to work together on these complex tasks, and
allow the community to create layers of hidden complexity and abstraction
instead.
Instead of having a development team deciding what set of functions would
be required for the community's tasks, we create a platform where the
community can create and maintain those functions themselves.
This very quickly turned into a generic platform for creating all kinds of
functions. The next question became: how do we implement those functions?
In order to allow for a multilingual approach to function implementation,
we adopted the idea of composing (combining) existing functions.
Composing functions is an old idea. In fact, it is one of the most
foundational ideas in all of computer science: giving names to and using
functions, i.e. function abstraction and application. That is exactly what
the lambda calculus <https://en.wikipedia.org/wiki/Lambda_calculus> does.
Lambda calculus was developed by Alonzo Church
<https://en.wikipedia.org/wiki/Alonzo_Church> in the 1930s.
The 1930s were a turbulent time in many ways, and also in Mathematics: the
decade saw the dream of Mathematics and Logic being shattered, and its
foundation completely rebuilt. The comic Logicomix
<https://en.wikipedia.org/wiki/Logicomix> retells the dramatic story of
those events.
There were two main results: first, that not every mathematical question
can be answered
<https://en.wikipedia.org/wiki/G%C3%B6del%27s_incompleteness_theorems>; and
second, that every mathematical question that can be answered at all can be
answered by using a combination of a surprisingly simple and small
foundation. And not only that: there are many such foundational systems!
Lambda calculus is one, but so are Turing machines
<https://en.wikipedia.org/wiki/Turing_machine>, cellular automata
<https://en.wikipedia.org/wiki/Cellular_automaton> (such as Conway’s Game
of Life <https://en.wikipedia.org/wiki/Conway%27s_Game_of_Life>), unrestricted
grammars <https://en.wikipedia.org/wiki/Unrestricted_grammar>, even simple
marble and lever games such as Turing Tumble <https://www.turingtumble.com/>
without any electric components are each capable of performing any possible
calculation there could ever be.
So lambda calculus was a main inspiration for how composition works in
Wikfunctions. But that’s not all!
In the 1960s, Richard Montague
<https://en.wikipedia.org/wiki/Richard_Montague> pioneered the linguistic
theory that was later called Montague grammar
<https://en.wikipedia.org/wiki/Montague_grammar>, an approach to formally
represent the meaning of natural language expressions. Montague took
inspiration in the lambda calculus, and since then the lambda calculus also
became a mainstay in linguistics. In this approach, the meaning of words
such as “some” or “every” are captured with simple expressions in lambda
calculus. You can read more about the use of lambda calculus in linguistics
in this introduction aiming at “absolute dummies”
<http://palmstroem.blogspot.com/2012/05/lambda-calculus-for-absolute-dummies…>.
Or in this comic <https://imgur.com/a/XBHub> aimed at linguists.
Let me quote the words
<https://allthingslinguistic.com/post/95678520747/the-lambda-calculus-for-ab…>
of linguist Gretchen McCulloch
<https://en.wikipedia.org/wiki/Gretchen_McCulloch> about the use of lambda
calculus in linguistics:
“The Lambda Calculus is often used in semantics as a way of representing
meaning in a manner more independent of the specific words used in a
particular language.”
That is exactly what we are aiming for with Abstract Wikipedia!
The abstract content that will make up Abstract Wikipedia is basically
“just” a user-friendly and community-editable layer over lambda notation,
used to express the meaning of the Wikipedia articles. In a second step, we
then use lambda-calculus based compositions to transform these expressions
of meaning into natural language text that is then presented to the readers
of Wikipedia.
Which brings us to another connotation that lambda has: Λ or λ both look a
whole lot like the Chinese character 人, which can mean “human” or “person”
or “everybody” <https://en.wiktionary.org/wiki/%E4%BA%BA#Definitions>. And
that really represents for whom we are doing this work.
The lambda in WikiLambda is a conscious reference to both these bodies of
research. The new thing in WikiLambda is not the "Lambda" — it is the
"Wiki". It is this idea of bringing together a group of remarkable people
to see if they could build something new, something that can take us a step
closer to a world where everyone can share in the sum of all knowledge.
The on-wiki version of this newsletter can be found here:
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2022-01-28
--
Since the start of the project, we have published the function model for
Wikifunctions
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Function_model>, but
the description is rather technical and uninviting. In these newsletters,
we have previously described parts of the function model in a more
accessible way: what is an object
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2020-11-10>, what
are functions good for
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2020-10-07>, labels
and documentation
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2020-10-22>,
what are generic types
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2021-01-21>,
and why we allow for multiple implementations per function
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2021-06-17>.
Today, let’s dive into a core concern: how do we represent a function?
*What is a function?* The term “function” is used in various different
disciplines, and the English Wikipedia offers articles on functions in computer
science <https://en.wikipedia.org/wiki/Subroutine>, mathematics
<https://en.wikipedia.org/wiki/Function_(mathematics)>, linguistics
<https://en.wikipedia.org/wiki/Functional_linguistics>, biology
<https://en.wikipedia.org/wiki/Function_(biology)>, engineering
<https://en.wikipedia.org/wiki/Function_(engineering)>, and sociology
<https://en.wikipedia.org/wiki/Structural_functionalism>. All of these
notions are related and interesting, and for Wikifunctions we use the
following, specific definition: a function takes some input and responds
with an output. The input affects the output in a predictable way.
*What are functions good for?* We previously discussed the general
motivation for functions
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2020-10-07>:
functions answer questions, and answering questions is a crucial part of
allowing everyone access to the sum of all knowledge. Functions will be the
central type of objects in Wikifunctions . Users of Wikifunctions will be
able to “call” or use functions to answer their questions. Contributors to
Wikifunctions will be able to define new functions and create the related
supporting objects.
*How do we represent a function?* Here’s the overview of how a function is
represented in Wikifunctions and the related objects supporting it (we’ll
go into these in detail below): a function has labels, aliases,
documentation, a return type and a list of arguments, a list of testers, a
list of implementations, and an identity. (We will not discuss identity
today, as this is rather technical)
*Labels*. We define a function by giving it a label, a name. The label
depends on the language: a function that adds up two numbers may be called
“Addition” in English, “Zbrajanje” in Croatian, “Сложе́ние” in Russian,
“যোগ” in Bangla, etc. It might also have aliases that will help people to
find the right function: “Add”, “Sum”, or “Plus” might be good aliases in
English, “прибавле́ние” might be an alias in Russian, and “+” might be an
alias that works in many languages.
*Documentation*. A function will also often have documentation – some text
that describes what the function does and how it does it. This should help
people with differentiating the function from similar functions, and for
allowing users to understand what the function call will result in and how
that answers their questions. We have previously discussed labels, aliases,
and documentations
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2020-10-22>.
*Return type*. The return type tells us what type of object the answer of
the function will be. For example: “number”, “boolean” for true/false,
“string” for words, etc. This can be helpful in many ways: it can help when
browsing the available functions, as we sometimes know that our answer will
be a number; it can help when combining functions together, because we know
that an argument can only take a specific type, and that we can compose it
with a function that returns the required type. The return type can also
help us with understanding the function and what exactly it returns. For
the two “divide” functions mentioned above, one will return a number, and
the other a list of strings. Even if we don’t have any documentation for
the function in our language, this will give us strong hints about what it
might do.
*List of arguments*. A function takes some input. The input is given as one
or more arguments. Each argument can have a label/name (again, given in
each of the languages we support), and the type of object we expect this
argument to be. The type is important: say you have a function called
“divide”, which takes a string and a number, and divides the given string
into equally sized parts. So you call “divide “Wikipedia” into 3 parts” and
the function answers with “Wik”, “ipe”, and “dia”. Separately, there is
another function, also called “divide”, that takes two numbers, to
determine how many times the first goes into the second. These are two very
different functions, and the result of “divide(333, 3)” could either be 111
or 3, 3, and 3 — depending on which function you picked, and what types the
values had.
The numerical division function also illustrates the need for names for the
arguments: in that case, it is important which argument is the number by
which we divide and which is the number that is being divided. In other
cases, the name of the arguments are less important: for the “divide a
string into equal parts” function, the types are sufficient to know which
argument does what.
*List of testers*. Testers will play a crucial role in Wikifunctions, and
not only by fulfilling the standard role of tests. Traditionally, a test
aims to give the user some confidence that a function indeed returns with
the correct answer. When a function passes its tests, it is likely that the
function will return the right answer also for other arguments. A
well-designed set of tests can explore the “edge cases” of what is expected
when you call a function with a surprising input.
But in Wikifunctions, the testers will do so much more! When a contributor
creates the function that divides a string into equally long parts, they
could immediately give examples of what they intended: they can create a
tester that, given that we want to turn “Wikipedia” in three equal parts,
we want to get a result that is a list of three strings, “Wik”, “ipe”, and
“dia”. No matter what language they speak, every other contributor can see
the expected results in a well-defined way, and can help with creating
implementations that pass the testers.
The testers act as a means to hammer out agreement between the contributors
to Wikifunctions about what a function does exactly, no matter the language
they speak. The testers are where edge cases (and how they should be
resolved) can be suggested, and agreed or rejected. The testers ultimately
constrain what the “correct” implementations of the function are, and thus
precisely what the function is intended to do.
This also means that the testers are a form of language-independent
documentation, as they provide examples of how the function is called and
what results are expected. So even if there is no documentation available
in your language, the testers might still allow you to guess what a
function does, and use it productively.
*List of implementations*. An implementation makes it possible to actually
run the function on the given arguments, and to produce a result to answer
the function call with. In Wikifunctions, implementations can be given in
three different ways: either as a built-in, as code in a specific
programming language, or as a composition of other functions. We have
talked about these before, and we have discussed why we are going the unusual
way of allowing for multiple implementations
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2021-06-17> for
a function.
We hope that helps with understanding functions, testers, and
implementations better.
