Has there been discussion of Lua
<https://en.wikipedia.org/wiki/Wikipedia:Lua> as one of the languages?
On Thu, Apr 28, 2022 at 8:42 PM Denny Vrandečić <
The on-wiki version of this newsletter can be
Once Wikifunctions launches, we currently plan to support
implementations of functions in two programming languages, Python and
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
First, it must be legal to bring the code in. As per the result of the
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
- 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:
party libraries available. Initially it will only be possible to access the
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
- 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
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.
Abstract-Wikipedia mailing list --
Samuel Klein @metasj w:user:sj +1 617 529
Abstract-Wikipedia mailing list --