CoCoA » CoCoA-5

If we do not allow multi-line string literals, but we do allow concatenation in the parser then the example in the description could look like:

/**/ str := "abc\n" 
[[waiting for semicolon]] /**/ "def";
/**/ len(str);
7

Or if concatenation (in the parser) were denoted by ampersand then it would look like:

/**/ str := "abc\n" &
[[waiting for semicolon]] /**/ "def";
/**/ len(str);
7

Maybe the informative prompt could even say something like [[waiting for string]] since only a string literal may follow the ampersand... could be tedious to impl.

A possible motivation for wanting to allow multi-line strings is...
CoCoA is slow at reading polynomials with many terms, but the function RingElem(P,str) is tolerably fast, so reading of large polynomials is best done via strings;
but editing files containing very long lines is often awkward (e.g. Emacs becomes very slow... not sure about vim), so it would be convenient to break the strings
into smaller pieces which are then (automatically?) reconcatenated.

Another thought: I wonder how the sum function works when given many strings to concatenate? Performance is disappointing:

N := 2000;
L := [sprint(factorial(N+i)) | i in 1..N];
t0 := CpuTime(); str := sum(L); TimeFrom(t0);
println len(str);

The above took about 5s (18Mbytes) on my computer, but increasing to N := 4000; took 120s (80Mbytes)

Maybe we need a ConcatStr function?

My original thought (that multiline string literals are not so dangerous if we have helpful prompts) is not so helpful inside a CoCoA script.
They have the same potential to be confusing as multiline comments: one may have to look arbitrarily far back before knowing whether one is reading "active" source code, a comment, or a string literal. And obviously nasty things would happen if someone incautiously closed the string literal without meaning to.

In much the same way that I prefer single-line comments over multiline comments, I think I prefer ConcatStr (or ConcatStrNewline) over a multiline string literal.

Comments, thoughts?

PS: of course, another big advantage of not allowing multiline string literals is that I do not have to delve into the interpreter.

If we do adopt the fn ConcatStr and/or ConcatStrNewline then maybe there should be a modified form of fold which produces output that can easily be made into input?

If we do make a modified form of fold, in view of KISS, I'd say that the first version does not do anything clever about escaping chars.

Here is an outline prototype in CoCoA-5 language (proper version should be in C++): prints a long string as a list of strings

define NewFold(str, opt W)
  out := OpenOString();
  width := 60; // default value
  if IsDefined(W) then width := W; endif;
  print fold(str,W) on out;
  lines := close(out);
  input := OpenIString(lines);
  out := OpenOString();
  first := true;
  print "[" on out;
  while not(IsAtEOF(input)) do
    line := GetLine(input);
    if not(first) then print ",\n" on out; else  first := false; endif;
    print "\"", line, "\"" on out;
  endwhile;
  print "]" on out;
  return close(out);
enddefine; -- NewFold

PS might want to allow 2nd arg to say how long each substring is.