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

After reading more or less carefully all emails, and Section 5 of the
manual, can someone please answer these questions:

1. What are the practical situations in which " [] \== '[]' " becomes a
problem? (I don't mean existing code that assumes " [] == '[]' ", but
rather a problem with defining a predicate doing something with lists, or
not trying to do anything with lists.)

2. In "plain" Prolog, is there any other compound term treated like a list
is (compound terms are all equal, I guess, but lists are definitely more
equal)? My main conceptual problem with lists (at the beginning) was that
the properties and uses of lists really did not seem to necessitate them
being defined like they were: " .(a, .(b, ..., []))".

To rephrase, I see how list properties (and operations on lists) follow
directly from them being defined as they were, but I don't see how why
lists *must* have this particular representation.

These questions are really in good faith, I see that there is quite a bit
of excitement about the changes to lists in particular and SWI-Prolog in
general and I am trying to understand the exact reasons.

Cheers,
Boris


On Wed, Nov 27, 2013 at 6:42 AM, Richard A. O'Keefe <[email protected]>wrote:

>
> 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.
>
>
> _______________________________________________
> SWI-Prolog mailing list
> [email protected]
> https://lists.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog
>  <https://lists.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog>
>
-------------- next part --------------
HTML attachment scrubbed and removed