Wikifunctions:Type proposals/configuration of functions for given types

Summary

This will perform a similar role to Configuration of functions for given languages (Z14294), but instead of splitting the functions by Natural language (Z60), it will split them by Type (Z4) (likely to switch the function according to its input, output, or both).

Uses

Prompts:

Why should this exist?

Some linguistic functions branch naturally according to the dialect. Similarly many functions branch according to the type of input they are given (and/or the output desired).

What kinds of functions would be created using this?
- We will be able to perform object equality (Z13052), but direct the comparisons toward the correct type-specific equality functions.
- We will be able to appropriately group type-specific versions of the same function with an overarching meta function. For example, we are likely to have a version of n^2 (Z13663) for most other numerical types we enable (integers, reals, complex numbers...).

What standard concepts, if any, does this align with?

It is very similar to Configuration of functions for given languages (Z14294), and like it, will need a related type like function option for a list of languages (Z14293).

Structure

Example values

Not yet completed.

{ "type": "…", "value": "…" }	{ "Z1K1": "Zxyz", "ZxyzK1": "0" }

Validator

The validator ensures that:

Identity

Two configuration of functions for given types are the same if they map to the same function for every language (order in the list should not matter).

Converting to code

Python

…

JavaScript

…

Renderer

…

Parsers

…

Alternatives

Feel free to suggest.

Comments

Support as proposer. --99of9 (talk) 08:43, 27 March 2024 (UTC)[reply]
Strangely, we didn’t get a Type proposal for Configuration of functions for given languages (Z14294). My intuition is that this current proposal is logically prior to that one, and I think they both need to be considered along with Wikifunctions:Representing identity. I’m guessing there will be no progress there until after Easter. I’ll add this proposal to that page’s discussion later (if no one else does). I don’t yet see any reason to oppose this particular proposal, however.--GrounderUK (talk) 11:02, 27 March 2024 (UTC)[reply]
Please see Wikifunctions talk:Representing identity#Type safety

The most significant difference between this proposal and Configuration of functions for given languages (Z14294) is that this is more clearly “type distributive” or “type convergent”, and these cases could usefully be distinguished. Where functions are grouped by similar arguments but produce different types of result (their return types are not common but their arguments are: “type distributive”), we should ensure that each of the possible resultant types is valid in the immediate context. This is easier when the functions produce the same type of result from diverse forms of input (“type convergent”) but it suggests that the appropriate function may depend on factors other than type (or language), such as the number of inputs or the range within which some input falls.

Essentially, that would make this proposal and the language-driven version, a case construct. If that is the intention, at least in part, we should seek to ensure that lazy evaluation applies and, if feasible, that only the required branch is orchestrated prior to evaluation (which should itself deliver lazy evaluation). GrounderUK (talk) 15:34, 5 April 2024 (UTC)[reply]
Support I think this would be way cleaner than have dozens of different functions that still do the same thing conceptionally but edit different types. This will become more and more beneficially as new types start to be introduced. -ListWorshiper (talk) 16:09, 04 April 2024 (UTC)[reply]

…