[Abstract-wikipedia] Re: Fwd: Re: Newsletter #70: Requirements for code in Wikifunctions

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ć < dvrandecic(a)wikimedia.org&gt; wrote: > 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. > > > _______________________________________________ > Abstract-Wikipedia mailing list -- > abstract-wikipedia(a)lists.wikimedia.org > List information: > https://lists.wikimedia.org/postorius/lists/abstract-wikipedia.lists.wikime… > -- Samuel Klein @metasj w:user:sj +1 617 529 4266 _______________________________________________ Abstract-Wikipedia mailing list -- abstract-wikipedia(a)lists.wikimedia.org List information: https://lists.wikimedia.org/postorius/lists/abstract-wikipedia.lists.wikime…