Jump to content

Wikifunctions:Type proposals/configuration of functions for given types

From Wikifunctions

Summary

This will perform a similar role to Z14294, but instead of splitting the functions by Z60, it will split them by 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 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 Z13663 for most other numerical types we enable (integers, reals, complex numbers...).
    • A function written for 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 Z14294, and like it, will need a related type like Z14293.

Structure

Similar to 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

Question for implementation

I was planning to implement this Type, given its strong support, but wanted to clarify how exactly it should look like. Just a question:

  • I first thought it is the same structure as Z14294 and Z14293, just with Z60 replaced by Z4. But the example given above seem to indicate that the K2 of the option type indicates not a list of possible types for which to use the given function, but rather the signature of the types? Does this include just the arguments? Or both the arguments and the return type? Or do we want to leave that open and be agnostic with regards to that question? This is more informative, as this could be left agnostic.
  • But this question isn't: If the options are indeed the signatures, and not just a list of types, should we then rather have a list of list of types, instead a list of types, for the K2 of the function option?

Pinging @99of9, GrounderUK, ListWorshiper, Infernostars, Dv103, and SRG372: --DVrandecic (WMF) (talk) 08:19, 15 October 2025 (UTC)[reply]

I didn't think that deeply when proposing, sorry. It looks like @ScienceD90 made the example for us. I'm sure @GrounderUK will have a good opinion on this. My initial impulse is that allowing us to specify a list of types is a helpful generalisation. I expect they will often correspond with the types in the function signature, but maybe not always. So I think I'd be comfortable with a flat list of types. But on the other hand your list-of-lists suggestion is more general, so may allow ultimate flexibility down the track. --99of9 (talk) 02:29, 16 October 2025 (UTC)[reply]
I wouldn’t be so sure, but I’m thinking about it!
Also considering:
Then there’s a general reservation about the untidiness of the Type (Z4)/Reference (Z9) union via Object (Z1) – phab:T389183 etc., with added complexity for the identity of a Function call (Z7) to Typed enum of Wikidata references (Z6884) and properly generic types. GrounderUK (talk) 12:15, 16 October 2025 (UTC)[reply]
Retrieved from "https://www.wikifunctions.org/w/index.php?title=Wikifunctions:Type_proposals/configuration_of_functions_for_given_types&oldid=246933"