I present to you what I title "The Philosophy of Vyxal Design"
It covers the criteria that built-ins need to meet in order to be added
And the criteria that I'll be using to re-evaluate the usefulness of each built-in
As well as some overall goals
:
Vyxal is to be:
= Simple to understand and learn = Concurrently elegant and terse = Suitable for practical and recreational usage
Vyxal has to:
= Provide extensive built-in list functions = Produce logical and predictable results
Built-ins have to be:
= Generalised for most tasks
More specifically, they must either:
A) Be common to the majority of major languages (practical and golf) OR B) Have at least 10 CGCC [tag:code-golf] challenges where they can be used
For a 2 byte command, the requirements are looser...either:
A) Be common to essential/popular libraries (e.g. python's `math` library, or those other extension libaries) OR B) Have at least 4 CGCC [tag:code-golf] challenges where they can be used
Here are some examples of what is and isn't suitable for 1 and 2 byte built-ins.
1) Python's default list methods (dir(list)) are good for 1 byte built-ins
2) Python's math library functions (sans a few commonly featured functions) are good for 2 byte built-ins
3) String methods that can be applied to lists are good for 1 byte. Others are good for 2 bytes
e.g. ob.startswith(...) would be suitable as a 1 byte built-in as it can be extended to work upon lists. ob.lowercase() wouldn't be suitable as a 1 byte built-in because it's string specific
4) Entire stack operators (length, rotate stack, swap, etc) are good for 1 byte
5) List creation tools (ranges, generators, etc) are good for 1 byte. However, there would be some exceptions
