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

>>> This is all fine, until '[]' may appear as a token in the list.  In that
>> 
>>> case, flatten/2 just removes it.

List flattening is something I have often seen in exercises
but almost never in practice.  It is something best avoided.
And this has absolutely nothing whatever to do with the
fact that [] is an atom.  () is not an atom in Scheme, and
in Scheme you would have to be nuts to work with lists of
unknown structure and flatten them.  From memory, the first
year I was learning Prolog was the last year I ever used
'flatten' in Prolog.

The only language I know where arbitrarily composed lists
are put to good use is Erlang with 'iolists', where the idea
is to use [H|T] as a way of effectively concatenating H and
T.  Specifying the structure of iolists is actually quite
tricky, and in any case iolists do not allow atoms as elements.
Above all, the whole point of iolists in Erlang is *not* to
flatten them, but to build them up using 'constant-time
concatenation' and then pass them to something which traverses
them, not flattening them.

In Prolog, the important thing is that lists are not *that* special.
If they didn't exist, you could define them yourself:

:- data list(T) ---> empty_list | non_empty_list(T, list(T)).

What we _actually_ have is

:- data list(T) ---> '[]' | '.'(T, list(T)).

The alleged "ambiguity of the empty list" is only an issue if you
are using data structures that were designed to *look* well rather
than *work* well.

Making [] not be an atom might (MIGHT!) make bad programming
practices easier to patch into "working", but it would make
meta-programming so much more complicated that it couldn't be
excused.

A typed Prolog exists.  It's called Mercury.  It works very well.



>>>  Due to the ambiguity of the empty list,
>>> creating a multi list and call flatten/2 is considered bad programming.
>>> Without this ambiguity, using multi lists is safe and can be a handy
>>> solution, in particular for the not-so-experienced Prolog programmer.
>> 
>> Also for experienced programmers.  I had to resort to ugly tagging
>> of data in expressions to distinguish [] as a list from atoms, not
>> to mention strings.
> 
> I had (and still have) a hard time defending this. Yes, for most code
> that can work because it relies on [] \== '[]', there are also equally
> or more elegant ways to achieve your goals and no, it is not very
> elegant to have to introduce a new type of atomic constants with a
> single instance. And yes, the real ambiguities it creates on de-facto
> standard predicates (e.g., consult([]) and format("")) are a bit
> far-fledged. Also ambiguities it creates when mapping dynamically typed
> languages that do distinguish lists from symbols only provides weird
> corner cases that go wrong.
> 
> I'm happy that quite a few Prolog programmers admit that this
> distinction is useful. We should also not forget that although I think
> we should claim that the designers of consult/1 and format/3 and related
> cases made a mistake by introducing this ambiguity, they were pretty
> experienced programmers at that time.  Certainly much more experienced
> than the average Prolog programmer.
> 
> 	Thanks --- Jan
> _______________________________________________
> SWI-Prolog mailing list
> [email protected]
> https://lists.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog