Subject: Re: [Fwd: abolish/1 in 3.3.0]

From: Paul Singleton <[email-masked]>
Date: Mon, 24 Jan 2000 16:14:11 +0000

"Richard A. O'Keefe" wrote:

>  4. It just "feels" wrong.  Atoms are *symbolic*; it's the *identity* of
>     atoms that matters, not their *spelling*.  Strings are *textual*;
>     it's their *spelling* that matters, not their identity, for they have
>     none.

Surely atoms and character-code lists are two alternative
implementations of the same abstract type?

Both are immutable, hence are better seen as values, not objects.

In this view, neither has "identity", only equality.

Which you use depends on which operations are more common:

  if you mostly compare for equality, then the costs of the dictionary
  scheme (internment and garbage collection) are probably worth paying

  if you often want to decompose them, then the costs of the "chars"
  representation may be worth paying

  if you generate lots of them, e.g. retrieving fields from databases,
  then the chars repn may be cheaper overall, even though comparison
  is expensive

(Other schemes are feasible which may suit the third case better.)

Some programmers may prefer to use the atom ADT throughout an
application, despite its inefficiency in some respects, in the
belief that it contributes to overall simplicity.  I.e. there
may be a stylistic rationale for using the "wrong" ADT.

I think I'm arguing that both implementations should support the
same interface, e.g.

    atom_length/2      chars_length/2
    atom_member/2      chars_member/2
    atom_append/3      chars_append/3
    atom_to_term/2     chars_to_term/2
    etc.               etc.

in the name of orthogonality, and in the interest of simplifying
migration from one scheme to another.

I agree that the semantics of XXX_to_term/2 are so narrow and
arbitrary as to make it unworthy of being regarded as a "primitive",
but whether a Prolog system implements it in native library code,
in foreign library code, or deep within the kernel is surely
down to efficiency?

I'm sure we agree that it is out of order for Prolog implementors
to attempt to force application developers to use one or other ADT
in particular circumstances by not implementing certain operations.

I agree with Richard that atom_to_term "feels wrong", but disagree
that this in any way justifies not implementing it.

Paul Singleton