I’d urge you to take a look at the code for 🧰 [TOOL] CSLIB - ChoiceScript Library, if you haven’t already. It already provides some similar functionality (is_number) and uses similar concepts (e.g. an alphabetical lookup). Plus, if you find yourself implementing something that it doesn’t provide, it’d be great if you’d consider contributing it to that project, as the aim of CSLIB is not overly dissimilar to your words below:
Imagine the ability to left all this work to a predefined set of function that will administrate all this data for you. Giving the choiceScript author the ability to only focus in the story and leaving the heavy lifting of coding for the Data handlers deal??
I do think there’s limitations to what you can do at runtime though. Static analysis has more promise, at least for global variables (temps are more difficult), as you can infer the type from the initial value (though there are some edge cases, like the boolean case StephenHart mentioned). That’s probably not helpful to you here though.
Personally, now we have create_array, I find most of my data structure usage is covered by creating arrays that are big enough to hold any foreseeable amount of values. But I long since accepted that bullying ChoiceScript into doing anything too complicated, whilst very fun, is rarely worth it in practice (but that’s just a personal opinion of course!).
A final thought: is there anything stopping you from storing the associated data type in the “memory”? If you’re asking the user for numerical input, a simple implementation could be storing “num:${data}”.