🚀 go-pugleaf

N40 says that "Any layout text before the term is ignored.  A
read term ends with the end character followed by a layout text
i.e. a layout char or a comment."   It goes on to say that
"[there] shall be no layout text between the functor and the
opening bracket of a compound term if the functor is a prefix
operator".  Please correct me if I'm wrong, but doesn't `p (x)'
produce a syntax error on Edinburgh Prolog if `p' isn't a
prefix operator?   N40 would seem to allow this.

N33 states (under "Prolog syntax problems" (2): "spaces should
be as insignificant as possible" and refers to N9 which says
that a space is not used to distinguish between a functor and a
prefix operator (I don't have N9 handy right now, but I did
look this up once).

Richard O'Keefe has argued that blanks are significant in
English and they should be significant in Prolog.  This
argument uses a false analogy.  Punctuation characters are used
differently in English than in programming languages -- even
COBOL doesn't use English rules for hyphens and parentheses.
Instead, we should work with a "principle of least surprise",
using other programming languages as a reference.  Edinburgh
Prolog is unique among programming languages in making a
distinction between `p(a,b)' and `p (a,b)'.  [Please don't tell
me about some macro processors which distinguish between these
two cases -- most macro processors have a syntax which can be
at best described as painful.]

If one decides to define 'not' as a prefix operator and also
chooses to use it with as a functor (e.g. `not(a,b)'), one is
asking for trouble and should instead disambiguate by extra
quote marks or parentheses: 'not'(a,b) or not((a,b)).

I therefore suggest that the Prolog standard specifically
disallow using a prefix operator as a functor.  The use of
quotes and extra parentheses allows clear disambiguation.  This
will break a few programs, but in an acceptable way (i.e., they
will produce easily fixed syntax errors, rather than be
accepted silently in an unexpected way).


- Peter Ludemann      pgl@cup.portal.com
                      ...!sun!portal!cup!pgl

   --- my opinions are my sole responsibility, of course ---