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...).
- A function written for Gregorian calendar month (Z16098) could easily be generalised to apply to other types of months in other calendar systems.

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

Similar to Configuration of functions for given languages (Z14294). Values would have a list of options. Each option has a function to use for that option and a list of types describing the option to choose. There is also a default function on the main object.

Example values

Example value for multiplication configuration

{
  "type": "configuration of functions for given types",
  "options": [
    "function option of a type",
    {
      "type": "function option of a type",
      "function to use": "multiply two natural numbers",
      "for these types": ["Type", "Natural Number", "Natural Number"]
    },
    {
      "type": "function option of a type",
      "function to use": "multiply signs",
      "for these types": ["Type", "Sign", "Sign"]
    },
    {
      "type": "function option of a type",
      "function to use": "multiply integers",
      "for these types": ["Type", "Integer", "Integer"]
    }
  ],
  "default function": "raise type error"
}

{
  "Z1K1": "Zmmmmm",
  "ZmmmmmK1": [
    "Znnnnn",
    {
      "Z1K1": "Znnnnn",
      "ZnnnnnK1": "Z13539",
      "ZnnnnnK2": ["Z4", "Z13518", "Z13518"]
    },
    {
      "Z1K1": "Znnnnn",
      "ZnnnnnK1": "Z16728",
      "ZnnnnnK2": ["Z4", "Z16659", "Z16659"]
    },
    {
      "Z1K1": "Znnnnn",
      "ZnnnnnK1": "Z17120",
      "ZnnnnnK2": ["Z4", "Z16683", "Z16683"]
    }
  ],
  "ZmmmmmK2": "Zooooo"
}

Validator

The validator ensures that:

There are no entries with same list of types as another entry

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

A dict will be returned to Python code.

JavaScript

An object will be returned to Javascript code.

Renderer

We will use the regular UI for renderering and it will not have a string renderer

Parsers

We will use the regular UI for parsing and it will not have a string parser

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]
Strong support The current system is already quite annoying for the integer (add Integers (Z16693)) / natural (add two Natural numbers (Z13521)) / string (add two integer strings (Z10782)) split, and I can't imagine this getting any better with the other numeric types (float64, complex128 and fraction). infernostars (talk) (contribs) 18:00, 30 August 2024 (UTC)[reply]

…