Abstract Wikipedia/Updates/2021-05-11/tr

◀

Abstract Wikipedia Updates

▶

Aşama δ tamamlandı.

When we started the development effort towards the Wikifunctions site, we subdivided 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 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.
• This week, we completed Phase δ (delta).

The goal of Phase δ was to provide the capability to evaluate built-in implementations.

Bu ne anlama geliyor? Every function in Wikifunctions can have several implementations. There are three different ways to express an implementation:

1. As some code in a programming language, written by the users 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, but we will start small.
2. As a built-in function, written by the development team: this means that the implementation is handled by the evaluator as a black box. We hope to rely on only a very small number of required built-in functions, since each evaluator needs to implement all built-in functions to be usable, and we want to make adding new evaluators (and so new programming languages) as easy as possible. A list of built-in functions currently available is given below. This list is likely not final, but we hope it won't grow.
3. As a composition of other functions: this means that we use existing functions as building blocks in order to implement new capabilities. We have published a few examples of composed implementations. The example implementation of the Boolean functions might be particularly instructive.

In Phase δ, we created the infrastructure and interfaces to evaluate function calls at all, and allowed for built-in implementations. The built-in functions that are currently available are the following:

• If : Boolean, Any, Any ➝ Any — returns second argument if the first is true, else the third; if has two letters.
• Value by key : Key reference, Any ➝ Any — returns the value of the given key of the given object.
• Reify : Any ➝ List(Pair(Key reference, Any)) — transforms any object into a list of key-value pairs; it deconstructs the object.
• Abstract : List(Pair(Key reference, Any)) ➝ Any — transforms a list of key-value pairs into an object; it constructs an object.
• Cons : Any, List ➝ List — inserts an object to the front of an ordered list of objects.
• Head : List ➝ Any — gets the first item of a list.
• Tail : List ➝ List — gets the list with the first item removed.
• Empty : List ➝ Boolean — returns if a list does not contain any item.
• First : Pair ➝ Any — extracts the first value of a pair.
• Second : Pair ➝ Any — extracts the second value of a pair.
• Convert : String ➝ List(Character) — converts a string into a list of Characters.
• Convert : List(Character) ➝ String — converts a list of Characters into a string.
• Same : Character, Character ➝ Boolean — compares two characters and return if they are equal.
• Unquote : Quote ➝ Any — unquotes a Quote.

All of the implementations of these built-ins, though simple, are first drafts, and currently only lightly tested. If you test them and find issues, please report them on Phabricator or send an email to our mailing list. We will improve these over the following weeks.

The two screenshots show a new special page that lets you evaluate a function call. Here we offer two screenshots with examples. The first one shows the call to the If function. The condition is set to true, and thus the function call should return the consequent (given as the String “this”) and not the alternative (given as the String “that”). And indeed, the Orchestration result below the function call shows a normalized result representing the String “this”:

The second example is taken straight from the phase completion condition on the Phases planning. Here we check whether an empty list is indeed empty (we are calling the Z813/Empty function, and the argument, Z813K1/list is an empty list). The result is true (i.e. the Z40/Boolean with the Z40K1/identity Z41/true):

We promise to improve the UX before launch! This raw JSON output is mostly for debugging and internal development purposes as we work on a design language for the user experience.

We are now moving on to Phase ε (epsilon). In this phase we aim to support user-written implementations in a programming language. Our initial plan is to support code written in JavaScript and Python.

Since running arbitrary code written by anyone on the Internet has major security and performance risks, we will follow up the work in this phase with thorough security and performance reviews working with colleagues across the Foundation.

We currently do not have an official public test instance of the WikiLambda system running. Lucas Werkmeister has, in his volunteer capacity, so far provided us with a regularly updated public test instance, notwikilambda, for which we are deeply grateful, but that instance has not yet been updated to support the orchestrator backend (as we still need to document how to do so). We will continue to not run an instance of our own until after the security and performance reviews have concluded (but we certainly won’t stop anyone else from doing so, and can provide some support on the usual channels if someone wants to set it up).

Following the conclusion of the current Phase, we will move on to Phase ζ (zeta), which will allow for the third type of implementations, compositions.

Thanks to the team, thanks to the volunteers, for their great effort in bringing us so far, and I am excited for the next steps of the project!

(Note: there will not be a newsletter next week.)