The on-wiki version can be found here:
https://meta.wikimedia.org/wiki/Special:MyLanguage/Abstract_Wikipedia/Updat…
* * *
Today we will talk a little bit about how the catalog of functions will
actually work. A more formal and comprehensive description of this is
the function
model
<https://meta.wikimedia.org/wiki/Special:MyLanguage/Abstract_Wikipedia/Wiki_…>,
but here we want to create a more intuitive explanation.
Every page in the new wiki will contain one *Object*. Every Object is of
exactly one *Type*. Types decide what the Object means. Types also decide
what makes an Object valid or not. An Object that is of a certain Type is
called an *instance* of that Type. Every Object that is stored as a wiki
page is called a *Persistent Object*, and such an Object has a Z-ID by
which it can be referenced. The Z-ID is the name of the page.
What does it mean that the Type decides what the Object means? Let’s look
at an example. An Object of Type *Positive Integer* with the value
"2020" represents
the number 2020. That’s the number you get when you multiply 4, 5 and 101.
And because it has the Type of Positive Integer, we know it is a number. If
the Type of "2020" was String, then that wouldn’t represent the number
2020, but rather a sequence of four characters, "2", "0", "2", and 0. If
the Type of it was *Gregorian Calendar Year* then this would represent the
year 2020 in that calendar, a leap year starting with a Wednesday and
ending with a Thursday.
The Type decides what you can do with an Object -- or, more formally
speaking, which Functions you can apply to the given Object. If you have a
String, you can count the length of the String, *i.e.* how many characters
are in the sequence. The result for "2020" above would be four. If you have
a Gregorian Calendar Year, you might also be able to ask for the 'length',
but the result should probably be 366 days (as it is a leap year). If you
have a Positive Integer and ask for its length, you might be asking for the
logarithm in base 10, or you might be asking for the multiplicative
persistence <https://en.wikipedia.org/wiki/Persistence_of_a_number>. But
all of these would be different Functions (that may well have the same
label, “length”, in English; their descriptions would explain in more
detail what they would do). The Function states which Types it can take,
and the Type decides what an Object means.
Types can be very diverse. Some Types might have a small, explicitly
defined number of instances. These are called *Enumerations*, because all
the instances of the Type are known in advance and enumerated, and each
instance must be one of these few possible values. The classic example of
such a Type is *Boolean*, named after George Boole
<https://en.wikipedia.org/wiki/George_Boole>, which has exactly two
instances: *True* and *False*. Another Enumeration would be the *Days of
the Week*. Other Types can be simple but have an infinite number of
possible instances. Examples of such Types are *String* for sequences of
characters, and *Positive Integer* for the counting numbers. Other Types
can be composed of simpler Types. For example, one way to represent an
*Integer* would be to compose it from a Positive Integer and a Boolean,
where the Boolean decides whether the Integer is positive or negative, and
the Positive Integer represents the absolute value.
Not every Object has to be stored as a wiki page. For example, there is no
need to store the number 2020 as an Object in the wiki, as it can be easily
just created on the fly.
This is how Objects are built and represented. Objects of almost all Types
are called *Literals*. A Literal is an Object that, when evaluated, results
in itself. For example, when you evaluate the number 2020, the result is
the number 2020. But there are two very special Types whose instances are
not Literals, and these two types are *References* and *Function Calls*.
References are a special Type of Object that refers to a Persistent Object
by its Z-ID. It basically just says “here, this Reference, should really be
just this Object that is referenced to by this Z-ID”. Evaluating a
Reference results in the referenced Object. A Reference does not need to be
evaluated immediately, but can be evaluated whenever needed. In fact, it is
sometimes impossible to evaluate all References fully, as it can easily
lead to a recursion and infinite objects.
The other special Type of Object is the Function Call. A Function Call
consists of a *Function* and a *List of Arguments*. Evaluating a Function
Call is the core 'magic' of the whole system: it is basically replacing a
Function Call with the result of that Function Call, *e.g.* evaluation
would be replacing the Function Call to the Function with the label
"length" and the argument "2020" of Type String with the value "4" of Type
Positive Integer.
Function Calls are usually created on the fly. We wouldn’t, in general,
create a new wiki page with a Persistent Object in which we store the
Function Call described above, but rather we would send that Function Call
to an evaluation engine which, in turn, evaluates the Function Call and
returns the result. There is really not much more to the system than that.
A Function Call is in many ways analogous to using a MediaWiki template
<https://www.mediawiki.org/wiki/Help:Templates> with parameters.
I hope that this explanation made some sense and helped with understanding
the planned system. We are currently developing the part of the system that
allows contributors to create Types inside the wiki itself, so that the
community can create and control which Types exist. Please feel free to ask
questions.
------------------------------
The voting for the final round of the naming contest
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Wiki_of_functions_naming…>
is
ongoing. Voting will be open until Monday, November 16. If you haven’t
already, please vote here and decide on a name for the new project where
all of these Objects we described above will be available. The proposals we
are voting on are, in reverse alphabetical order: *Wikimedia Functions*,
*Wikilambda*, *Wikifusion*, *Wikifunctions*, *Wikicodex*, and *Wikicode*.
Let us know your preferences and decide on the name of the new project by
Monday!
The wikiversion of this newsletter can be found here:
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2020-11-25
----
Every Object in Wikifunctions will be identified by its Z-ID, similar to
the Q-IDs and L-IDs of Wikidata for Items and Lexemes, respectively.
Whereas most of the Z-IDs will be simply assigned consecutively, we plan to
have a few intentionally chosen Z-IDs, just as with Q-IDs and L-IDs. Unlike
with Q-IDs and L-IDs the goal of these is less for them to be "Easter
eggs", but rather to be mnemonic and to help with remembering them.
No, no, don’t worry - you shouldn’t be remembering all the Z-IDs that you
need to use. The interface should hide most of the Z-IDs. But sometimes,
either in early versions of the system, when the interface isn’t
sufficiently complete yet, or later in some debugging tasks or when
inspecting or creating some messages on the wire, it might be helpful to
have core Z-IDs be ever so slightly easier to recall than entirely
arbitrary assignments.
I invite you all to join us in finding good Z-IDs for the core Objects of
Wikifunctions. We will be coalescing on the solution on this page: Reserved
ZIDs <https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Reserved_ZIDs>.
The page discusses and lists:
- Should there be a contiguous block of Z-IDs reserved, e.g. all Z-IDs
with four digits or fewer (or maybe three or fewer? Just two or one?)
- Which Z-IDs should be reserved?
- What should these Z-IDs be standing for?
- What are the Objects that should get pre-assigned Z-IDs?
Here are a few thoughts that went with the current status of assigned Z-IDs
in the Function Model (but you will see that the page above does not always
agree with these thoughts).
We tried to minimize the number of reserved Z-IDs, and just reserve the
Z-IDs Z1-Z99. That’s tight. By extending to Z999 or Z9999 we would have
more space.
The Z-IDs Z1-Z25 were mostly for the basic types of the Function Model.
These include Object, Type, Function, Implementation, Error, String, List,
etc. After that we thought about assigning a block of Z-IDs for the fifteen
or so initial Functions, and, twenty above them, their respective initial
Builtin Implementations, e.g. having “if” be Z31 and the builtin
implementation of “if” be Z51. Besides that, we need a number of reserved
Z-IDs for certain error codes, for languages, and for the Boolean values
True and False.
Here are a few thoughts on how some of the basic Types were assigned Z-IDs
- mostly based on the length of the English label:
- Z1 : *Object* (Type) : because everything starts here.
- Z2 : *Persistent object* (Type) : everything on the wiki is a Z2,
that's why this has such a low ZID.
- Z3 : *Key* (Type) : because the word key has three letters in English.
- Z4 : *Type* (Type) : because the word type has four letters in English.
- Z5 : *Error* (Type) : because the word error has five letters in
English.
- Z6: *String* (Type) : because the word string has six letters in
English.
- Z7: *Function call* (Type) : because function calls are the main
'magic' of the system, and 7 is a magic number. It is also close to Z8.
- Z8: *Function* (generic type, thus technically a function) : because
function has eight letters in English.
- Z9 : *Reference* (Type) : because the word reference has nine letters
in English.
- Z10 : *List* (generic type, thus technically a function) : because
it's the first number that has two digits.
- Z11 : *Monolingual text* (Type) : because it is just one language, and
there's a one in the name.
- Z12 : *Multilingual text* (Type) : because it's an extension of Z11.
- Z14 : *Implementation* (Type) : because the word implementation has
fourteen letters in English.
- Z20 : *Tester* (Type) : because 20/20 is perfect vision, and tests
make errors visible.
- Z99 : *Quote* (Type)
Another basic Type that still needs an assignment is Boolean, and possibly
others.
A list of the currently suggested initial fifteen Functions:
- *if*: Boolean, T, T ➝ T
- *value by key*: Key reference, T ➝ U
- *reify*: Any ➝ List(Pair(Key reference, Any))
- *abstract*: List(Pair(Key reference, Any)) ➝ Any
- *head*: List(T) ➝ T
- *tail*: List(T) ➝ T
- *empty*: List(T) ➝ Boolean
- *cons*: T, List(T) ➝ List(T)
- *unquote*: Quote ➝ Any
Additionally to that we also need a validator function for most of the
basic Types. There is a task about the basic Functions and Types on
Phabricator: T261474 <https://phabricator.wikimedia.org/T261474>
These are all just suggestions, and we are happy to see them discussed on
wiki <https://meta.wikimedia.org/wiki/Talk:Abstract_Wikipedia/Reserved_ZIDs>.
Please make further suggestions for reserved Z-IDs there, either for
mnemonic purposes or also for genuine easter eggs. I am sure that you will
come up with much better and more interesting suggestions than we are. So,
let us know your ideas and see you next week with some news.
The on-wiki version of this post is here:
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2020-11-17
--
The vote for the name of the new Wikimedia project that will contain a
contributor-curated catalog of functions is over! Thanks to all the
participants.
There have been votes from 320 accounts, a considerable increase over the
193 voters in our first round. Using the vote tallying process described in
the rules, the top candidate resulting from the vote is *Wikifunctions*.
Here is how the vote shook out. After removing the ineligible votes, these
were the top preferences of the voters:
1. Wikifunctions 84
2. Wikilambda 82
3. Wikimedia Functions 70
4. Wikicode 45
5. Wikicodex 16
6. Wikifusion 16
We eliminate the two options with the fewest votes, *Wikifusion* and
*Wikicodex*, and count the top preferences after that elimination:
1. Wikifunctions 92
2. Wikilambda 89
3. Wikimedia Functions 79
4. Wikicode 53
That round eliminated *Wikicode*, resulting in this third round:
1. Wikifunctions 126
2. Wikilambda 97
3. Wikimedia Functions 90
Which lead to the elimination of *Wikimedia Functions*:
1. Wikifunctions 190
2. Wikilambda 123
Which finally led to *Wikifunctions* winning. The fact that we had to
eliminate all options but two shows how tight the vote was.
In order to honor the name *Wikilambda*, which as you can see also caught
quite some attention, and which had a few fiery supporters, we have decided
to name the software extension to MediaWiki that we are developing
*WikiLambda* (note the CamelCase, which is normally present in our software
tools in honour of our roots in UseMod
<https://en.wikipedia.org/wiki/UseModWiki>).
The next step is now to have the Legal department do the in-depth vetting
of the name. We aim to have that finalized by mid-December.
Interestingly, should *Wikifunctions* not be accepted, per the rules of the
contest, the runner-up would not be *Wikilambda* but *Wikimedia Functions*.
If *Wikifunctions* is to be eliminated due to legal considerations, this is
how the first round would looked like:
1. Wikimedia Functions 113
2. Wikilambda 94
3. Wikicode 63
4. Wikicodex 22
5. Wikifusion 21
With *Wikicodex* eliminated, the next round looks as this:
1. Wikimedia Functions 117
2. Wikilambda 99
3. Wikicode 75
4. Wikicodex 22
Which eliminates *Wikifusion* and leads to the following results:
1. Wikimedia Functions 125
2. Wikilambda 108
3. Wikicode 80
Finally, eliminating *Wikicode*, we see quite a strong lead:
1. Wikimedia Functions 176
2. Wikilambda 137
The winning proposal of that would be *Wikimedia Functions*, again with
*Wikilambda* being the apparent follow-up. We know already that *Wikimedia
Functions* would pass the vetting process (due to the strong trademark that
*Wikimedia* itself is), so we would be able to stop the process there. So
the comments about *Wikilambda* above would stay.
Thanks again for everyone participating in the vote! We are looking forward
to finalizing the result, and come back to you within a few weeks. Once
that is closed, we will be setting up the timeline and the process for the
logo contest. We already have community members being eager to start. Feel
free to start creating proposals and discussing them! That page is
preliminary. Over the next few weeks we plan to suggest rules for the logo
contest, and also to publish some suggestions regarding the potential logo.
We are also very excited about these parts coming together!
Thank you all!
The on-wiki version of this newsletter is here:
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2020-11-05
----
The second round of voting has started for naming the new Wikimedia
project, the wiki of functions!
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Wiki_of_functions_naming…>
How
often do you have the opportunity to name a Wikimedia project? This will be
the first new Wikimedia project to launch since 2012.
Today I will talk about the details of the second round of the naming
contest. Feel free to skip this update if you are not interested in this.
The first round saw more than 170 proposals submitted for what to call the
central wiki of functions. After more than 500 votes, we have a list of the
six top proposals. We have published considerations from legal and
communications
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Wiki_of_functions_naming…>
on
the proposals.
The six top proposals, in alphabetical order, are:
- Wikicode
- Wikicodex
- Wikifunctions
- Wikifusion
- Wikilambda
- Wikimedia Functions
<https://meta.wikimedia.org/wiki/File:Mediawiki_logo_proposal_(gradient_tran…>
<https://meta.wikimedia.org/wiki/File:Mediawiki_logo_proposal_(gradient_tran…>
Winner of the MediaWiki logo contest
We have used and adapted a gadget written by Amir Sarabdani
<https://meta.wikimedia.org/wiki/User:Ladsgroup> in his volunteer capacity,
and diligently adapted by James and Nick for our usage. The gadget was
written and has been used previously for voting on the new logo for the
MediaWiki software
<https://www.mediawiki.org/wiki/Project:Proposal_for_changing_logo_of_MediaW…>.
That vote, by the way, just a few days ago, and the winner of the vote was
just announced. The preliminary winner - pending the final Legal check-up -
can be seen to the right. Congratulations to Amir for running this process,
and congratulations to the MediaWiki community on a fresh and beautiful
proposed new logo!
Unfortunately, gadgets do not work on the mobile website. If you're using a
mobile device, you can go directly to the vote recording page
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Wiki_of_functions_naming…>
and
enter your preference manually.
For the second round, you are asked to rank the six proposals by
preference. We will then use a modified instant-runoff voting system to
decide on the winner of the vote. The vote tallying will work as follows:
First, we count how many valid votes have been made. This provides the
denominator. Then we count, for each proposal, how often it has been listed
as the first preference. This provides the numerator. If any proposal
reaches more than half at this point, it immediately becomes the winning
proposal. If, which is more likely, none of the proposals manage to exceed
half at this point, we count which proposal is listed least frequently as
the first preference. This proposal gets eliminated (in case of a tie, all
of the least popular proposals get eliminated together). Then all votes
which had an eliminated proposal as their top preference are re-assigned to
the next-ranked preference, and we count the votes again.
We repeat this process until one proposal becomes the top preferred choice
by at least half of all voters. This proposal becomes the winner of the
second round of voting.
The winner of this second voting round will then undergo a more thorough
(and expensive) vetting process. Assuming the vetting process finds no
issues with the candidate, the candidate will become the official name of
the new project.
In the case that there are findings that disqualify the proposal, we will
remove that proposal from all rankings, and repeat the tallying of the
votes with the now modified rankings. This will produce a new top proposal,
which in turn gets validated. This proceeds until a top candidate is deemed
acceptable by the legal vetting process.
Votes have opened on Monday, and will be open for two weeks, *until 16
November*. We have kept the same rules regarding voting eligibility as
applied to the first round:
- You must have a registered account which is not blocked on more than
one project
- You must not be a bot
- You must have made at least 25 edits as of September 1 on any public
Wikimedia production wiki
Additionally, current and former members of the Board of Trustees and of
the Advisory Board of the Wikimedia Foundation are also qualified to vote.
We hope that this process will be finished by 8 December, when we plan to
announce the name of the project - and then kick-off the contest to find a
logo to go with the new name.
So, if you are eligible, please go ahead and cast your vote! Let us know
your preferences and help to name a brand new Wikimedia project. Spread the
word in your communities!
*Go vote
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Wiki_of_functions_naming…>!*
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Wiki_of_functions_naming…
A version of this newsletter with links and formatting is available on-wiki
here: https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2020-10-22
In this edition of the weekly posts, I want to discuss the different places
where we will use unstructured text in the objects of the wiki of
functions. The following is a plan and a request for comments. Besides the
labels, nothing is implemented yet, so we would really appreciate your
feedback.
Labels. Every object in the wiki of functions will be identified by a Z-ID,
similar to Q-IDs identifying items in Wikidata. But just like Q-IDs, we
don't expect Z-IDs to be widely visible and used. Instead, every object
will have labels, one per language.
But unlike Wikidata items, every object will be an instance of a specific
type. For example, there might be an object representing the addition of
two integer numbers. So the English label for this object could be “add”.
Other good labels for this object could be “addition”, “sum”, or “plus”. An
inappropriate name for the function would be “multiplication”, as that
would be terribly confusing.
Uniqueness. There would likely also be other objects representing functions
that do addition, for example the addition of two floating point numbers,
or of two complex numbers, or of two matrices. In the wiki of functions
labels will not need to be unique overall - but they will need to be unique
for each type. So there can only be one function with the label “add” that
takes two integers and returns one integer. Or only one type with the label
“integer”. Per type, each label must be unique.
Now does every object need a label? No. There will be many objects where a
label won’t be strictly necessary. Not every test for a function will need
a label, nor will every implementation of a function. They may have labels,
but they won’t be necessary - this is another difference to Wikidata, where
items without labels are almost always problematic.
One more note on labels - labels do not have to be direct translations
across languages. So in one language, two functions might have the same
label if they have a different type, but in another language the two
functions might have different labels as well. For example, in English
“length” might be an appropriate label for both a function that returns the
number of elements in a list, but also for a function that returns the
length of a river, or a function that returns the duration of a movie. In
Croatian, on the other hand, all three of these might have different names
(“broj elemenata”, “duljina”, “trajanje”). Each language can decide what
pattern works best for them. Whether verbs in the imperative mood (“add”)
or a description of the result (“sum”) or the name of the operation
(“addition”) work best can be decided from language to language, and
independent style guides for each language may evolve.
Aliases. Besides labels, every object can have additional aliases per
language. Aliases are helpful when searching for an object. The above
function, labeled “add” in English, could have all the other alternative
names given above - “sum”, “plus”, “addition” - as aliases, so that when
someone searches for one function by a different name they still find the
right one as a result.
Documentation. Every object may also have documentation in each language.
Documentation is some wikitext that further describes the given object.
Many objects will not have any documentation at all, but many will have
some. If you ever had the opportunity to read The Art of Computer
Programming, you will know that there is often a lot to say about a
function! But besides this kind of background story, we can also have some
documentation describing a given implementation, or some explanation for
why a given test is useful. It could also link to a Phabricator task
describing an error that used to be there and that this test is checking
for it in order to catch it before it resurfaces, or a link to other
resources such as a textbook on algorithms.
Keys and arguments. At least types and functions will also have labels for
each key of the type and for each argument of the function. These will be
used in creating the user interface to display and edit values and function
calls.
Short descriptions. One specific question we have is - should we have
optional short descriptions for each object? In many IDEs, and sometimes
even directly in the programming language (think docstrings in Python)
there is support for short one-liners that give a bit of extra information
for a function, beyond just the name of the function and the arguments and
the types.
We are going to have a strong type system, and we will have plenty of space
for the documentation. So do we really also need a place for short
descriptions? What would their use case be? How would they be used in the
UX? On the Website, something akin to the pop-up previews in Wikipedia seem
to be even more useful than a one-liner, previewing the whole documentation.
Originally I assumed per default that we would have short descriptions,
given their importance and usefulness in Wikidata, and so they also feature
in the AbstractText prototype. But they were never useful there. Also, the
type took over the role of the disambiguator, as described above, so there
was really no technical need for a short description. I currently lean
towards not having them, but I would like to hear more input.
The good thing is that no decision will be carved in stone. The data model
of the wiki of functions will be much more flexible than the data model of
Wikidata, and if we figure out that we do need short descriptions, we can
just introduce them later. It is much harder to remove things though,
because almost everything that is there gets used some way or the other, so
I am more wary of introducing features without a good reason.
Dogfooding. One obvious question is: hey, we are developing this
architecture to create multilingual content, why even have all this
documentation and labels and all that in actual languages, why not use our
own functions to build all of this up?
And yes, agreed, that would be best. It’s just, we’re not there yet, and
until then, we will still need labels and documentation and aliases. So
eventually I would very much look forward to using abstract content to
describe the objects of the wiki of functions themselves. It will also be
interesting to see if we can then roll back some of the local content, and
how open we will be to do so - as this will give us a lot of interesting
insight into how to approach similar goals in the other Wikimedia projects,
from descriptions (and maybe even labels? or sense glosses?) to stubby
Wikipedia articles, there will be plenty of potential to make our content
across projects be easier to maintain and to provide a more uniform
baseline coverage across languages.
New video introducing Abstract Wikipedia. A new presentation, given for
Wikidata’s Eighth Birthday, organized by the community of
WikiProject:India, is available: https://www.youtube.com/watch?v=GAb1HylGemA
Naming contest. Next week, Tuesday 27 October, the second round of voting
for the name of the new wiki of functions will begin. The proposals are
currently being vetted by legal, and we should know which names will be in
the final round soon.
.svg){kind=link}