First, it must be legal to bring the code in. As per the result of the community discussion, 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 for providing comments on earlier drafts of this newsletter.