Talk:Abstract Wikipedia/Typed lists

Autoguessing

When I create programs with the programming language R I usually do not declare what a specific argument in a list or on its has as a type. The easy definition of variables is one of the reasons why use R. For people without a deeper understanding of programming it is not so easy after my understanding to say what a specific argument has as the type. The definition of a string and a boolean is propably claer at the other types I have problems to distinct. After my expierence when experimenting with the conversion of spreadsheet functions into source code in R the needed type comes out of the argument of the function within it is used. So I wish a autoguessing function after it will help people to program much easier after my expierence after thinking about the correct type is complicated.--Hogü-456 (talk) 18:37, 2 April 2022 (UTC)

Generic function

Some function, ⟨Zfff⟩, consumes an untyped Z10/List and a Z4/Type, ⟨Zttt⟩, and emits a (generic) typed list.

The canonicalized Z7/Function call looks like this (using ⟨variables⟩ in place of "literals"):

{
 "Z1K1": "Z7",
 "Z7K1": ⟨Zfff⟩,
 ⟨ZfffK1⟩: ⟨Zttt⟩,
 ⟨ZfffK2⟩: [ "a", "b", "c", "d", "e" ]
}

As previously discussed, I would prefer the following representation, however:

{
 "Z1K1": {
  "Z1K1": "Z4",
  "Z4K1": {
   "Z1K1": "Z7",
   "Z7K1": "Z881",
   "Z881K1": ⟨Zttt⟩
  }
 },
 "K1": {
  "Z1K1": "Z7",
  "Z7K1": ⟨Zfff⟩,
  ⟨ZfffK1⟩: ⟨Zttt⟩,
  ⟨ZfffK2⟩: [ "a", "b", "c", "d", "e" ]
 }
}

Here, I assume that the return type of the "Z881" function is "Z4", whereas the return type of the ⟨Zfff⟩ function is the generic type for a typed list with elements of type ⟨Zttt⟩ (the "Z4" returned by "Z881" for type ⟨Zttt⟩). I suppose this is not currently possible, in which case it could simply be "Z4" (with no change to my preferred representation). --GrounderUK (talk) 13:05, 5 April 2022 (UTC)

Have the first element of a list be the type (option 6)

I have no objection to this option for typed lists, although I raise left-to-right bias as a concern. I do find the use of “Z1” to extend the proposal to untyped lists confusing, however. I think it amounts to saying that all lists must be typed. I suppose we could auto-guess that an untyped list should be a typed list with type “Z1” just because the first element is not a type. We then have the odd case where the untyped list just happens to have a Z4/Type (object, reference or function call) as its first element. Is that invalid when the other elements are not of that type? Or do we transform such an (apparently) invalid typed list into a typed list with type “Z1”? Also, how would we express a list where every element is a {Record} (beginning {"Z1K1:)?

On balance, I think we need to maintain a clear distinction between typed and untyped lists. We could then interpret a typed list with type “Z1” as a list of ZObject {Record}s, rather than being equivalent to an untyped list. Or we could remove the “Z1”, transforming it into a canonical untyped list. For the odd case where an untyped list includes a (non-Z1) Z4/Type (object, reference or function call) as its first element, we need to escape that element somehow. Or we could escape the whole list by embedding it into a Z10 value object, (following the pattern we use for a string that looks like a reference). Alternatively, we could consider (new) option 6c, in which the first element of a typed list is not strictly a Z4/Type. For example, it might be the key–value pair that is used to construct the list’s generic type (so, for the example ""Z881K1": "Z6""). (I assume that we wouldn’t want to use the complete function call, since that would prevent a typed list whose elements have a generic type. However, a function call to a function that generates both the type and the list of that type, as in #Generic function above, would indicate the type and might be used as the first element. I would see that as a variant of the generic function option, however.)

Of course, this notation is very LISP-like. Although the first element looks like a type, it represents the implicit function that evaluates to the list’s generic type. We should recall that Wikifunctions is “something like LISP in JSON” and ZObjects are simply lists where the elements are key–value pairs. That does not mean that a typed list whose generic type is a Z3/Z1 pair should necessarily be interpreted as a transient object, but maybe it could be intended to be just that in the special case where the first (or exactly one) Z3/Key happens to be equal to "Z1K1". Note that the “Z1” in such a pair should be (or become) a ZObject {Record}, as above, with its Z1K1/type consistent with the Z3K1/value type. Specifically, the Z1 in the "Z1K1" pair would be (or become) a Z4 value object (as in the second example in #Generic function, above). I don’t think any of this should be automatic, but I have always thought that we should eventually support ZObject constructor functions, and a LISPy constructor might operate over a typed list of this nature.

TL;DR New variant 6c: the first element of a typed list should not be an actual Z4/Type and a typed list of Z1 elements is not equivalent to an untyped list. Otherwise, an untyped list needs an escape mechanism for the case where the first element is a Z4/Type other than “Z1”.--GrounderUK (talk) 12:57, 14 April 2022 (UTC)