Guile docstrings---should Guile code be ANSI C compatible?

[Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>]

(Again I'm forced to bring things up which could be interpreted as
 implicit criticism of Greg's work: Let me just repeat that I like
 his work a lot, and think it is important.)

Guile's current docstrings are not compatible with ANSI C.

"In ANSI C, string literals are not allowed to continue past newlines
like this, but this is how Guile's docstrings look like now."

"ANSI C requires that newlines are included explicitly\n\
like that."

(The last \ just says that the two lines should be interpreted as one
line.)

Until now we have followed the rule that Guile code should be ANSI C
compatible.  Since the code in the current repository isn't compatible
with regard to docstrings, it can't be compiled on all ANSI C
compilers.

We now have two alternatives:

1. (Greg's suggestion) Making an exception to the rule about ANSI C
   compliance and using a script which transforms the code in the
   .x-files into ANSI compilant source using a script:

   #!/usr/bin/perl -pwi.bak
   BEGIN { $backslashing = 0; }
   
   if (/^SCM_DEFINE/) { $backslashing = 1; next }
   
   if (/^\#define FUNC_NAME/) { $backslashing = 0; next }
   
   if ($backslashing && (m/^\S/ || m/^\s*$/)) {
     s/$/\\n\\/ unless (m/\"\s*\)\s*$/ || m/\\$/);
   }

2. (I could do this if this choice is selected) Putting in \n\ at the
   end of lines in multiline docstrings to make it ANSI C compatible.

I guess the main point speaking for 1 is that since gcc *allows* a
newline in strings, people will easily forget the \n\ so that Guile
code breaks on other compilers.

The main point speaking for 2 is that the code will be standard C.

Maciej, could you please make a decision which route we should take.

/mdj