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