I've made a file called choices.yaml for version 3 planning
and the idea behind it is that it's listing all the potential character candidates for each of the core function
and then, once choices.yaml is done, an inverse yaml can be automatically generated where all the overload candidates for a specific character are listed
so if function A has candidates [a, b, c], function B has candidates, [b, c] and function C has candidates [a, c], then the inverse yaml will be something like
- character: a
choices: [A, C]
- character: b
choices: [A, B]
- character: c
choices: [A, B, C]
with the idea being that there'd be no overlaps between overloads
in choices.yaml, there's a few "patterns" I've listed
(I say patterns for lack of better word for code style)
function: "Core function name"
type: element
overloads: [types that this core function supports]
candidates: [...] # copilot suggestions
where the # copilot suggestions is what copilot thought would be a good candidate
candidates are taken from the codepage btw
the overloads section of the element style contains all the different combos of types
so half might operate on [number, string], range [0, n) might operate on [number], and addition might operate on [number-number, number-string*, string-string]
the number-string* means that it also operates on string-number
oh oh and number-string$ means that the result of both string-number and number-string are equivalent
also today I realised for the first time that Vylight is supposed to be a play on the word highlight and that it isn't a light-theme syntax highlighter
this is despite the fact I read it as vy as in high
