Re: Challenges of adding octal and hexadecimal escape sequences in strings

[Jose E. Marchesi]

Hi Mohammad!

> I've added support for octal and hexadecimal escape sequences in strings.
> But there's a problem with Poke strings: they are null-terminated.
>
> Please consider the following example:
>
> ```poke
> defvar s = "a\0b";
>
> assert (s'length == 1);
> assert (s'size == 2#B);
> assert (s == "a");
> ```
>
> This behavior is IMHO annoying and counter-intuitive.
>
> The desired behavior (IMHO):
>
> ```poke
> defvar s = "a\0b";
>
> assert (s'length == 3);
> assert (s'size == 4#B);
> assert (s == "a\0b");
> assert (s + "cde" == "a\0bcde");
> ```

I don't think that is the desired behavior.  If we define Poke strings
as NULL-terminated, it is obvious they are not to contain any NULL
byte.  Now, we can achieve that by two ways:

a) By doing what we do now, i.e to ignore any part of the string after a
   NULL character, in case one is inserted, or

b) To emit an error whenever a 0 byte is attempted to be stored in a
   string value.

Supposing we wanted to switch to b), at the moment the only ways to
create a string value in Poke are:

b1) Using a string literal, and
b2) using a cast from uint<8> to string

The first case is easy to implement: just emit a compile-time error if a
string literal contains a null character.

For the second case we have two choices: either to raise an exception
when `8UB as string' is executed, or to keep the current behavior of
generating an empty string "", but the latter would be an exception to
the rule.

That's why I prefer a) to b): it is more orthogonal, and can be
explained by a single rule without needing any exceptions to the rule.
Also, it comes handy to shorten strings :D