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

On 27/11/2013, at 4:23 AM, Alan Baljeu wrote:
> 
> Raising questions, then:
> 1) Is [] an atom in Mercury?

I'm not sure whether that question has an answer.
Let me show you something from the reference manual:

:- type tree
        --->    empty
        ;       leaf(int)
        ;       branch(tree, tree).

:- type list(T)
        --->    []
        ;       [T | list(T)].

So [] is whatever kind of thing empty is.

Whether _either_ of them counts as an "atom" in the Prolog sense
is dubious.  Lists are not built in; they are defined in the
'list' module.  There isn't strictly speaking any built in
'atom' or 'symbol' type.  There _is_ a "term" module for working
with Prolog-style terms, and you can *convert* lists and trees
to terms, and [] and empty would then be structurally similar terms:
functor(atom("[]"),    [], context(...)) for []
functor(atom("empty"), [], context(...)) for empty.

So to the extent that there is a meaningful answer to this question,
I'd have to say "yes".

> 2) Is the breaking change in SWI a step towards stronger typing?

No.  Remember, lists are just *ONE* algebraic data type out of
*infinitely* many in principle and hundreds in practice.  If you
make "[]" not an atom in the list(_) type, why not make "empty"
not an atom in the tree type?  And this leads to a reductio ad
absurdum: since _any_ atom might be a terminating constructor in
a recursive ADT, _every_ must become not-an-atom if you want to
take anything describable as "a step towards stronger typing".


> 3) Mercury works well.  Is that an argument against change in SWI, for change in a different direction, or supporting the viability of the current change?

No, it's an argument that if you DO want to change in the
direction of stronger type checking, then it is advisable
to take your steps in the direction of something that has
been proven to work well, like that.  Taking steps in
random directions (like breaking []) is more like a drunkard's
walk.

If there were a plan for how SWI Prolog might migrate to
stricter type checking, and if the change to [] were part of
that plan, that would be a completely different story.
As yet, we have been given no trace of an adumbration of an
outline of such a plain, so no reason to regard the change to
[] as a _coherent_ step in any direction.

It's the inconsistency that bothers me.  Switching from "..."
as a list of codes to "..." as a string entirely removes the
possible confusion between "" and '[]'.  It doesn't make
much sense to have _both_ changes, especially when the argument
for making [] not be an atom would be, if sound, an argument
for making _every_ atom not be an atom.