[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Matlab-compatible string class

From: Daniel J Sebald
Subject: Re: Matlab-compatible string class
Date: Sat, 30 Dec 2017 20:27:29 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1

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');

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');

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.


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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]