Абстрактна Вікіпедія/Оновлення/2021-05-11

This page is a translated version of the page Abstract Wikipedia/Updates/2021-05-11 and the translation is 22% complete.
Оновлення Абстрактної Вікіпедії Translate

Абстрактна Вікіпедія (список розсилки) Абстрактна Вікіпедія в ICR Абстрактна Вікіпедія в Телеграм Wikifunctions on Mastodon Абстрактна Вікіпедія у Твіттері Абстрактна Вікіпедія у Фейсбуці Абстрактна Вікіпедія на Ютубі Сторінка проекту Абстрактні Вікіпедії Translate

Фаза δ завершена

Коли ми розпочали розробку сайту Вікіфункцій, ми поділили роботу з запуску Вікіфункцій на одинадцять фаз, названих першими одинадцятьма буквами грецького алфавіту.

Метою етапу δ було забезпечити можливість оцінки вбудованих реалізацій.

Що це означає? Кожна функція у Вікіфункціях може мати декілька реалізацій. Існують три різні способи вираження реалізації:

  1. Як деякий код на мові програмування, написаний користувачами Вікіфункцій: реалізація функції може бути надана будь-якою мовою програмування, яку підтримують Вікіфункції. Зрештою ми прагнемо підтримати велику кількість мов програмування, але почнемо з малого.
  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 ➝ Anyreturns second argument if the first is true, else the third; if has two letters.
  • Value by key : Key reference, Any ➝ Anyreturns 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)) ➝ Anytransforms a list of key-value pairs into an object; it constructs an object.
  • Cons : Any, List ➝ Listinserts an object to the front of an ordered list of objects.
  • Head : List ➝ Anygets the first item of a list.
  • Tail : List ➝ Listgets the list with the first item removed.
  • Empty : List ➝ Booleanreturns if a list does not contain any item.
  • First : Pair ➝ Anyextracts the first value of a pair.
  • Second : Pair ➝ Anyextracts the second value of a pair.
  • Convert : String ➝ List(Character)converts a string into a list of Characters.
  • Convert : List(Character) ➝ Stringconverts a list of Characters into a string.
  • Same : Character, Character ➝ Booleancompares two characters and return if they are equal.
  • Unquote : Quote ➝ Anyunquotes 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.)