Bug #182
Unescaped double quote inside superstring
Description
The parser goes into a strange state if an unescaped double quote character is found inside a superstring. It correctly reports an error, but then seems still to be inside the superstring.
# """abc"def"""; ERROR: Expected a double-quote character; you've either forgotten a backslash to escape this quote, or two double quote characters to end the multi-line string literal """abc"def"""; ^ ... ; #
Decide what the correct behaviour should be, and implement it.
Related issues
History
#1
Updated by Anna Maria Bigatti over 11 years ago
- Category set to Parser/Interpreter
#2
Updated by Anna Maria Bigatti over 10 years ago
- Target version set to CoCoA-5.1.0 Easter14
#3
Updated by John Abbott about 10 years ago
- Target version changed from CoCoA-5.1.0 Easter14 to CoCoA-5.1.1 Seoul14
#4
Updated by John Abbott about 10 years ago
- Status changed from New to In Progress
If I recall correctly, we abolished "superstrings" in CoCoA-5.1. So the problem is no longer relevant. In any case, the behaviour now is different:
>>> """abc"def"""; --> ERROR: Unexpected identifier, are you forgetting a "*" or a ";" ? --> """abc"def"""; --> ^^^
The interpreter sees the input as ""
(empty literal) followed by "abc"
followed by the identifier def
.
I continue to have doubts about the wisdom of allowing juxtaposed string literals; I wonder if we ever documented why we wanted it? If we disallow juxtaposition, then the error will be signalled at the third "
, which is probably more helpful to the user.
#5
Updated by John Abbott about 10 years ago
- % Done changed from 0 to 50
I have (temporarily?) disabled recognition of juxtaposed strings. The resulting behaviour on the example input is:
>>> """abc"def"""; --> ERROR: Expecting an operator, or a semicolon to end the statement --> """abc"def"""; --> ^^^^^
I think this is sufficiently clear and helpful.
#6
Updated by John Abbott about 10 years ago
- Status changed from In Progress to Closed
- Assignee set to John Abbott
- % Done changed from 50 to 100
This bug essentially vanished when we abolished multiline string literals.
Now that juxtaposed strings literals are being abolished, I think the overall behaviour is fine.
So closing.
#7
Updated by John Abbott over 3 years ago
- Related to Feature #1587: Multiline string literals (again) added