Re: opinion about "strictmatch" and "compatible"

Charles Greathouse
Analyst/Programmer
Case Western Reserve University

On Tue, Oct 7, 2014 at 3:47 AM, 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]
`