|Bill Allombert on Fri, 22 Feb 2013 22:39:38 +0100|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
|Re: PARI 2.6 syntax 1: iferr/iferrname|
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.