Re: Escape sequences in *printf family of functions

[John W. Eaton]

On  5-Apr-2012, Rik wrote:

| I think the decision is whether to follow Matlab's kludge for the sake of
| compatibility or to separate the behaviors.  One mode would be consistent
| and specific to Octave.  In this mode, single quotes are used for verbatim
| input and escape sequences are not processed; Double quotes are used to
| indicate that escape processing is desired.  This is self-consistent and
| the pattern that all UNIX shells follow.  I have a strong, but personal,
| preference for coding in that manner because I can guarantee, without
| reading the documentation for each function, that I will get out what I
| program in.
| 
| The second mode would chase Matlab compatibility.  Once you decide to be
| inconsistent with single and double quotes then you need another standard
| to decide which functions should implement it and which should not.  Since
| flipping a coin on a per function basis isn't a great standard, we might as
| well follow the whimsy of Matlab and use the same list of functions they
| do.  I don't have a complete list but I have found the following are
| affected: the template strings of printf(), sprintf(), fprintf(), the
| pattern strings of regexp(), regexpi(), the pattern and replacement strings
| of regexprep(), the message strings of error(), warning().
| 
| If we do go whole hog, and just implement Matlab compatibility, then we
| should update the documentation to clearly point out the surprises that can
| happen and direct users to regexptranslate() for translating strings to
| escaped versions.

I don't want to see us have different modes for compatibility
controlled by either command-line arguments or internal settings.

We used to have lots of preferences like this that controlled syntax
and semantics.  It seemed like a good idea at the time, but turned out
to be a horrible disaster because you have to do a lot of extra work
if you want your code to work no matter what the user preferences are.

We ended up with a lot of code that did things like this:

  sqep = single_quote_escape_processing ();
  unwind_protect
    single_quote_escape_processing (true);
    ...
  unwind_protect_cleanup
    single_quote_escape_processing (sqep);
  end_unwind_protect

This quickly becomes unmanageable, and code breaks any time a new
preference is added.

It took a long time and a lot of effort to undo the mistake I made in
introducing these kinds of settings and I don't want to repeat that
mistake now.

With the exception of allow_noninteger_range_as_index and
do_braindead_shortcircuit_evaluation, the options that remain with
--traditional are really quite superficial.  And I'm not sure why we
have allow_noninteger_range_as_index and
do_braindead_shortcircuit_evaluation.  It seems to me that warnings
would be sufficient for those.  And we already do have a warning for
Matlab-style short-circuit evaluation for | and &, so it seems to me
that it would make sense to always enable that feature and just keep
the warning on by default except when using --traditional.

Even if you make the setting "local", you are really just temporarily
setting the global value.  For example,

  octave> function f ()
  > missing_function_hook ("foo", "local");
  > missing_function_hook ()
  > g ()
  > end
  octave> function g ()
  > missing_function_hook ()
  > end
  octave> g
  ans = unimplemented
  octave> f
  ans = foo
  ans = foo
  octave> missing_function_hook 
  ans = unimplemented

So all functions must be prepared to handle all possible preference
settings.

Further complicating the language with "function local" settings or
similar things is not appealing to me either.

I'd prefer it if we just have single-quoted strings behave in a
way that is compatible with Matlab.  I know it is inconsistent and
ugly, but I think making the behavior optional is worse.

jwe