🚀 go-pugleaf

In article <5265@jade.BERKELEY.EDU> lagache@violet.berkeley.edu (Edouard Lagache) writes:
>     To be quite honest, I thought that nit-pickers were only to be found in
>     model railroading and other "precision" hobbies, but I guess the PROLOG
>     net has its own set, and regrettably, I didn't put a "no nit-picking"
>     sign on my documentation.
I think it is unfortunate that there has been so much negative feedback
for Lagache's code.  There have been other collections of code posted to
the net (worse than the recent posting, I think) which people have quietly
ignored.  Recent postings are a result of long term frustration, and are not
personal attacks.  Hopefully people will learn from these postings (I have).

>               merge([],[],[]).
>               merge(Head1.Tail1, Head2.Tail2, Head1.Head2.R) :-
>                         merge(Tail1,Tail2,R).
>
>     does not run on the A.D.A. VML PROLOG interpreter.  It complains about
>     finding "unexpected period on line 2".  While I believe the dot
>     notation for cons cells is part of the original language specification,
>     it isn't mentioned in Clocksin and Mellish, and thus, is missing from
>     at least one PROLOG implementation.
It can be made to run on some Prolog systems which object to it at first
by declaring . as an operator.  One thing which has always puzzled me is
why people (even the best Prolog programmers in the civilized world),
insist on using [H|T] instead of H.T and why implementors support the
first syntax more.

	H.T is more readable
	H.T says the functor is '.' and there are two arguments, H and T
	H.T is one less character
	H.T doesn't use 'funny' characters used for letters in Europe
	H.T is not a syntactic special case (well,.. less so)

[H|T] confuses people.  It has confused Prolog implementors!  There are
Prolog implementations in which lists are not normal terms, due to this.
Of course it is a shame that '.' and ',' are so overloaded in Prolog,
but since '.' IS the list constructor functor, we may as well get it
out in the open for all to see.

>     still in the midst of a "readability revolution".  Given the terseness
>     of some of the code touted as "improvements" over my work, it may be
>     time for some people on this net to go back and take a course in
>     structured Pascal!
Readability is in the eye of the beholder (see my previous comment).
However, I think it is generally agreed that cut does not aid readability.
An advantage that (clean) Prolog has over Pascal (no matter how structured)
is that it has declarative semantics.  People should rediscover this every
few months; one tends to forget.

	Lee Naish