🚀 go-pugleaf

In article <1431@kulcs.kulcs.uucp> bimbart@kulcs.UUCP (Bart Demoen) writes:
>In article <619@ecrcvax.UUCP> bruno@ecrcvax.UUCP (Bruno Poterie) writes:
>>This may be alright if you seek only efficiency, but:
>>	o  you increase the size of your database by a non-negligible factor
>>	o  you fill up your dictionary with functors 
>[Demoen also included "repr1" and "repr2" again]

>I tested your second remark, on the database size, in BIMprolog, but the
>result might be the same for other implementations as well; and the result
>is not that surprising:

>repr2 uses 8 WAM instructions LESS than repr1
>repr2 uses 260 native code bytes LESS than repr1

Demoen has recently been attacking my tutorial as being dialect-specific.
In the current version of Quintus Prolog,
	repr2	occupies 412 bytes (clauses + procedure records)
	repr1	occupies 312 bytes (clauses + procedure records)
	rule/3	occupies 300 bytes (clauses + procedure records)
where rule/3 is the representation which looks like e.g.
	rule(append([H|T],L,[H|R]), [append(T,L,R)|Goals], Goals).

When making a comparison like this, it is important to make sure that
no other storage is being consumed, so I first compiled a dummy file
which mentioned all the atoms that appeared in Demoen's examples.

There is at least one otherwise sensible Prolog system for PCs which
has a rather low limit on the number of predicates a user can define.
That's not my reason for not having described the method Demoen refers
to as 'repr2', but it does show that Poterie is complaining about a
real problem.  (The real problem is such low limits, of course.)

I don't expect these figures for Quintus Prolog to generalise to other
systems, and I was surprised by them myself.