I have the following ideas for string literals in a new language
(first the string, then the string literal is given):
String literals start with an opening bracket and end with
a closing bracket.
abc
[abc]
Brackets within the string literal are allowed when properly
nested.
abc[def]ghi
[abc[def]gih]
A single opening or closing bracket is written as "[`]" or
"[]`", respectively. This rule has higher precedence than the
preceding rule: whenever there is a "[`]" or "[]`" within
a string literal, it means "[" and "]", with no exceptions.
abc[def
[abc[`]def]
abc]def
[abc[]`def]
abc[`]def
[abc[`]`[]`def]
abc[]`def
[abc[`][]``def]
The notation for "[`]" and "[]`" within a string is awkward,
but is antecipated to be required only rarely. Most texts will
contain brackets that are properly nested, and this was made
to be easy.
So, are there any problems with this specification I have missed?
Strings that are impossible to encode or string literals whose
interpretation is ambiguous? Cases where frequent strings are
cumbersome to encode? TIA!
On 29/09/2021 20:46, Stefan Ram wrote:
I have the following ideas for string literals in a new language
(first the string, then the string literal is given):
String literals start with an opening bracket and end with
a closing bracket.
abc
[abc]
Brackets within the string literal are allowed when properly
nested.
abc[def]ghi
[abc[def]gih]
A single opening or closing bracket is written as "[`]" or
"[]`", respectively. This rule has higher precedence than the
preceding rule: whenever there is a "[`]" or "[]`" within
a string literal, it means "[" and "]", with no exceptions.
abc[def
[abc[`]def]
abc]def
[abc[]`def]
abc[`]def
[abc[`]`[]`def]
abc[]`def
[abc[`][]``def]
The notation for "[`]" and "[]`" within a string is awkward,
but is antecipated to be required only rarely. Most texts will
contain brackets that are properly nested, and this was made
to be easy.
So, are there any problems with this specification I have missed?
Strings that are impossible to encode or string literals whose
interpretation is ambiguous? Cases where frequent strings are
cumbersome to encode? TIA!
I don't know if some strings are impossible to code. But it looks near-impossible to write or read any strings that contain square
brackets or single quotes.
How do you deal with the usual non-printable characters that need escape sequences such as CR, LF, TAB, BELL, etc?
With the usual "..." delimiters, your examples reduce to:
abc
"abc"
abc"def"ghi
"abc""def""ghi" # or the more common:
"abc\"def\"ghi" # (I allow both)
I'm not sure how you came up with these puzzling 3-character sequences:
[ [`]
] []`
If introducing ` as some sort of escape symbol, why not have it precede
the escaped character:
[ `[
] `]
Your examples, if still using [..] to delimit strings, and allowing
embedded ...[...]... without needing escapes, become:
abc[def]ghi
[abc[def]gih]
abc[def
[abc`[def]
abc]def
[abc`]def]
abc[`]def
[abc[``]def]
abc[]`def
[abc[]``def]
Here it needs `` to represent one `.
I have the following ideas for string literals in a new language
(first the string, then the string literal is given):
String literals start with an opening bracket and end with
a closing bracket.
On 29/09/2021 21:31, Bart wrote:
On 29/09/2021 20:46, Stefan Ram wrote:That was my main question. AISI, if Stefan uses an escape sequence for
How do you deal with the usual non-printable characters that need escape >>sequences such as CR, LF, TAB, BELL, etc?
LF etc then a string's opening and closing delimiters could be escaped
in order to embed them.
"abc" + LBRACKET + RBRACKET + BACKAPOSTROPHE + "def"
James Harris <james.harris.1@gmail.com> writes:
On 29/09/2021 21:31, Bart wrote:
On 29/09/2021 20:46, Stefan Ram wrote:That was my main question. AISI, if Stefan uses an escape sequence for
How do you deal with the usual non-printable characters that need escape >>> sequences such as CR, LF, TAB, BELL, etc?
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.]
"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).
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.
James Harris <james.harris.1@gmail.com> writes:
On 29/09/2021 21:31, Bart wrote:
On 29/09/2021 20:46, Stefan Ram wrote:That was my main question. AISI, if Stefan uses an escape sequence for
How do you deal with the usual non-printable characters that need escape >>> sequences such as CR, LF, TAB, BELL, etc?
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.]
"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 have the following ideas for string literals in a new language
(first the string, then the string literal is given):
String literals start with an opening bracket and end with
a closing bracket.
abc
[abc]
Brackets within the string literal are allowed when properly
nested.
abc[def]ghi
[abc[def]gih]
A single opening or closing bracket is written as "[`]" or
"[]`", respectively. This rule has higher precedence than the
preceding rule: whenever there is a "[`]" or "[]`" within
a string literal, it means "[" and "]", with no exceptions.
abc[def
[abc[`]def]
abc]def
[abc[]`def]
abc[`]def
[abc[`]`[]`def]
abc[]`def
[abc[`][]``def]
The notation for "[`]" and "[]`" within a string is awkward,
but is antecipated to be required only rarely. Most texts will
contain brackets that are properly nested, and this was made
to be easy.
So, are there any problems with this specification I have missed?
Strings that are impossible to encode or string literals whose
interpretation is ambiguous? Cases where frequent strings are
cumbersome to encode? TIA!
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 296 |
Nodes: | 16 (2 / 14) |
Uptime: | 71:03:07 |
Calls: | 6,656 |
Calls today: | 2 |
Files: | 12,201 |
Messages: | 5,332,212 |
Posted today: | 1 |