Bill Allombert on Wed, 24 Sep 2008 17:45:12 +0200

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: GP and syntax errors

On Thu, Sep 18, 2008 at 11:57:02AM +0200, Jeroen Demeyer wrote:
> Hello list,
> This is an issue which I already raised on the pari-users list, but I 
> repeat it here in a longer way...
> I don't like the fact that syntax errors cannot be trap()ped anymore 
> with GP's new parser.  I can certainly agree with the explanation in 
> COMPAT that syntax errors and runtime-errors are completely different. 
> But now GP basically ignores syntax errors (apart from printing an error 
> message).

The problem was that trap() was used for three or four different
purposes, and was doing none of them correctly. We are slowly fixing
that. We have just reached the point where the breakloop is actually usable.

> I have a few automatic GP scripts, i.e. scripts which run without user 
> interface (like shell scripts).  For those scripts, it is very annoying 
> that there is no easy way to check for syntax errors.

Well you can use 'gp2c -W' if you want real syntax analysis (with
unfortunately the current limitation of gp2c).

> I would like to have some way of detecting (not even handling) syntax 
> errors more easily.  I would be happy with any of the following:
> a) add syntax errors back into trap().  You could even make it such that 
> you have to explicitly specify trap(syntax, ...) and that "syntax" would 
> not be trapped by default.
> b) add a new command syntax_trap() which would behave like trap() for 
> syntax errors.
> c) have a default along the lines of quit_gp_on_error which would exit 
> gp with a non-zero exit status whenever an untrapped (syntax) error is 
> encountered.

Actually we plan to add a function iferr() to trap run-time errors
locally. At this point we could keep the function trap() as a global event
handler only:

Old                 -> New
trap()              -> default(breakloop,1)
trap({err},rec,code)-> iferr(code,rec,{err})
trap({err},rec)     -> trap({err},rec)

So far we are not completly clear on the iferr() interface and
implementation. See bug #329 for some ideas.