>> On 29/09/2021 21:31, Bart wrote:
>>> On 29/09/2021 20:46, Stefan Ram wrote:
>>> How do you deal with the usual non-printable characters that need escape
>>> sequences such as CR, LF, TAB, BELL, etc?
>> That was my main question. AISI, if Stefan uses an escape sequence for
>> LF etc then a string's opening and closing delimiters could be escaped
>> in order to embed them.
>
> CR, LF, TAB, and BELL do not need escape sequences in my
> notation as they can be included either literally or via
> the embedding language if need be.
>
> [ a bracketed string
> can span several lines,
> and it may
> contain literal tab
> characters if need be.
> BELL signs are antecipated to be rarely needed.]
Those four may be covered but do you not need to handle any other
nonprinting characters such as backspace or del?
You may also want to have a plan for ending lines with something other
than the line endings which happen to be present in the particular
editor you are using (which is what the above text would naturally
include).
What if someone writing one of your strings wanted to include a trailing
space on one line but not another? In the above, trailing blanks would
not be evident in the source.
An escape arrangement would allow such issues to be addressed as well as
providing a way of embedding (or, de-signifying) string delimiters.
Something else to consider is where text has to be entered in lines but
the encoded text should omit the line breaks.
>
>> "abc" + LBRACKET + RBRACKET + BACKAPOSTROPHE + "def"
>
> If these strings are part of a languages with string
> concatenation operators (which is intended indeed) this
> would be possible. I plan to realize concatenation of
> strings by mere concatenation of expressions, so
> "abc\adef" could be written [abc]*BELL[def], that is
> a sequence of a string literal, a name, and another
> string literal (names would have to be marked in this
> language, I used an asterisk in this post as an example
> for a marker for a reference by name).
That's interesting. I tried the same. I found it would work especially
well and usefully for a trailing newline. In your syntax:
[abc] ;Just the three letters abc
[abc]*n ;abc and newline
>
> I decided to use []` for the closing bracket as part of the
> text, as I wrote. If I had decided to use `] for the closing
> bracket as part of the text, this would mean that a backtick
> cannot be the last character in a string. So, I could have
> used ]` instead, but using []` instead means that my strings
> always have properly nested brackets, which helps when using
> editors with functions to find matching brackets.
Understood, but AIUI your idea of having
[`
for a de-signified opening bracket would also make it hard to put such a
backtick at the /beginning/ of a string.
All told, escapes are not the worst idea in the world.
--
James Harris