lee@mulga.oz (Lee Naish) (09/30/87)
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
cdsm@doc.ic.ac.uk (Chris Moss) (10/07/87)
In article <2278@mulga.oz> lee@mulga.UUCP (Lee Naish) writes: > 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] 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. I have a lot of sympathy with this, and used to write all my conses with a dot. But now I think it shouldn't be allowed. After all, nobody likes writing full lists as a.b.c.d.[]. They always switch to [a,b,c,d] in the end. So it's more confusing having the two notations. Sure every IMPLEMENTOR must know that '.' is the cons functor. But it helps to clean up error handling if . on its own (i.e. not in a number or graphic symbol) is always the line terminator. Then one can get away from the silly errors like a(b).a(c). being treated as one clause. Most of the other arguments (one less character etc.) are far less important than the learning argument. Of course the best notation would be [a b c . X] (have I seen that before?) but then . as a terminator would be impossible. Chris Moss..