Re: PARI 2.6 syntax 1: iferr/iferrname

[Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>]

On Fri, Feb 15, 2013 at 06:32:47PM +0100, Karim Belabas wrote:
> * Bill Allombert [2013-02-14 22:42]:
> [...]
> 
> I am not sure that two separate functions iferr / iferrname are useful.
> We could have a single iferr() -- corresponding to current iferrname --
> with the following syntax:

A possibility is to discriminate on the number of arguments, like 'if' do.

>   iferr("error_name"  /* (1) */
>     , /* code that may raise an exception (2) */ 
>     , /* variable E containing the error, optionnally some_predicate(E) (3) */ 
>     , /* recovery code (4) */ )
> 
> (1) "error_name" is optional. Omitting it results in current iferr()
> behaviour: trap all runtime exceptions. Otherwise only trap exceptions
> with the expected name.

In that case, we should exchange (1) and (2). We should really stick to usual
iferr convention, i.e. iferr(code, error handling code)

> (3) must contain a variable name, say E, to store the exception context
> for later manipulations.
> 
> I like the idea of being able to ascertain that the exception is the one
> we intended to catch for complicated cases (unlike your toy example
> above where the "not invertible" exception can only come from a
> t_INTMOD, making the test spurious)
> 
> But it's not that nice to impose an extra argument in the frequent case
> where the code is simple enough to *know* that an exception with the
> expected name can only come from the "right" error. I see two
> possibilities: 

I do not think this case can actually happen in correctly written code.

>  * sol. 1: "binding" the predicate to the error E: allow either 
> 
>    - a variable name, says 'E' by itself (current syntax)
>    
>    - or something like
> 
>      E | some_predicate(E)
> 
>    [ to be read "E such that..." ] Probably impossible without 
>    introducing yet another argument code. You tell us :-)

This requires changing the parser so that A | B is a valid syntax, which
is rather painful.

>  * sol. 2: having two functions, the simple iferr(), with just a variable name,
>    and a more complicated iferrtest(), say, with an extra argument
>    corresponding to a predicate E must satisfy in order for us to catch
>    this particular exception. This seems very easy to implement, without 
>    introducing a new argument code.

Or alternatively allowing a last optional argument to iferr.
i.e. allowing both

iferrtest("e_DOMAIN", exp(-tan(x)^2)
  , E
  , my([f,v,op,lim,x] = Vec(E)); f=="tan" && lim=="Pi/2 + kPi"
  , 0);

and

iferrtest("e_DOMAIN", exp(-tan(x)^2)
  , E, 
    my([f,v,op,lim,x] = Vec(E)); 
    if(f=="tan" && lim=="Pi/2 + kPi"
     , 0
     , error(E)))

Cheers,
Bill.