From post@volker-wysk.de Mon Nov  5 03:33:25 2001
Received: from volker (mail@dsl-213-023-043-036.arcor-ip.net [213.23.43.36])
	by swi.psy.uva.nl (8.11.2/8.11.2) with ESMTP id fA52XOt16561;
	Mon, 5 Nov 2001 03:33:24 +0100 (MET)
Received: from localhost ([127.0.0.1] ident=v)
	by volker with esmtp (Exim 3.22 #1 (Debian))
	id 160ZYt-0000Zo-00; Mon, 05 Nov 2001 03:32:31 +0100
Date: Mon, 5 Nov 2001 03:32:31 +0100 (CET)
From: Volker Wysk <post@volker-wysk.de>
X-X-Sender:  <v@volker>
To: Jan Wielemaker <jan@swi.psy.uva.nl>
cc: Volker Wysk <post@volker-wysk.de>, <prolog@swi.psy.uva.nl>
Subject: Re: [SWIPL] no copy semantics for PlTerm, in the C++ interface
In-Reply-To: <200111041308.fA4D83802468@gollem.swi.psy.uva.nl>
Message-ID: <Pine.LNX.4.31.0111050238520.2098-100000@volker>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Sun, 4 Nov 2001, Jan Wielemaker wrote:

> > The class PlTerm in the C++ interface, SWI-cpp.h, contains this:
> >
> >   int operator =(const PlTerm &t2)	/* term */
> >   { return PL_unify(ref, t2.ref);
> >   }
> >
> > This is not correct copy semantics. You can't overwrite a PlTerm
> > object. You can't use PlTerm objects as values like this. For
> > instance, the Standard Template Library relies on correct copy
> > semantics. You couldn't store PlTerm's in STL containers, etc.
> >
> > I suggest renaming the operator=() methods to unify().
>
> I never claimed to be a C++ expert.  = has been redefined to allow
> natural unification from C++.  I guess you'd like to see
>
>    int operator =(const PlTerm &t2)	/* term */
>    { return PL_put_term(ref, t2.ref);
>    }

I'm a little confused now. As far as I can tell from the SWI-Prolog
documentation, we have
- Terms inside the Prolog machine
- pointers inside Prolog to terms (= variable bindings?)
- corresponding term_t values on the C side
- PlTerm objects

PlTerm objects are lightweight, and it makes perfect sense to use them as
values (you wouldn't want allocate them on the heap). In order to do this,
they must behave like values, or unforeseen things will happen. So an
assignment must make two objects identical. I'm not sure if this is
completely guaranteed after the PL_put_term() operation.

I'd just do "ref = t2.ref;" instead of the call to PL_put_term. This is
what the default assignment operator would do. So you could just leave
away the operator= method.

Also, the return type isn't right; it needs to be PlTerm&. For instance,
for statements like this: if ((term1 = term2) > term3) { ...

> I think I agree to your proposal, also because = is a bit strange
> and leads to
>
> 	return X = Y;
>
> rather then the possibly someway clearer:
>
> 	return X.unify(Y);
>
> Big problem is that there is a lot of code around that will break
> if we change this.

I think, the assignment behavior should be changed. The way it is now, it
can be a great source of errors. It's just too obvious to use PlTerm
objects as values, like you would use pointers.

There are more things that could be improved. For instance, I found it
confusing that the indexes of PlTerm::operator[] start at 1, whereas in
PlTermv::operator[] they start at 0. I'd abandon the PlTermv class
altogether, and use vector<PlTerm> instead; or iterators.

I'd also use C++ strings instead of, or in addition to C strings. The
entire thing could also be better intergreted with the STL. For instance,
Prolog lists could be mapped to list<>. The conversions from/to PlTerm
could also be done more elegantly with template methods, or traits. This
would make it extensible, so you could add your own conversions without
changing the PlTerm class.

Btw. there's a small bug: PlTerm::functor() (as described in the
documentation) is PlTerm::name() in SWI-cpp.h.


Bye

