Talk:Abstract Wikipedia/Generic function type

Type conversion

Currently, a Z8/Function’s function type is implicit. It can always be derived (made explicit) from the Z17K1/type(s) in the Z8’s Z17/Argument declaration(s) together with the Z8K2/return type. The generic function type, as originally envisaged, requires some redundancy within the function call that returns the generic type, which repeats the types from elsewhere in the function definition. I suppose it would be simple enough to define a type-conversion function over the current form of Z8 returning the generic form (without changing the Z2, of course). Because Z8 would still be a type, rather than a function, we would need a surrogate Z8 function to return the generic function type as a Z4. The minimalist version of this option leaves the canonical and normal forms unchanged. This would imply the need for an additional type-conversion function that turns a generic function into a pre-generic function (with a type of “Z8”). GrounderUK (talk) 16:09, 9 August 2022 (UTC)

Hi @GrounderUK, thanks for your comment! Yes, the generic function type can be derived from the Z17s in Z8K1/argument declarations and the Z4 in Z8K2/return type.

However that is only possible once you have the actual function object that will be called, i.e. the callee. In the caller, you don't have that information. For example, the sort function could take a comparison function as an argument. Currently the only information you would have about that argument is that it is a Z8. It is only when you actually call the sort function on a particular comparison function that you can derive the Z17s/argument declarations and the Z4/return type of that Z8 argument. That's why you need to put information in the type itself.

Moreover, as mentioned in option 2, if we replace the non-generic function type by a generic function type, we can get rid of Z8K1 and Z8K2 entirely, since that information would already be in the type. AAssaf-WMF (talk) 08:16, 12 August 2022 (UTC)

Thank you for the reply. If the function exists (i.e. has a representation within a persistent object), why can you only see its type and not its other keys? And if the function does not exist, its Z17s and and Z8K2 must be in the transient object (which is just a structured string). They may be just references, I suppose, but then there must be corresponding persistent objects whose keys are (or should be) accessible. What am I missing here? Similarly, as in your example, if you have a reference to a “particular comparison function” then the (“type conversion”) function I envisage would give you its generic function type without actually calling the sort function or the comparison function.

So much for my enhanced Option 1. In Option 2, I think it would be inappropriate to get rid of the Z8K1 and Z8K2, since that is where the keys and labels reside.

By the way, I took a look at your proof of concept for Option 3. I think your Z50000 is the same as the “surrogate Z8 function” in my alternative proposal. Do you think the type-conversion I mentioned of a generic function into a pre-generic function is unnecessary? GrounderUK (talk) 10:03, 12 August 2022 (UTC)

Looking back at Option 2, I see you have it containing a list of Z17s, whereas the Function Model suggests it would be a list of Z4s (the values of the Z17K1s). I suppose the resultant generic type would still be a list of Z4s (argument types) plus the Z4 of the return type? Are these separate sub-options? Or would they both be supported, with two different functions able to return the function type? (Or is that a third sub-option?) GrounderUK (talk) 10:43, 12 August 2022 (UTC)