octave-maintainers
[Top][All Lists]
Advanced

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

Re: Matlab-compatible string class


From: ederag
Subject: Re: Matlab-compatible string class
Date: Sun, 31 Dec 2017 11:04:20 +0100
User-agent: KMail/4.14.10 (Linux/4.4.79-18.23-default; KDE/4.14.25; x86_64; ; )

On Friday, December 29, 2017 08:22:23 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?
> 
> jwe


OK, missed some history, I liked
https://savannah.gnu.org/bugs/?35911#comment3
but --braindead is very cosmetic now.
That solves many development headaches,
so the following it just sharing some thoughts.


Right now, in octave
numel("\t123\n")
ans =  5
makes sense
In matlab this would yield 2+3+2=7, very non-intuitive
for programmers coming from another language, isn't it ?


Another one:
strtrim(" \t1 2 3\t\n")
ans = 1 2 3

But with matlab's current implementation, this would yield the same as
strtrim(' \t1 2 3\t\n')                                                         
                                           
ans = \t1 2 3\t\n


Of course it is possible to insert an sprintf() around the string, like
strtrim(sprintf(' \t1 2 3\t\n'))
but this looks ugly.

Let's hope they think it over.
But I guess python will remain superior to matlab for string handling.
https://docs.python.org/3/reference/lexical_analysis.html#string-and-bytes-literals
especially
"": interpreted (like octave)
r"": raw (like current matlab)
not to mention the handy f"" format...

Let's say that r"" mean raw string in octave too.

One way to maintain octave's nice behavior while allowing 
to use or distribute packages compatible with matlab
would be a way to declare _files_ as "matlab braindead".
The "pkg load" or initialization script would perform the declaration.
Especially for pkg load, this would be deterministic and transparent to the 
user.

Instead of braindead, borrowing Dan's suggestion, it could be 
interpconfig({files}, '-defaultStringType', 'escape');

For these marked files, "" would be interpreted as r"" strings.

Since it affects only the interpretation of a file, 
it seems safer and easier to maintain
than the old global --braindead that is definitely discarded.

Ederag



reply via email to

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