From jan@swi.psy.uva.nl Fri Oct 26 16:09:14 2001
Received: from gollem.swi.psy.uva.nl (root@gollem [145.18.152.30])
	by swi.psy.uva.nl (8.11.2/8.11.2) with ESMTP id f9QE9Et25805;
	Fri, 26 Oct 2001 16:09:14 +0200 (MET DST)
Received: from localhost (localhost [[UNIX: localhost]])
	by gollem.swi.psy.uva.nl (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) id f9QE9EG17773;
	Fri, 26 Oct 2001 16:09:14 +0200
From: Jan Wielemaker <jan@swi.psy.uva.nl>
Organization: SWI, University of Amsterdam
To: Paul Singleton <paul.singleton@bcs.org.uk>, prolog@swi.psy.uva.nl
Subject: Re: [SWIPL] Type error vs. silent failure
Date: Fri, 26 Oct 2001 15:51:58 +0200
X-Mailer: KMail [version 1.0.29.2]
Content-Type: text/plain
References: <200110261101.f9QB1Pl12948@gollem.swi.psy.uva.nl> <3BD95E8E.5040202@bcs.org.uk>
In-Reply-To: <3BD95E8E.5040202@bcs.org.uk>
MIME-Version: 1.0
Message-Id: <01102616091403.08005@gollem>
Content-Transfer-Encoding: 8bit

On Fri, 26 Oct 2001, Paul Singleton wrote:
>Jan Wielemaker wrote:
>
>> Only in some really performance-critical situations I sometimes estimate
>> whether using catch/3 or checking is more efficient.  Note that catch/3
>> is not cheap for many reasons.  The call is a meta-call, you have to
>> push the goal, template and recovery onto the stack and if an exception
>> happens another expensive unwinding and meta-call must take place.
>
>
>Please reassure us that the "exception doesn't happen" cost is nothing
>to be afraid of :-)

You'll be off slighly worse than call/1, much depending on the size of
the terms you pass as arguments.  Bart Demoen has done some timings that
indicate SWI-Prolog is quite ok general on catch/3 and even good at
handling an exception if it gets that far.

>If not, is it inherently expensive, or could it e.g. be compiled as a
>special case?

I guess it could be better by compiling especially the first argument.
If you are prepared to pay a significant price in development effort and
recovery performance normal execution could be as fast as without
catch/3.

Especially if the first argument is not a control-construct
(,/2, ;/2, etc.) and there is some real work done it is unlikely that
catch/3 has major impact on the performance.  Just try to avoid it
doing very simple tasks (e.g. catch(arg(I,T,A), ...)).

>> Next is coding:
>> 	
>> 	catch(nth1(N, List, E), error(type_error(_), _), fail)
>> 
>> isn't really pretty, but 
>> 
>> 	catch(nth1(N, List, E), _, fail).
>> 
>> May give some undesired results.  Maybe nth1/3 isn't around and your
>> goal now fails silently rather then with an error.  Maybe the system
>> runs out of stack, but this code will silently fail!
>
>Java pragmatically distinguishes "checked" and "unchecked" exceptions,
>then imposes static checking on checked exceptions (must be either
>handled or explicitly declared to be possibly thrown).  Is it feasible
>to do such static checking on (some practically useful subset of)
>ISO or SWI Prolog?

Guess so, though I wouldn't know how useful it would be.  I can't say
I've ever felt a need for it.  It would be great to have a good static
checker for SWI-Prolog using as much as possible of its extensions.  If
you are using modules the one inside PceEmacs is doing an increasingly
good job, but still has more then enough opportunities for improvements.

>Paul Singleton
>
>PS I am not suggesting that it must be a good idea because Java does 
>it, but that software engineering issues like this are essentially
>pragmatic, not theological, 

I always though language choice is pretty close to theology :-)

	--- Jan

