Abstract Wikipedia/Pre-generic function model/da

This page is a translated version of the page Abstract Wikipedia/Pre-generic function model and the translation is 22% complete.
This page is historic and does not describe the current situation. See f:Wikifunctions:Function model for the current version of the function model.

Abstrakte Wikipedia via mailingliste Abstrakte Wikipedia på IRC Wikifunctions på Telegram Wikifunctions på Mastodon Wikifunctions på Twitter Wikifunctions på Facebook Wikifunctions på YouTube Wikifunctions-websted Translate

The current function model prescribes the function model of Wikifunctions for the time where we plan to launch the wiki. In particular, it assumes that we are already quite feature complete and have the ability to run functions, function calls, composition, and generic types. But these won’t be available until Phase ζ (zeta). This currently hampers the implementations of tasks in the earlier phases as we have to come up on the fly with non-generic versions of central types.

(It’s actually even worse: in reality the function model is some weird hybrid between the launch function model and the pre-generic one; We want to clean up both parts with this rewrite, starting with defining the pre-generic function model.)

In order to resolve this barrier, we provide here a simplified version of the full function model that is meant as a stop-gap solution until generics are available.

One overall difference is that without generics there is a greatly diminished need for local keys. So the whole function model assumes that we do not have local keys, or that we can get rid of them in normalization. This will not be possible once we have generics.

“No difference” in the list below means that this type is the same in the pre-generic model as well as in the full function model.

Note that the ZIDs are not final. The discussion is ongoing here.

  • Z1K1/type (Z4/Type)

Ingen forskel.

Z2/Persistent object (Z4/Type)

  • Z2K1/id (Z6/String)
  • Z2K2/value (Z1/Object)
  • Z2K3/label (Z12/Multilingual text)
  • Z2K4/aliases (Z32/Multilingual set)
  • Z2K5/description (Z12/Multilingual text)


Ingen forskel.

Z3/Key (Z4/Type)

  • Z3K1/value type (Z4/Type)
  • Z3K2/key id (Z6/String)
  • Z3K3/label (Z12/Multilingual text)

Ingen forskel.

Z4/Type (Z4/Type)

  • Z4K1/identity (Z4/Type)
  • Z4K2/keys (Z10/List)
  • Z4K3/validator (Z8/Function)

Z4K2 should expect a Z10/List of Z3/Key but that is not possible yet. So it just expects a Z10/List.

Z4K3 should expect a Z8/Function that takes a single input of type Z1/Object and returns a Z10/List of Z5/Error, but that is not possible yet, so it is just Z8/Function.

Z5/Error (Z4/Type)

  • Z5K1/error type (Z50/Error type)
  • Z5K2/error value (Z1/Any)

Måske ingen forskel?

Z6/String (Z4/Type)

  • Z6K1/string value (Z6/String)

Ingen forskel.

Z7/Function call (Z4/Type)

  • Z7K1/function (Z8/Function)
  • Others based on Z8/Function

This will change significantly. In the pre-generic version this is a Z4/Type whose instances have wildly different behavior than any other type’s instances: the keys are not defined by the Z4/Type, but by the Z8/Function. This will need special handling in the pre-generic world. For the post-generic world we hope to get a unified treatment. See discussion here.

Z8/Function (Z4/Type)

  • Z8K1/arguments (Z10/List)
  • Z8K2/return type (Z4/Type)
  • Z8K3/testers (Z10/List)
  • Z8K4/implementations (Z10/List)
  • Z8K5/identity (Z8/Function)

This will change significantly. In the pre-generic version this is a Z4/Type and this will become a Z8/Function later that has basically the given keys. Z8K1/arguments should be a Z10/List of Z17/Argument declaration (TBD). Z8K3 and Z8K4 should be a Z10/List of Z20/Tester respectively Z14/Implementation with the given Z8/Function as an argument. Needs to be specced out fully.

Z9/Reference (Z4/Type)

  • Z9K1/reference ID (Z6/String)

Ingen forskel.

Z10/List (Z4/Type)

  • Z10K1/head (Z1/Object)
  • Z10K2/tail (Z10/List)

This will be the classic generic Z4/Type. In the pre-generic version it takes any Z1/Object as a value and then has a Z10/List as its continuation. In the post-generic world this will become a Z8/Function with a single argument of type Z4/Type that returns a Z4/Type (the parameterized list) whose type for the head will be the given Z4/Type and whose type for the tail will be a Z10/List parametrized with the same type.

Z11/Monolingual text (Z4/Type)

  • Z11K1/language (Z60/Language)
  • Z11K2/text (Z6/String)

Ingen forskel.

Z12/Multilingual text (Z4/Type)

  • Z12K1/texts (Z10/List)

The type of Z12K1 should become a Z10/List of Z11/Monolingual texts.

Z14/Implementation (Z4/Type)

  • Z14K1/function (Z8/Function)
  • Z14K2/composition (Z1/Any)
  • Z14K3/code (Z16/Code)
  • Z14K4/built in (Z6/String)

This should take the function as an argument. Needs to be rethought.

Z16/Code (Z4/Type)

  • Z16K1/language (Z61/Programming language)
  • Z16K2/code (Z6/String)
  • Z16K3/signature (Z10/List)

The signature will be a Z10/List of Z4/Types. That will be only needed in the generic model: the only reason for having a signature separate from the one in the definition is that we might not need to evaluate the values before executing the function.

Z17/Argument declaration

  • Z17K1/argument type (Z4/Type)
  • Z17K2/key id (Z6/String)
  • Z17K3/label (Z12/Multilingual text)

Ingen forskel. But does it even need to exist or can it be just Z3/Key?

Z18/Argument reference (Z4/Type)

  • Z18K1/key id (Z6/String)

Ingen forskel.

Z20/Tester (Z4/Type)

  • Z20K1/function (Z8/Function)
  • Z20K2/call (Z7/Function call)
  • Z20K3/result validation (Z7/Function call)

Z21/Unit (Z4/Type)

  • (Ingen nøgler)

Ingen forskel.

Z22/Pair (Z4/Type)

  • Z22K1/first (Z1/Object)
  • Z22K2/second (Z1/Object)

This will be generic too.

Z23/Nothing (Z4/Type)

  • (Ingen nøgler)

Ingen forskel.

Z31/MonoLingualStringSet (Z4/Type)

  • Z31K1/language (Z60/Language)
  • Z31K2/stringset (Z10/List)

Z31K2/stringset will be a Z10/List of Z6/Strings.

Z32/MultiLingualStringSet (Z4/Type)

  • Z21K1/stringsets (Z10/List)

Z32K1/stringsets will be a Z10/List of Z31/MonoLingualStringSets.

Z39/Key reference (Z4/Type)

  • Z39K1/reference (Z6/String)

Ingen forskel.

Z40/Boolean (Z4/Type)

  • Z40K1/identity (Z40/Boolean)

Ingen forskel.

Z50/Error type (Z4/Type)

  • Z50K1/keys (Z10/List)
  • Z50K2/...: Something that turns this into a string given the keys. This will be added later.

This will change. The Z50K1 will be a Z10/List of Z3/Keys, and more importantly, this would become a function that creates a Z4/Type.

Z60/Language (Z4/Type)

  • Z60K1/code (Z6/String)
  • Z60K2/code aliases (Z10/List)

Ingen forskel.

Z61/Programming language (Z4/Type)

  • Z61K1/code (Z6/String)

Ingen forskel.

Z70/Union (Z4/Type)

Does not exist in the pre-generic model.

Z80/Byte (Z4/Type)

  • Z80K1/value (Z6/String)

Ingen forskel.

Z86/Code point (Z4/Type)

  • Z86K1/value (Z6/String)

Ingen forskel.

Z99/Quote (Z4/Type)

  • Z99K1/quotation (Z1/Object)

Ingen forskel.

Se også