🚀 go-pugleaf

Mr. O'Keefe seems to be somewhat inconsistent with his arguments. He says

>> O'Keefe further says
>> <I have frequently used
>> <                arg(N, T, A),
>> <                !,              % now we know that N >= 1
>>
>> These are really bad arguments about the semantics of arg/3. If p/3
>> is called with an integer which is possibly zero, there is no
>> need to push the work to arg/3:
>
>Hello Mr Thought Policeman!  Yes, I *can* rewrite my code.  Why
>*should* I?  Why "push the work to" _me_?  Why is it ok to break
>code that relied on a defined property of arg/3?  Especially when
>you consider that I wrote PS/6 and sent it to the net back in 1984
>precisely to make clear what it was that I _wanted_ to be able to
>rely on?

and elsewhere he writes

> ... My favourite example is
>opening files.  If there is an operation "would I be allowed to open
>file F for operations O", then I don't need to handle errors in open/3.
>But then we run up against the need for lots and lots of "would it be
>ok to do X" predicates.
>

Now as far as I can see, the above use of arg/3 is exactly as saying
"would it be ok to call arg/3 with these arguments?". I admit that for
each predicate the border line between "this query is ok and it fails"
and "this is an error" might be subject to personal taste or
well-based theoretical considerations. For example, just recently I've
encountered a program that has something like

	p(X) :- functor(X, F, A), !, ...	% X is nonvar
	p(Var) :- ...				% when X is a variable!
	
which, in my opinion, is similar to O'Keefe's use of arg/3. Certainly,
others may have different opinions, because arity 0 or too high in arg/3
is certainly not the same type of error as a free variable in functor/3.

When we consider built-in predicates as a shorthand for (possibly infinite)
series of unit clauses, the main question to answer is how to handle
type and range errors, if any, because the call
		arg(fred, p(X), A)
just fails, although we want it to raise an exception. Consequently,
we have to introduce types into the error concept, and what these types
are can be subject of lengthy discussions. To me it seems very helpful
if arg/3 does not silently fail neither on negative numbers nor on
other numbers outside of the arity bounds. The argument that this would
break many existing programs can be answered in a way which is similar
to O'Keefe's suggestions about errors - define
	my_arg(A, B, C) :- A > 0, functor(B, F, Arity), A =< Arity.
and replace your arg/3 by my_arg/3. I still think it is not a good
programming style to rely on a certain behaviour when outside of the
arity range. Furthermore, I don't think that "I have used the feature X in my
programs and therefore it should be in the standard" is a sufficient reason.
I also think that if there is a Prolog Policeman out here, it is not me :-)

--Micha
--
E-MAIL  micha@ecrc.de            	MAIL	Micha Meier
						ECRC, Arabellastr. 17
                     				8000 Munich 81
						Germany