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

On 11/27/2013 02:22 AM, Jeff Schultz wrote:
> 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."

Ha, finally implementation! This is not a problem. In SWI-Prolog atoms
are basically `symbols' (called blobs for historical reasons) of type
`atom'. A symbol consists of a byte-blob (hence the name) and a C
struct that defines its type. The struct contains function pointers for
comparision (other than ==, which is decided by the handle), printing,
save/restore, etc. Stream handles and database handles (clause
references) are other things that are implemented as blobs. All blobs go
by one tag, historically called TAG_ATOM. As far as the Prolog engine is
concerned, all blobs are treated equal: they are handles that can be
compared without considering what they represent.

That of course is a bit involved implementation. Long time ago, before
blobs, I considered the same change. What I considered than is to simply
define that a certain atom-handle is [], without adding it to the atom
lookup hash table. You can even bind it to the string "[]". Next, you
need to deal with it in a only few places. Mostly atom/1 and (quoted)
write requires a test in a few places.

> SWI uses large tags and is a byte-coded interpreter.  These

SWI-Prolog only has 3 tag bits:

#define TAG_VAR		0x00000000L	/* tag for variable (= 0L) */
#define TAG_ATTVAR	0x00000001L	/* tag for attributed variable */
#define TAG_FLOAT	0x00000002L	/* Floating point number */
#define TAG_INTEGER	0x00000003L	/* Tagged or indirect integer */
#define TAG_ATOM	0x00000004L	/* an atom */
#define TAG_STRING	0x00000005L	/* String */
#define TAG_COMPOUND	0x00000006L	/* Compound term */
#define TAG_REFERENCE	0x00000007L	/* Reference pointer */

It is not really a byte-coded interpreter. The VM code is an
array of machine words. Operations are pointers into the VM (using
GCC's threaded code support if available). Operations are followed by 0
or more arguments, often data in their native Prolog representation.

	Cheers --- Jan

> representation issues are not a big problem for it.  They are for some
> other implementation choices.
>
>
>      Jeff Schultz
> _______________________________________________
> SWI-Prolog mailing list
> [email protected]
> https://lists.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog