Design #473: Multiline string literals - useful or obsolescent? - CoCoA-5 - CoCoA Project

Design #473

Multiline string literals - useful or obsolescent?

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

Status:

Closed

Priority:

Normal

Assignee:

John Abbott

Category:

Parser/Interpreter

Target version:

CoCoA-5.1.0 Easter14

Start date:

13 Mar 2014

Due date:

% Done:

100%

Estimated time:

5.00 h

Spent time:

4.00 h

Description

For the same reasons I do not like multiline comments, I have grave doubts about multiline string literals. They seem to be "useless" -- we never use them!

Related issues

History

#1 Updated by John Abbott about 10 years ago

We could define juxtaposition of normal string literals to mean concatenation with a newline inserted between the two strings. To my eye there is no significant difference in readability.

So instead of

str := """abc
def
ghi""";

we could get the same result writing

str := "abc" "def" "ghi";

NB the 3 literals abc def and ghi should be on separate lines, but there's an irritating bug in redmine which eats the whole post except for def

#2 Updated by John Abbott about 10 years ago

My suggestion about juxtaposition of string literals is not backward compatible because juxtaposition is already defined to be simple concatenation (I didn't know that!!).

I think the current defn is not very useful since the + operator also effects simple concatenation. There may be a technical difference: it could be that the parser effects the concatenation of juxtaposed string literals whereas the + operator is surely effected by the interpreter.

NOTE 20140318 Anna tells me that I insisted on concatenation of juxtaposed string literals when we were designing CoCoA-5; it seems I've changed my mind in the meantime! :-)

#3 Updated by John Abbott about 10 years ago

Status changed from New to In Progress
% Done changed from 0 to 10

The source code relating to the recognition of string literals is in Lexer.C:423--511

Token Lexer::getStringLiteral(const CharPointer &begin, const ParserNS::ParserStatus &ps)

The fn above acquires the entire string literal (with appropriate checks for matching delimiters).

#4 Updated by John Abbott about 10 years ago

Our options are:

remove all code related to multiline string literals
comment out all code related to multiline string literals
leave the code as is but remove all references from the C5 documentation
keep multiline strings as an integral part of C5

If I recall well, Anna insisted on multiline strings because that's how the on-line manual in C4 was implemented (and she wanted it to be easy to reflow text). However, the on-line manual in C5 is handled by C++ code, so there is no longer any special need for multiline strings.

My preference is for (1); we could go there "softly" via (2). I think (3) is slightly risky: someone who accidentally types three double-quotes will find C5 behaving in a strange(=undocumented) manner.

Option (4) is probably the easiest if the C5 doc has already been written; otherwise option (3) is easiest.

Can anyone justify wanting to keep multiline string literals?

#5 Updated by John Abbott about 10 years ago

% Done changed from 10 to 30

I have made a copy of Lexer::getStringLiteral which handles only normal string literals. It is 60 lines long compared to 88 lines for the version which handles multiline string literals as well. Note also that the parts which deal with multiline literals are quite involved (= convoluted = messy = hard to comprehend).

It seems very hard to justify the overhead of this extra "convoluted" code to handle a feature that has never yet proved useful!

Comments? Opinions? Ideas?