Project

General

Profile

Bug #182

Unescaped double quote inside superstring

Added by John Abbott almost 12 years ago. Updated almost 10 years ago.

Status:
Closed
Priority:
Normal
Assignee:
John Abbott
Category:
Parser/Interpreter
Target version:
CoCoA-5.1.1 Seoul14
Start date:
08 Jun 2012
Due date:
% Done:

100%

Estimated time:
7.50 h
Spent time:
0.75 h

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

Related to CoCoA-5 - Design #473: Multiline string literals - useful or obsolescent?Closed2014-03-13

Related to CoCoA-5 - Design #576: Disallow juxtaposition for string literals?Closed2014-06-25

Related to CoCoA-5 - Feature #1587: Multiline string literals (again)Closed2021-04-02

History

#1 Updated by Anna Maria Bigatti about 11 years ago

  • Category set to Parser/Interpreter

#2 Updated by Anna Maria Bigatti about 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 almost 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 almost 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 almost 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 about 3 years ago

  • Related to Feature #1587: Multiline string literals (again) added

Also available in: Atom PDF