On 13 Mar 2024, at 15:22, John Rose wrote:
> … OVERLOADS …
>
> I don’t see (maybe I missed it) a decisive objection to overloading across ST
> and String, at least for some processing APIs.
Perhaps it is this: A language processor API that takes STs and never Strings
is making it clear that all inputs should be properly vetted, nothing taken on
trust as a bare string.
Doing that MIGHT require a performance model which permits expensive vetting
operations to be memoized on particular OCCURRENCES of inputs (not just the
input strings viewed in and of themselves).
If that’s true, then I guess that’s support for Guy’s proposal: That STs (even
trivial ones) should never look identical to strings. Maybe they should always
be preceded by a sigil $, or (per my suggestion) they should always have at
least one occurrence of \{ inside, even if it’s a trivial nop.
I kind of like Guy’s offensive-to-everyone suggestion that $ is required to
make a true ST. Then it’s clear how the veteting APIs mate up with their
vetted inputs. And if $ is not placed in front, we surrender to the
string-pasters, but at least the resulting true-string expressions won’t be
accepted by the vetting APIs.
