Re: opinion about "strictmatch" and "compatible"

[John Cremona <john.cremona@gmail.com>]

After a 17-year deprecation period, I think your proposal makes
perfect sense.  (But will Don agree?)

John

On 7 October 2014 08:47, Karim Belabas <Karim.Belabas@math.u-bordeaux.fr> wrote:
> Dear PARI/GP users,
>
>   I recently rewrote the gp interpreter in a more modular way to support
> in a nicer way the various frontends (gp, Java/Android, emacs, TeXmacs,
> etc.) and I would like your opinion on two obscure, in my opinion
> obsolete, features. Both complicate the code (I can live with that) and
> the interfaces / documentation (which bothers me).
>
> First some background, if you're in a hurry, jump to PROPOSED CHANGES at
> the end.
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> 1) The "strictmatch" default: is 1 by default, which produces the following
>   expected behaviour
>
>   ? print(1)))); 1+1
>     ***   unused characters: print(1)))); 1+1
>     ***                              ^---
>
>   In other words, if incorrect bracing causes some characters to be
>   left over, we have a syntax error and no statement is executed.
>
>
>   If set to 0 ( strictmatch = 0 in GPRC or "default(strictmatch,0)" ),
>   we have
>
>   ? print(1)))); 1+1
>     ***   Warning: unused characters: )));1+1.
>     1
>
>   We simply discard the extra characters, issue a warning, and go on.
>   (Note that all characters are still discarded, 1+1 is not executed.)
>
>   The original intent was to allow people writing complicated 1-liners directly
>   in the gp interpreter (and not used to Lisp) to add as many closing
>   parentheses as they pleased rather than count and properly match them.
>
>   For about ten years, the conclusion of ??strictmatch has been
>   "Please do not use this; find a decent text-editor instead"
>
> This complicates the parser interface and is, in my opinion, worse than
> useless: harmful.
>
>
> 2) The "compatible" default: in 1995, Henri Cohen and I decided to
> change 70% of all GP function names, effective in gp-2.0, released in 1997.
> Although long term benefits were expected from the more consistent naming
> scheme, this certainly broke existing scripts; so I provided "compatible" as
> well as the "whatnow" mechanism.
>
> Depending on the value of "compatible", runtime errors due to
> evaluation of undefined functions, e.g. initalg(x^2+1), were handled in
> a special way if the offending function name had been present in gp-1.39.
> The original (1997) meaning was :
>
>   * compatible = 0: error but warn about the name change
>     ? initalg(x^2+1)
>       ***   at top-level: initalg(x^2+1)
>       ***                 ^--------------
>       ***   not a function in function call
>     A function with that name existed in GP-1.39.15; to run in backward
>     compatibility mode, type "default(compatible,3)", or set "compatible = 3"
>     in your GPRC file.
>
> New syntax: initalg(pol) ===> nfinit(pol)
> [...]
>   The output of "whatnow(initalg)" followed, explaining the new syntax for that
>   command.
>
>   * compatible = 1: issue a warning but otherwise accept the function. Meant
>   as a transitory help and no longer works since gp-2.5.0 (2011) and Bill's
>   rewrite of the GP parser: now treated as compatible = 0.
>
>   * compatible = 2: use the old (1997) function naming scheme, except that
>   we distinguish between uppercase / lowercase, so 'i' (unbound by default)
>   is not the same as 'I' (= sqrt(-1)).
>
>   * compatible = 3: use the old function naming scheme, do not distinguish
>   between uppercase/lowercase (e.g. 'i' is an invalid variable name: it equals
>   sqrt(-1)).
>
>
> This was certainly useful at the time, but it was meant as a one-shot
> transitory help and was never designed to provide long-term backward
> compatibility support. It has the following drawbacks:
>
>   * functions changed in subtle ways over time, possibly with different
>   input/output conventions. Compatibility only concerned the function
>   name.
>
>   * this was specific to the 1997 change, and functions continued to
>   change after that, in a less massive way (maybe 10 other functions
>   were removed), and I went on changing whatnow to indicate the current
>   name and syntax, but there's no history. I.e. no way of emulating the
>   behaviour of gp-2.3 in gp-2.7, say.
>
>   * in "compatible > 1" mode, none of the new functions are available:
>   about 250 of them since 1997...
>
>
> Personal comments:
>   * I don't think anybody was addicted to "compatible = 3". Judging from
>   feedback email in the 1993-1995 period, the impossibility to use 'i'
>   as a loop index was the No 1 pet peeve of GP users at the time.
>
>   And I have never met with a GP script written in FORTRAN 77 style :-).
>
>   * since we provide all versions of PARI/GP on our web site / ftp
>   server, full compatibility is easily obtained by running the exact
>   gp binary the script was written for.
>
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>
> PROPOSED CHANGES:
>
> 1) make strictmatch = 0 a no-op: we always have a syntax error when the
> syntax is incorrect.
>
> 2) make compatible = 1,2,3 a no-op: we always have compatible = 0
> behaviour.
>
> 3) leave whatnow() alone for the time being (so that errors still
> provide a hint about function name changes).
>
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>
> Thanks in advance for any feedback. If nobody feels strongly about this,
> I'll just go on with the changes :-)
>
> Cheers,
>
>     K.B.
> --
> Karim Belabas, IMB (UMR 5251)  Tel: (+33) (0)5 40 00 26 17
> Universite de Bordeaux         Fax: (+33) (0)5 40 00 69 50
> 351, cours de la Liberation    http://www.math.u-bordeaux1.fr/~kbelabas/
> F-33405 Talence (France)       http://pari.math.u-bordeaux1.fr/  [PARI/GP]
> `
>