Hi SJ,
I could have sworn that there was already a task for it, but I couldn't
find it. It is part of the initial Abstract Wikipedia plan:
We currently do not plan to implement support for Lua in time for the
launch (unless someone else implements it), but we do plan to address this
issue relatively soon after launch. Lua will likely be the first
programming language to be added after launch (unless someone else
implements another language sooner).
Cheers,
Denny
On Thu, Apr 28, 2022 at 5:51 PM Samuel Klein <meta.sj(a)gmail.com> wrote:
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> 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…
_______________________________________________
Abstract-Wikipedia mailing list --
abstract-wikipedia(a)lists.wikimedia.org
List information: