Re: [] \= '[]' (was Re: Ann: SWI-Prolog 7.1.0)

Jeff Schultz <[email protected]>
Newsgroups gmane.comp.ai.prolog.swi
Message-ID <[email protected]>
On 26/11/2013 20:41, Jan Wielemaker wrote:
> There is a simple QED for [] \== '[]': it has proven to break extremely
> little and the things it did break were mostly broken already (just in a
> more subtly way).

> The only practical thing it breaks is foreign code doing ATOM_nil =
> PL_new_atom("[]"). That even affects little code as the C API already

For me, a very important thing it potentially breaks is my usual machine 
representation of Prolog values.  This is to take a machine word (often 
still 32 bit) and partition it into a *small* bitfield for a "tag" and 
use the rest for a "value."

Keeping the tag field small has very practical implications.  At no more 
than 2 or 3 bits for the tag, the value field can address any aligned 
word in memory.  Prolog needs tags for variables, terms, atoms, integers 
and floats.  That's five values, and leaves an additional three 
possibilities in a 3 bit tag.  Usually (SWI doesn't) one is used for a 
more compact representation of lists, one for "big" integers, and one is 
spare.

Problem is, that one tag now has to accommodate non-atom NIL, 
maps/dicts/objects/whatever, and strings.  (And there are other data 
types in SWI already too.)  It is possible to fairly efficiently re-pack 
all of these into eight primary tags, using a mixture of sub-tags on 
some kinds of values, and tagged boxed memory for others, but it leads 
to more generated machine code, which affects performance.  (For my 
implementations, it appears that I'd need to consume one of the eight 
primary tags just for non-atom NIL, or see a performance reduction on 
list-processing code.)

SWI uses large tags and is a byte-coded interpreter.  These 
representation issues are not a big problem for it.  They are for some 
other implementation choices.


     Jeff Schultz
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.