The on-wiki version of this newsletter can be found here:
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2022-04-28
--
Once Wikifunctions launches, we currently plan to support implementations
of functions in two programming languages, Python and JavaScript. But
unfortunately, that doesn't mean that all the code out there, written in
Python or JavaScript, will become readily available to be copied and used
in Wikifunctions. The code has to fulfill certain requirements. In today's
newsletter we will discuss these requirements, and what you can do to
prepare code you want to make available through Wikifunctions.
First, it must be legal to bring the code in. As per the result of the
community discussion
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2021-12-21>,
the code will be published under the Apache-2 license. If you wrote the
code yourself, or otherwise own the rights to it, you are free to publish
it in Wikifunctions. If you are taking the code from an existing open
source project, you must make sure that it has a compatible license.
Second, the code must be “functional”. That means that, given a specific
input, the code must always return the same output. In particular, that
makes a number of classes of functions not available:
- The result must be determined by the input and have no random
component. This means we cannot have a function that simulates throwing
dice, that returns a newly minted GUID, or similar random results. A random
element would break our caching strategy, in particular the ability to
memoize any function call and replace it with its result if available.
- The result of the function cannot depend implicitly on the time of
day, or the current date, or the location of the user. This means we cannot
have a function that returns the current day of the week. If we want to
rely on such context, we have to make it explicit as an argument to the
function. A function such as “how high is the sun here right now?” would
need to be rephrased “how high is the sun at the given location and time?”
and take the location and time as arguments.
- A function call cannot have intentional side effects. There must be no
function calls that are expected to cause a specific change in the world,
e.g. a function call which instructs a robot to start a certain routine, or
that switches on a light. Yes, a function call will always have some effect
on the world (it may cause caches to change, it will use computing
resources, and it will turn some electricity into heat), but those are
incidental and may change in the future. Someone may write a system that
uses the results of Wikifunctions to control their robots or devices, but
the actual control would be implemented in that system, not in
Wikifunctions.
- A function cannot have a hidden state that is changeable by a function
call. This is a consequence of the previous point. This means, for example,
that we cannot have a function that keeps a count of how often it has been
called and returns that count.
- This also means there cannot be a function call that edits a Wikipedia
article or edits a Wikidata item. Editing a function, or a function
implementation, may eventually change the content of an article on
Wikipedia (that is, once we allow for Wikifunctions functions to be called
from articles in Wikipedia), but calling a function on Wikifunctions will
not cause an article content to change.
- A function may not call out to the Web or the wider Internet. No HTTP
requests or similar mechanisms will be allowed at launch. Any resources or
data a function wants to use must be provided as arguments.
- Initially, functions will not be able to access data from Wikimedia
projects. We plan to extend Wikifunctions in an early post-launch milestone
to allow access to items and lexemes in Wikidata, and later to meta-data
about media files on Commons.
- Functions cannot store or load files to a persistent file system, or
read from or write to a persistent database. They may not access any other
network or device.
Some of these use-cases may be tackled after launch (e.g. in order to allow
random results, or to use implicit arguments for functions such as “what is
the current time?”), but these will require careful planning, discussion,
and ultimately changes to the system.
These are further restrictions that Wikifunctions will initially have:
- Both Python and JavaScript have an extensive ecosystem of third party
libraries available. Initially it will only be possible to access the
Python standard library and the JavaScript standard built-in objects,
respectively. We plan to allow later for a process to add further libraries
and make them accessible from an implementation.
- It will initially not be possible to call another Wikifunctions
function from a code implementation (only from compositions). We plan to
allow that, although this might initially be restricted to cases where the
called function also has an implementation in the same programming language.
- Initially, only certain types will have built-in
serialization/deserialization logic (i.e., code that maps between the
ZObject representation and in-memory objects for each programming
language). These types are Boolean, string, List, Map (becomes a dict in
Python or a Map in JS), and Nothing (None in Python, null in JS). For every
other type, native code will work directly with the respective native JSON
object at first. We are working on a design to allow the community to add
serialization and deserialization for more types.
- This also means that there is no real support for 'objects' in the
sense of object-oriented languages. The interface with Wikifunctions will
be a function call, not a call to the method of an object that can rely on
internal state. There is also no information hiding in objects. Every value
in Wikifunctions must be entirely serializable and deserializable. Values
are immutable, which also is at odds with how objects are commonly designed
and used in practice in many object-oriented contexts.
- Initially, we won’t have a built-in mechanism to support dispatch or a
type hierarchy.
We are already planning to add more programming languages, but they will
also have similar restrictions. Both JavaScript and Python, as well as many
other languages, allow top-level functions to be defined. For other
languages, such as Java or Smalltalk, we would need to define a slightly
different pattern in order to interact with the functional interface that
Wikifunctions provides. Whenever we add a language, the process will
involve a design step in which we will discuss the appropriate mappings. We
also plan to document how further programming languages can be added so
that the effort becomes predictable.
This post has no examples and no how-to, but rather describes the
requirements for implementations. In the following weeks, we will follow up
with one or more posts that examine a few patterns and examples on how code
from libraries could be reused within Wikifunctions.
Thanks to Mahir256 <https://meta.wikimedia.org/wiki/User:Mahir256> for
providing comments on earlier drafts of this newsletter.