Path: utzoo!attcan!uunet!munnari.oz.au!goanna!ok
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.lang.prolog
Subject: Re: Standards question: behavior of arg/3
Message-ID: <4054@goanna.cs.rmit.oz.au>
Date: 23 Oct 90 07:34:04 GMT
References: <9888@bunny.GTE.COM> <3992@goanna.cs.rmit.oz.au> <1920@tuvie> <35150@cup.portal.com>
Organization: Comp Sci, RMIT, Melbourne, Australia
Lines: 116

In article <35150@cup.portal.com>, pgl@cup.portal.com (Peter G Ludemann) writes:
> '==/' is IBM-Prolog-ese for not equal, treating varaibles as distinct.
> I put the ==/ inside wait:(...) so that the test will delay until
> everything is instantiated (by the way, Richard, this is all in
> the manual which I sent you).

Apology.  I knew it was in the manual.  My point was that the name was
rather opaque.  Given that \ is in the EBCDIC character set (and in fact
IBM Prolog supports the Edinburgh name \==) I don't see what the point
of replacing one opaque but at least familiar symbol by an equally
opaque but unfamiliar symbol was.  That was the point.  

> 	- Edinburgh treats functor names as special and doesn't allow
> 	  input like "f()".  For Edinburgh compatibility, arg(0,...)
> 	  should fail.

There are two distinct things here.
1.  Edinburgh Prolog data structures are copied from the usual
    presentation of terms in first-order logic.  Having the functor
    (e.g. f/3) of a term (e.g. f(a,b,c)) be part of the structure of
    the term is not the "Edinburgh" way, it's the usual way of
    describing terms in first-order logic.  PopLog makes the arity
    part of the structure, but not the function symbol, so it would
    represent f(a,b,c) by the vector #(a b c f).

2.  Edinburgh syntax does not allow f() as input.
    Changing the public-domain parser so that it WAS legal would
    require adding about two lines [wait a bit...  change the clause

    read_atom(Functor, ['('|S1], Precedence, Answer, S) :- !,
	parse(S1, 999, Arg1, S2),		% look for "," or ")"
	read_args(S2, RestArgs, S3),
	Term =.. [Functor,Arg1|RestArgs],
	exprtl0(S3, Term, Precedence, Answer, S).

    to

    read_atom(Functor, ['('|S1], Precedence, Answer, S) :- !,
	read_args_1(S1, Args, S2),
	Term =.. [Functor|Args],
	exprtl0(S2, Term, Precedence, Answer, S).

    read_args_1([')'|S1], [], S1) :- !.		% empty argument list ()
    read_args_1(S1, [Arg|Args], S3) :-		% non-empty argument list
	parse(S1, 999, Arg, S2),
	read_args(S2, Args, S3).

    ... Done!]
    This would have the effect of making f() == f, as it should be.

> 	- Prolog-II, Prolog-III, IBM-Prolog (and others?) have a more
> 	  generalized view of functors.  For example, using this view,
> 	  one could define =../2 by the infinite list of clauses: 
> 		F      =.. [F] . 	<******* NB
> 		F()    =.. [F] .	<******* NB
> 		F(A)   =.. [F,A] .
> 		F(A,B) =.. [F,A,B] .
> 			etc.

I haven't been able to try this in IBM Prolog, but in one Prolog that
I _have_ got that takes this kind of thing (the arity is part of the
structure but the function symbol is not) there were two unpleasant
effects:  first, the wretched thing didn't take the function symbol
into account when indexing (I am *not* saying that IBM Prolog doesn't,
not at all, but if you can't rely on the function symbol being _there_
it's a wee bit tricky to index on it), and second precisely this
anomaly occurred:
	f =.. X 	-> X = [f]
	f() =.. X	-> X = [f]
	T =.. [f]	-> T = f
but NOT	T =.. [f]	-> T = f()

Why do I have to keep on saying that we want our EPs to satisfy
SIMPLE laws?  Here are two laws which univ satisfies in Prologs whose
data structures are based on the usual description of terms in
first-order logic:

	if at any instant T1 =.. L1, T2 =.. L2, L1 == L2 would succeed,
	then at that instant T1 = T2 would succeed.
	"univ is an isomorphism between terms and certain lists"

	immediately after doing T1 =.. L1,
	T2 =.. L1, T2 == T1 would succeed (where T2 is a new variable) and
	T1 =.. L2, L2 == L1 would succeed (where L2 is a new variable)

The table exhibited by Ludemann does not obey these laws,
and I honestly cannot see that as an improvement.

> 	  Furthermore, a principal functor is not limited to be an atom;
> 	  it can be any term.  Using the syntax <<f(a),2,3>>, the principal
> 	  functor is itself a functor: f(a).

The functor of no term in an Edinburgh Prolog is an atom.
Functors are Atom/Arity PAIRS.  A function SYMBOL can be an atom
(or, for arity 0, a number).

Just how much of a generalisation of Edinburgh data structures is it
to allow non-atomic function symbols?  None:  it's a special case.
To get these "generalised" structures, all you have to do is confine
yourself to one function symbol, say '', and then write
	''(''(f,a),2,3)
Big deal.

Given that anything which can be done using ``improper'' terms
can be done using perfectly ordinary terms, and what is more can
be done with the same time and space bounds, and given that ``improper''
terms just never come up in the design method that I follow, and
given that ``improper'' terms do *not* correctly mimic higher-order
logic, I don't quite see the point of them.  From my own experience,
this is the kind of ``hack'' that an undergraduate feels ever so
proud of having discovered, and then realises a few years later isn't
such a good idea after all.  It just doesn't buy you anything you
can't get without it.

-- 
Fear most of all to be in error.	-- Kierkegaard, quoting Socrates.