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.

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