Abstract Wikipedia/Updates/2021-08-27/nan

◀

Tsai-iau Uikiphitia King-sin

▶

Kai-tuānn ζ i-kīng uân-sîng

When we started the development effort towards the Wikifunctions site, we sub-divided the work leading up to the launch of Wikifunctions into eleven phases, named after the first eleven letters of the Greek alphabet.

• With Phase α (alpha) completed, it became possible to create instances of the system-provided Types in the wiki.
• With Phase β (beta), it became possible to create new Types on-wiki and to create instances of these Types.
• With Phase γ (gamma), all the main Types of the pre-generic function model were available.
• With Phase δ (delta), it became possible to evaluate built-in implementations.
• With Phase ε (epsilon), it became possible to evaluate contributor-written implementations in any of our supported programming languages.
• This week, we completed Phase ζ (zeta).

The goal of Phase ζ has been to provide the capability to evaluate implementations composed of other functions.

What does this mean? Every Function in Wikifunctions can have several Implementations. There are three different ways to express an Implementation:

1. As a built-in Function, written in the code of Wikilambda: this means that the Implementation is handled by the evaluator natively using code written by the team.
2. As code in a programming language, created by the contributors of Wikifunctions: the Implementation of a Function can be given in any programming language that Wikifunctions supports. Eventually we aim to support a large number of programming languages; for now we support JavaScript and Python.
3. As a composition of other Functions: this means that contributors can use existing Functions as building blocks in order to implement new capabilities.

With Phase ζ we close the trilogy of Phases dealing with the different ways to create Implementations.

Besides making composition work, we also spent some time on other areas.

We worked to reduce technical debt that we accumulated in development during the last two phases which we rushed in order to be ready for the security and performance reviews. We improved how the error system works, re-worked the data model for Testers and Errors, refactored the common library to be more extensible, moved the content of the wiki to the main namespace, and changed Python function definitions to align with the style we use for JavaScript ones.

We started with some work to make the current bare-bones user experience better. This included displaying Testers' results and meta-data on their own page as well as related Function and Implementation pages. Functions and Implementations can be easily called right from their page. We made it much easier to create and connect Implementations and Testers with their functions, started on the designs for Function definition and implementation, and implemented aliases that sit alongside labels, much like in Wikidata. Plenty done!

We are now moving on to Phase η (eta). The three main goals of phase η is to finish the re-work of the Error system, to revisit user-defined types and integrate them better with validators, and to allow for generic types.

What are generic types?

We have a type for a list of elements. But instead of saying “this is a list of elements”, we can often be more specific, and for example say “this is a list of strings”. Uī-siánn-mi̍h ū lōo-iōng? Because now, if, for example, we have a function to get the first element of a list, we know that this function will return a string when given this kind of list. This allows us to then offer a better user experience by making more specific suggestions, because now the system knows that it can suggest functions that work with strings. We can also check whether an implementation makes sense by ensuring that the types fit. We won’t be able to do that in all cases, but having generics will allow us to increase the number of cases where we can do that by a lot. For more background you can refer to the Wikipedia article on generic programming.

In this example case, instead of a special type representing a list of strings, we will have a function that takes a type and returns a typed list. If you then call this function with the string type as the argument, the result of the function will be the concept of a list of strings. And you can easily use that for any other type, including user-defined types.

Guá beh kám-siā thuân-tuī! My thanks to the volunteers! Some of us are starting to have fun using the prototype, playing with implementations across different programming languages interacting with each other in non-trivial ways, and starting to build a small basic library of functions. This will also be the phase where we move from the pre-generic data model to the full function model. To give due warning: this probably means that almost everything will need to be re-written by the end of this phase, in order to take advantage of the generic system that we are introducing.

Kám-siā lí tsi̍t-lōo phue-phuànn guán!