Re: Matlab-compatible string class

[Daniel J Sebald]

On 12/29/2017 03:31 PM, John W. Eaton wrote:
> On 12/29/2017 03:58 PM, Daniel J Sebald wrote:
> > On 12/29/2017 07:22 AM, John W. Eaton wrote:
> > > On 12/29/2017 06:41 AM, ederag wrote:
> > >
> > > > Could it be possible to expand escaped characters like \n
> > > > to '\', 'n' only in the --braindead mode ?
> > >
> > > No, we've been down that path before and we won't do it again.  It 
> > > makes it too difficult to write code that will just work if the 
> > > meaning of the language can change based on some option.  What 
> > > happens when you pass your code that requires "\n" to mean LF to 
> > > someone who uses Octave with --braindead?
> >
> > Could make such an option software settable, e.g.,
> >
> > interpconfig('-stringtype', 'escape');
> > AllMyOtherCode();
> >
> > That avoids the command-line configuration option, but interpconfig() 
> > function wouldn't be backward compatible; not the most egregious 
> > problem though.  It would be something like:
> >
> > if (compare_versions(version(), "4.4.0", ">="))
> >    interpconfig('-stringtype', 'escape');
> > end
> > AllMyOtherCode();
> >
> > That would be fairly backward compatible, I would think.
> >
> > In some sense, the above is analogous to the "tex" setting of graphics 
> > text:
> >
> > octave:45> get(get(gca,"title"), "interpreter")
> > ans = tex
> >
> > With that in mind, a alternate approach would be to add such an option 
> > to all the functions that use strings.  That is, leave the 
> > interpretation/use of the string to the very last moment.  How to 
> > display such strings at the command line (i.e., escape or non-escape) 
> > is arbitrary I suppose then, but how important that is, I don't know.
>
> No, it is no good to have some kind of option that controls this kind of 
> behavior.  It means that I can't write a function that uses a backslash 
> escape sequence unless I first ensure that it works the way I want.
>
> Really, we don't want this.  We already did this experiment with many 
> other user-configurable settings that affect the way the language works 
> and we spent literally years removing all of them.  The configuration 
> options that remain affect things like output that don't matter so much.

Here's a couple other ideas, but first it seems that no matter what one 
does here there is a backward compatibility issue.  Making the change 
will mean that there is probably lots of user-written Octave scripts out 
there using escape-strings that no longer works perfectly.  (One 
solution is a translator, which I'll come back to.)

1) This idea isn't too much different than the compatibility option. 
Have the routine eval() accept an input option "legacy", "escapestring", 
"cstylestring" that will treat all strings as escape-strings, i.e., 
C-style.  That way, if someone has some code with escape characters in 
it, s/he can still use it.  (BTW, I assume the only way to get escapes 
into new-strings will be via sprintf.)

2) Introduce a new escaped-string or C-style-string syntax using a 
character that isn't likely to be used for something else in a 
syntactical sense.  For example, currently the following (and many other 
variations) creates a syntax error:

octave:1> x = \"This is an\nescaped string.\n"
parse error:

  syntax error

>>> x = \"This is an\nescaped string.\n"
        ^

But if that syntax were to mean treat the string as C-style, then it is 
close to the current format.  Note that the above is slightly unusual 
from a language point of view because only the left-hand opening 
character has a backslash \" while the ending is sans backslash \. 
Otherwise there is no way of using \" inside the string.  For example:

octave:1> x = "This is a\nregular string.\n"
x = This is a\nregular string.\n
octave:2> x = \"This is an\n\"escape\" string.\n"
x = This is an
"escape" string.

If one wanted to retain the open/close delimiter similarity, then maybe

octave:2> x = /"This is an\n\"escape\" string.\n/"
x = This is an
"escape" string.

Or,

octave:2> x = @This is an\n\"escape\" string.\n@
x = This is an
"escape" string.

is single characters on both ends, but it is getting two far afield from 
what one normally might guess as being an string delimiter symbol.  I 
sort of like the idea of just tagging a backslash before any string to 
make it an "escape-string".

So, here's where an Octave-supplied "translator-function" comes into 
play.  It would take as input a string or file and identify any legacy 
"..." strings in the item and convert the strings to \"...".  A bit 
tricky in the sense that some parsing is required to identify what are 
truly strings as opposed to say " used in a comment, and things that are 
already \"" should not become \\"", etc.  However, editors like vim 
already accomplish these sorts of language parsings for color 
highlighting without too much hassle.

Dan