The on-wiki version can be found here: https://meta.wikimedia.org/wiki/Special:MyLanguage/Abstract_Wikipedia/Update...
* * *
Today we will talk a little bit about how the catalog of functions will actually work. A more formal and comprehensive description of this is the function model https://meta.wikimedia.org/wiki/Special:MyLanguage/Abstract_Wikipedia/Wiki_of_functions_naming_contest, but here we want to create a more intuitive explanation.
Every page in the new wiki will contain one *Object*. Every Object is of exactly one *Type*. Types decide what the Object means. Types also decide what makes an Object valid or not. An Object that is of a certain Type is called an *instance* of that Type. Every Object that is stored as a wiki page is called a *Persistent Object*, and such an Object has a Z-ID by which it can be referenced. The Z-ID is the name of the page.
What does it mean that the Type decides what the Object means? Let’s look at an example. An Object of Type *Positive Integer* with the value "2020" represents the number 2020. That’s the number you get when you multiply 4, 5 and 101. And because it has the Type of Positive Integer, we know it is a number. If the Type of "2020" was String, then that wouldn’t represent the number 2020, but rather a sequence of four characters, "2", "0", "2", and 0. If the Type of it was *Gregorian Calendar Year* then this would represent the year 2020 in that calendar, a leap year starting with a Wednesday and ending with a Thursday.
The Type decides what you can do with an Object -- or, more formally speaking, which Functions you can apply to the given Object. If you have a String, you can count the length of the String, *i.e.* how many characters are in the sequence. The result for "2020" above would be four. If you have a Gregorian Calendar Year, you might also be able to ask for the 'length', but the result should probably be 366 days (as it is a leap year). If you have a Positive Integer and ask for its length, you might be asking for the logarithm in base 10, or you might be asking for the multiplicative persistence https://en.wikipedia.org/wiki/Persistence_of_a_number. But all of these would be different Functions (that may well have the same label, “length”, in English; their descriptions would explain in more detail what they would do). The Function states which Types it can take, and the Type decides what an Object means.
Types can be very diverse. Some Types might have a small, explicitly defined number of instances. These are called *Enumerations*, because all the instances of the Type are known in advance and enumerated, and each instance must be one of these few possible values. The classic example of such a Type is *Boolean*, named after George Boole https://en.wikipedia.org/wiki/George_Boole, which has exactly two instances: *True* and *False*. Another Enumeration would be the *Days of the Week*. Other Types can be simple but have an infinite number of possible instances. Examples of such Types are *String* for sequences of characters, and *Positive Integer* for the counting numbers. Other Types can be composed of simpler Types. For example, one way to represent an *Integer* would be to compose it from a Positive Integer and a Boolean, where the Boolean decides whether the Integer is positive or negative, and the Positive Integer represents the absolute value.
Not every Object has to be stored as a wiki page. For example, there is no need to store the number 2020 as an Object in the wiki, as it can be easily just created on the fly.
This is how Objects are built and represented. Objects of almost all Types are called *Literals*. A Literal is an Object that, when evaluated, results in itself. For example, when you evaluate the number 2020, the result is the number 2020. But there are two very special Types whose instances are not Literals, and these two types are *References* and *Function Calls*.
References are a special Type of Object that refers to a Persistent Object by its Z-ID. It basically just says “here, this Reference, should really be just this Object that is referenced to by this Z-ID”. Evaluating a Reference results in the referenced Object. A Reference does not need to be evaluated immediately, but can be evaluated whenever needed. In fact, it is sometimes impossible to evaluate all References fully, as it can easily lead to a recursion and infinite objects.
The other special Type of Object is the Function Call. A Function Call consists of a *Function* and a *List of Arguments*. Evaluating a Function Call is the core 'magic' of the whole system: it is basically replacing a Function Call with the result of that Function Call, *e.g.* evaluation would be replacing the Function Call to the Function with the label "length" and the argument "2020" of Type String with the value "4" of Type Positive Integer.
Function Calls are usually created on the fly. We wouldn’t, in general, create a new wiki page with a Persistent Object in which we store the Function Call described above, but rather we would send that Function Call to an evaluation engine which, in turn, evaluates the Function Call and returns the result. There is really not much more to the system than that. A Function Call is in many ways analogous to using a MediaWiki template https://www.mediawiki.org/wiki/Help:Templates with parameters.
I hope that this explanation made some sense and helped with understanding the planned system. We are currently developing the part of the system that allows contributors to create Types inside the wiki itself, so that the community can create and control which Types exist. Please feel free to ask questions. ------------------------------
The voting for the final round of the naming contest https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Wiki_of_functions_naming_contest/Names is ongoing. Voting will be open until Monday, November 16. If you haven’t already, please vote here and decide on a name for the new project where all of these Objects we described above will be available. The proposals we are voting on are, in reverse alphabetical order: *Wikimedia Functions*, *Wikilambda*, *Wikifusion*, *Wikifunctions*, *Wikicodex*, and *Wikicode*. Let us know your preferences and decide on the name of the new project by Monday!
On 11.11.20 02:17, Denny Vrandečić wrote:
This is how Objects are built and represented. Objects of almost all Types are called *Literals*. A Literal is an Object that, when evaluated, results in itself. For example, when you evaluate the number 2020, the result is the number 2020. But there are two very special Types whose instances are not Literals, and these two types are *References* and *Function Calls*.
To check that I’m not misunderstanding this: does this mean that the more general AbstractText concept of “evaluator functions” has been abandoned? In AbstractText, if I understood correctly, any type could have an evaluator function which would determine how instances of the type were evaluated; a “literal” would then be when the evaluator function returns the same value (you’ve reached a fixed point).
(I will confess that if my understanding is right, I won’t be sad to see evaluator functions go; I had not yet gotten around to fully understanding them, and I believe in GraalEneyj only references and function calls have special evaluation so far.)
Cheers, Lucas
Yes, that's correct. The reason was that, in the end, the evaluator functions were some form of magic wrapping around any possible type. In some cases it would lead to make things look a little bit neater (as magic usually does), but in most cases it is just additional overhead. Instead of having magic evaluator functions, we can always have these explicit.
As usual, I don't know if this is the right approach, but it feels like it makes it simpler to abandon evaluator functions. The new proposal also suggests to abandon linearizer functions and basically all other hard-coded such functions, besides the validator function, which remains a crucial part of the data model.
Thanks for checking, Cheers, Denny
On Sun, Nov 29, 2020 at 2:17 PM Lucas Werkmeister mail@lucaswerkmeister.de wrote:
On 11.11.20 02:17, Denny Vrandečić wrote:
This is how Objects are built and represented. Objects of almost all Types are called *Literals*. A Literal is an Object that, when evaluated, results in itself. For example, when you evaluate the number 2020, the result is the number 2020. But there are two very special Types whose instances are not Literals, and these two types are *References* and *Function Calls*.
To check that I’m not misunderstanding this: does this mean that the more general AbstractText concept of “evaluator functions” has been abandoned? In AbstractText, if I understood correctly, any type could have an evaluator function which would determine how instances of the type were evaluated; a “literal” would then be when the evaluator function returns the same value (you’ve reached a fixed point).
(I will confess that if my understanding is right, I won’t be sad to see evaluator functions go; I had not yet gotten around to fully understanding them, and I believe in GraalEneyj only references and function calls have special evaluation so far.)
Cheers, Lucas _______________________________________________ Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
Sorry, has the "new proposal" been drafted? --Al.
On Tuesday, 1 December 2020, Denny Vrandečić dvrandecic@wikimedia.org wrote:
Yes, that's correct. The reason was that, in the end, the evaluator functions were some form of magic wrapping around any possible type. In some cases it would lead to make things look a little bit neater (as magic usually does), but in most cases it is just additional overhead. Instead of having magic evaluator functions, we can always have these explicit.
As usual, I don't know if this is the right approach, but it feels like it makes it simpler to abandon evaluator functions. The new proposal also suggests to abandon linearizer functions and basically all other hard-coded such functions, besides the validator function, which remains a crucial part of the data model.
Thanks for checking, Cheers, Denny
On Sun, Nov 29, 2020 at 2:17 PM Lucas Werkmeister < mail@lucaswerkmeister.de> wrote:
On 11.11.20 02:17, Denny Vrandečić wrote:
This is how Objects are built and represented. Objects of almost all Types are called *Literals*. A Literal is an Object that, when evaluated, results in itself. For example, when you evaluate the number 2020, the result is the number 2020. But there are two very special Types whose instances are not Literals, and these two types are *References* and *Function Calls*.
To check that I’m not misunderstanding this: does this mean that the more general AbstractText concept of “evaluator functions” has been abandoned? In AbstractText, if I understood correctly, any type could have an evaluator function which would determine how instances of the type were evaluated; a “literal” would then be when the evaluator function returns the same value (you’ve reached a fixed point).
(I will confess that if my understanding is right, I won’t be sad to see evaluator functions go; I had not yet gotten around to fully understanding them, and I believe in GraalEneyj only references and function calls have special evaluation so far.)
Cheers, Lucas _______________________________________________ Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
Hi Al,
thanks for asking, I was unclear in the wording:
the new proposal refers to the fluent state of this: https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Function_model
"New" in this case, in my mind, was comparing it to the old proposal of abstracttext https://github.com/google/abstracttext
Thanks for asking and giving me the opportunity to clarify, Denny
On Thu, Dec 3, 2020 at 5:58 AM Grounder UK grounderuk@gmail.com wrote:
Sorry, has the "new proposal" been drafted? --Al.
On Tuesday, 1 December 2020, Denny Vrandečić dvrandecic@wikimedia.org wrote:
Yes, that's correct. The reason was that, in the end, the evaluator functions were some form of magic wrapping around any possible type. In some cases it would lead to make things look a little bit neater (as magic usually does), but in most cases it is just additional overhead. Instead of having magic evaluator functions, we can always have these explicit.
As usual, I don't know if this is the right approach, but it feels like it makes it simpler to abandon evaluator functions. The new proposal also suggests to abandon linearizer functions and basically all other hard-coded such functions, besides the validator function, which remains a crucial part of the data model.
Thanks for checking, Cheers, Denny
On Sun, Nov 29, 2020 at 2:17 PM Lucas Werkmeister < mail@lucaswerkmeister.de> wrote:
On 11.11.20 02:17, Denny Vrandečić wrote:
This is how Objects are built and represented. Objects of almost all Types are called *Literals*. A Literal is an Object that, when evaluated, results in itself. For example, when you evaluate the number 2020, the result is the number 2020. But there are two very special Types whose instances are not Literals, and these two types are *References* and *Function Calls*.
To check that I’m not misunderstanding this: does this mean that the more general AbstractText concept of “evaluator functions” has been abandoned? In AbstractText, if I understood correctly, any type could have an evaluator function which would determine how instances of the type were evaluated; a “literal” would then be when the evaluator function returns the same value (you’ve reached a fixed point).
(I will confess that if my understanding is right, I won’t be sad to see evaluator functions go; I had not yet gotten around to fully understanding them, and I believe in GraalEneyj only references and function calls have special evaluation so far.)
Cheers, Lucas _______________________________________________ Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
Thank you for clarifying, Denny.
I see why a Z4K3/validator is a hard-coded function, as the arguments to the referenced Z8/Function are implicit within the Z4/Type. It does feel as though a Z7/Function_call might be similar, in that the arguments within the function call are, in fact, arguments to the referenced Z8/Function (or to the transient function embedded in the function call). It was envisaged that a new Z8/Function (Z824) would expand the Z7/Function_call prior to evaluation, presumably ensuring that the arguments in the call are valid with respect to the function's signature. Personally, I think I might prefer a bit of hard-coding here. For example, "Z824" could be defined as the "call constructor" within the definition of the Z8/Function, possibly (like the Z4K3/validator) within the definition of its Z4/Type.
Regards, Al.
On Friday, 4 December 2020, Denny Vrandečić dvrandecic@wikimedia.org wrote:
Hi Al,
thanks for asking, I was unclear in the wording:
the new proposal refers to the fluent state of this: https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Function_model
"New" in this case, in my mind, was comparing it to the old proposal of abstracttext https://github.com/google/abstracttext
Thanks for asking and giving me the opportunity to clarify, Denny
On Thu, Dec 3, 2020 at 5:58 AM Grounder UK grounderuk@gmail.com wrote:
Sorry, has the "new proposal" been drafted? --Al.
On Tuesday, 1 December 2020, Denny Vrandečić dvrandecic@wikimedia.org wrote:
Yes, that's correct. The reason was that, in the end, the evaluator functions were some form of magic wrapping around any possible type. In some cases it would lead to make things look a little bit neater (as magic usually does), but in most cases it is just additional overhead. Instead of having magic evaluator functions, we can always have these explicit.
As usual, I don't know if this is the right approach, but it feels like it makes it simpler to abandon evaluator functions. The new proposal also suggests to abandon linearizer functions and basically all other hard-coded such functions, besides the validator function, which remains a crucial part of the data model.
Thanks for checking, Cheers, Denny
On Sun, Nov 29, 2020 at 2:17 PM Lucas Werkmeister < mail@lucaswerkmeister.de> wrote:
On 11.11.20 02:17, Denny Vrandečić wrote:
This is how Objects are built and represented. Objects of almost all Types are called *Literals*. A Literal is an Object that, when evaluated, results in itself. For example, when you evaluate the number 2020, the result is the number 2020. But there are two very special Types whose instances are not Literals, and these two types are *References* and *Function Calls*.
To check that I’m not misunderstanding this: does this mean that the more general AbstractText concept of “evaluator functions” has been abandoned? In AbstractText, if I understood correctly, any type could have an evaluator function which would determine how instances of the type were evaluated; a “literal” would then be when the evaluator function returns the same value (you’ve reached a fixed point).
(I will confess that if my understanding is right, I won’t be sad to see evaluator functions go; I had not yet gotten around to fully understanding them, and I believe in GraalEneyj only references and function calls have special evaluation so far.)
Cheers, Lucas _______________________________________________ Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
abstract-wikipedia@lists.wikimedia.org