"Finding the Invariant" - Case Study: TO

I was trying to make some fairly generic routines that would accept either a WORD!, a TEXT!, a CHAR!, or an INTEGER!. Then it would give you either a WORD! or an INTEGER! out.

At some point I ran up against this:

>> to integer! "1"
== 1

>> to integer! #"1"  ; I wanted 1...
== 49  ; ..but I got a codepoint (the ASCII value for 1)

That is the status quo. But I thought to compare this with another possibility:

>> to integer! "1"
== 1

>> to integer! #"1"
== 1

>> codepoint of #"1"
== 49

With this, you could imagine putting a TEXT! or a CHAR! in as input to to integer!...not knowing which type of input you had...yet either way get a result that had some kind of consistent representational meaning.

But the status quo is unlikely to ever have a useful invariant like that. Even just considering these two cases, TO INTEGER! becomes a bizarre operation. If it had a name it would be something like convert-decimal-string-to-integer-value-unless-char-in-which-case-codepoint.

No one wants that operation. So of course you see it used in cases where people already know which they have... something like to integer! my-string or to integer! my char!. All that's happening is that the short word TO is being leveraged to get a frequently used integer property.

Yet it's not even that "short" when you have to add a type onto it. As I point out with CODEPOINT OF, might there be clearer ways to say that at little or no extra cost?

 TO INTEGER!
 CODEPOINT OF  ; just one character longer... and more explanatory

If you take a look at what a difference ENBIN and DEBIN are making vs. trying to pick arbitrary TO conversions, I think it tells a similar story.

So might the TO conversions be studied in such a way that there's some actual chance that accepting multiple types as input could be an asset instead of a liability?

I think this case of TO INTEGER! of #"1" is a good talking point for that.