Compile-file: non-similarity of strings with cr/lf

Logged In: YES
user_id=5735

relevant links:
https://sourceforge.net/tracker/index.php?func=detail&aid=731952&group_id=1355&atid=351355
http://clisp.cons.org/impnotes/clhs-newline.html
proposed solution: add faithful newline i/o,
via a new encoding facet binary-newline or something like that

Logged In: YES
user_id=5923
Originator: NO

The faithful newline i/o introduces additional problems.

What we need is a solution such that
- .fas files are plain text file that can be edited with a text editor,
- .fas files can be edited and resaved with a different line-terminator
convention, without changing their semantics,
- .fas files can be concatenated to produce an executable script;
it should even be possible to concatenate Unix .fas files with DOS .fas
files.

The simplest solution is to ignore the newlines when reading .fas files.
This requires a different string representation where all #\Return and
#\Linefeed are explicit. I.e. instead of

"multiline
string"

we write

#0Y"multiline\n
string"

The escape sequences \n and \r are well-known from C and Java, \n also
from Unix 'sed'.

Such a solution has been implemented on 2006-11-20 for strings, by introducing a
#0Y"..." syntax. If you care about symbol or package names that contain CR characters
you can do the same with a #0Y|...|::|...| syntax.

Logged In: YES
user_id=5735
Originator: NO

>If you care about symbol or package names
>that contain CR characters
>you can do the same with a #0Y|...|::|...| syntax.

yes, please.

Logged In: YES
user_id=5735
Originator: NO

#0Y|...|::|...| syntax is already used for stream encoding.
how about always quoting all CR/LF in all strings/symbols/package prefixes in compiled files?

Logged In: YES
user_id=5735
Originator: NO

I don't like the extra #0Y, especially because deciding whether to print it requires pre-scanning symbols and strings.
maybe we could detect that the i/o is dealing with a FAS files and branch on that?

Logged In: YES
user_id=5735
Originator: NO

another issue is that
(let ((*print-readably* t)) (prin1-to-string (string #\return)))
==> "#0Y\"\\r\""
is not ANSI-compliant.
here we are really stuck because we use CL printer to write FAS files.
I think we should drop #0Y for strings altogether and always use \n and \r when doing FAS i/o.
to detect whether we are doing FAS i/o, I think we need to add a #0Y code to the beginning of fas files, similar to the encoding.

Logged In: YES
user_id=5735
Originator: NO

we already have strmflags_reval_B which overrides *read-eval* and whose (only?) raison d'etre is for FAS files.
I propose we rename it to strmflags_fas_B and use it instead of *compiling* and #0Y"" in io.d.

Logged In: YES
user_id=5735
Originator: NO

thank you for your bug report.
the bug has been fixed in the CVS tree.
you can either wait for the next release (recommended)
or check out the current CVS tree (see http://clisp.cons.org\)
and build CLISP from the sources (be advised that between
releases the CVS tree is very unstable and may not even build
on your platform).