On 06-May-2002, Cristian Diaconu <[EMAIL PROTECTED]> wrote:
> On Tue, 7 May 2002 00:05:25 +1000, Fergus Henderson <[EMAIL PROTECTED]> wrote:
>
> >Since the CLR lacks any direct support for Prolog-style backtracking,
> >logic programming language implementations for the CLR need to emulate
> >it somehow. The best way to do this, IMHO, is to generate code that
> >uses a continuation-passing style, as explained in the two papers that
> >I posted references to earlier. In particular, this means using the
> >CLR's exception-handling support to implement commits ("cuts", in Prolog
> >terminology). Commits are not exceptional, and may occur with reasonably
> >high frequency for certain styles of logic programming.
> >
> >If you know of an efficient way to implement Prolog-style backtracking
> >and commits on the CLR, without using exception handling, then I would
> >very much like to know about it.
> >
> >If you do not, then I hope you would concede that the design of a
> >virtual machine which aims to efficiently support a wide variety
> >of languages should not ignore the efficiency of throwing exceptions.
>
> Thank you for your input. This sounds like a well reasoned argument -
> exactly the type I was hoping for in fact - and I have to admit my
> ignorance in the matter. However, I will take a look at the papers you
> mention and try to see how an implementation might work w/ CLR and whether
> it seems to require continuation as provided by the CLR.
>
> I 100% agree that a language construct such as the one you describe is the
> perfect argument for adding what would otherwise seem (IMHO) an overly
> intrusive feature.
I was just arguing that it is sometimes reasonable to use exceptions for
non-exceptional purposes on the CLR. I wasn't trying to draw any conclusions
from that about what features the CLR should or should not have.
Note that my argument is in fact an argument *against* the feature
originally mentioned in the subject line (the double-pass
exception semantics). For Mercury, we only make use of the usual
C++/Java/etc. style of exception handling, but we need to use exceptions
in non-exceptional conditions (for commits), so we want them to be fast.
That means that for Mercury we'd rather the target platform provide an
exception handling mechanism that *doesn't* include support for resumption,
because then the underlying implementation could implement exceptions
more efficiently.
However, I think the decision to support the Win32-style exception
handling model in the CLR was not unreasonable, given that the CLR
was intended to support a variety of languages. VB is not the only
language which uses an exception handling model that supports resumption.
--
Fergus Henderson <[EMAIL PROTECTED]> | "I have always known that the pursuit
The University of Melbourne | of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
