Project

General

Profile

Feature #1431

Juxtaposition of string literals

Added by John Abbott about 4 years ago. Updated over 2 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
Category:
CoCoA-5 function: new
Target version:
Start date:
03 Mar 2020
Due date:
% Done:

100%

Estimated time:
1.99 h
Spent time:

Description

We used to allow this, but then disallowed it in issue #576.

I raise it again because Martin Kreuzer wants to have some old CoCoA-4 packages transferred to CoCoA-5.
Those old packages tended to have a function called Man which printed out a very long, multi-line string.
This can be seen in the revitalized package thmproving.

Juxtaposing strings may help here. Discuss!

Reactivation appears to be a trivial matter of uncommenting the commented out code.


Related issues

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

Related to CoCoA-5 - Feature #781: Option to "fold" long lines?Closed2015-09-28

Related to CoCoA-5 - Slug #1363: Emacs UI: slow with long linesIn Progress2019-11-13

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

Related to CoCoA-5 - Feature #1599: ConcatStrClosed2021-06-12

History

#1 Updated by John Abbott about 4 years ago

The soln in thmproving.cpkg5 was to have a long succession of PrintLn commands:

  PrintLn "DESCRIPTION";
  PrintLn "";
  PrintLn "Given a putative theorem in Euclidean geometry, we introduce Cartesian";
  PrintLn "coordinates in the Euclidean plane, and translate the hypotheses and the...";

But in CoCoA-4 it was permitted to have newlines inside strings (more a curse than a mixed blessing).
With concatenation by juxtaposition, we could have something like:

  PrintLn "DESCRIPTION\n" 
          "\n" 
          "Given a putative theorem in Euclidean geometry, we introduce Cartesian\n" 
          "coordinates in the Euclidean plane, and translate the hypotheses and the...";

Is this a good idea?

I did also on one occasion actually want to have a long string literal... forgotten precisely why.
UPDATE I think I wanted to read in a large polynomial (e.g. 1Mbyte long), and it was inconvenient in Emacs to have such a long line (because Emacs becomes slow with long lines).

#2 Updated by John Abbott about 4 years ago

  • Related to Design #576: Disallow juxtaposition for string literals? added

#3 Updated by John Abbott about 4 years ago

The relevant source code is around line 2100 in Parser.C, in the function Parser::parsePrimary.

#4 Updated by John Abbott about 4 years ago

  • Related to Feature #781: Option to "fold" long lines? added

#5 Updated by John Abbott about 4 years ago

  • Related to Slug #1363: Emacs UI: slow with long lines added

#6 Updated by John Abbott about 3 years ago

Another possible justification for wanting to re-allow string literal juxtaposition is that we now have a fold function which can break a long string into pieces separated by newlines. The juxtaposition trick would make it easier to read in such a split string.

Why did I write in comment 1 that this is a "curse"? What problems does it cause?
I suppose a user could make the mistake to forget a comma after a string literal in a list of string literals then CoCoA will silently concatenate the literals.
Here is an example:

L := ["one" "two", "three"];

Or maybe string literal concatenation could be achieved by a special operator symbol? If so, what? (maybe &, ampersand)

Comments, ideas, suggestions?

#7 Updated by John Abbott about 3 years ago

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

#8 Updated by John Abbott about 3 years ago

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

A potential disadvantage of something like "abc"+"def"+"ghi" is that a naive impl will take quadratic time. I suppose we could do geobuckets for string concatenation ;-)

The example in comment 6 with a "typo" (missing comma) does rather discourage allowing juxtaposition (but several other computer languages allow it, presumably without causing too much trouble for new programmers). Requiring an explicit operator would avoid that problem, but does involve delving to the parser... mmmm.

We could re-enable multi-line string literals... I'll create a new issue (#1587) to discuss this

#9 Updated by John Abbott about 3 years ago

  • Assignee set to John Abbott

I have just looked at the source code (Parser.C around lines 2135--2150); the old code for juxtaposed strings is still there. I do not really understand how it worked.
Presumably the interpreter knows how to "read" what the parser produced (see Interpreter.C around line 3250; search for stringliteral).

As suggested in #1587#note-5 I have implemented a new fn ConcatStr (not sure that that name is the best).
Repeating the example given in that note, but using ConcatStr instead of sum took about 0.12s; so about 1000 times faster.
That is acceptably fast.

An advantage of a fn such as ConcatStr is that it can be called on lists created at run-time, in contrast to a "smart" way of concatenating string literals.

#10 Updated by John Abbott about 3 years ago

Another point in favour of ConcatStr is that it could insert newlines between the strings in a list, rather than requiring that the user put in \n explicitly at the end of each string.

println "First line\n" 
        "second line\n"  "last line";

println ConcatStrWithNewlines(
    [ "First line",
      "second line", "last line"]);

#11 Updated by John Abbott almost 3 years ago

#12 Updated by John Abbott over 2 years ago

  • Status changed from In Progress to Rejected
  • % Done changed from 10 to 100
  • Estimated time set to 1.99 h

Given the example in comment 6 (above), and the fact that ConcatStrings is now quite fast. We have decided to reject this issue.

Also available in: Atom PDF