🚀 go-pugleaf

In article <24861@pasteur.Berkeley.EDU> stolcke@icsi.Berkeley.EDU (Andreas Stolcke) writes:
>In article <189@qt.cs.utexas.edu>, bradley@cs.utexas.edu (Bradley L.
>Richards) writes:
>|> for "efficiency" reasons, most Prolog implementations
>|> omit the "occurs" check (i.e. here Y appears in foo(Y)), and blindly
>|> unify these terms.  This is, in fact, an error--
>
>Quoting from the C-Prolog User's manual, edited by Fernando Pereira, 1984:
>
>                The absence of the occur check  is   not   a   bug   or
>           design   oversight,   but   a  conscious   design  decision.
>           In   any   practical    programming
>           language,   basic  operations  are supposed to take constant
>           time.  Unification  against a variable should be thought  of
>           as the basic operation of Prolog, but this can take constant
>           time only if the occur check is omitted.
>
>I'd say that the above argument against the occur check sound
>pretty reasonable.

I think "conscious design decision" is the key phrase here.  IMHO, a decision
to improve efficiency at the expense of correctness is a poor decision.  It's
much like the thread on this group about integer overflow--omitting checks for
integer overflow for the sake of efficiency is foolish (as an *option* it's
ok, but as a *default* it's nuts).

The same thing with the occurs check.  What definition of "practical" are
we using here?  Is a language that produces erroneous results "practical"?
Again, for optimization after code has been thoroughly tested and debugged,
we might want to turn off some of the safety checks.  But as a standard way
of doing business, omitting the occurs check is simply wrong.

---------------------------------------------------------------------------
 Bradley L. Richards       uucp:  cs.utexas.edu!bradley
 bradley@cs.utexas.edu     CompuServe:  75216,1744
---------------------------------------------------------------------------