🚀 go-pugleaf

I have been sending messages which are rather hard on BSI Prolog syntax.
Somewhat belatedly, I'd like to try to put these comments in perspective.

1.  I believe that an attempt to force a rigid distinction between code
    and data is misguided in *any* Prolog dialect, because that distinction
    does not correspond to anything real in the language.  I stand by my
    one-way US$100 wager.

    One of the BSI documents in my possession makes it clear, by showing
    Prolog code purporting to be a definition of consult/1, that consult/1
    is to be based on read/1.

2.  If BSI Prolog were just another dialect, or if BSI Prolog provided means
    whereby a programmer could install another definition of read/1 (such as
    the public-domain DEC-10 Prolog parser, or something that uses VM/PROLOG
    syntax, or something that uses BIM native syntax, or whatever), then a
    fair assessment of the intended syntax (as distinct from the grammar)
    would be "a pretty good compromise".

    In fact, I'd say that it is easily the best of the current fragments.

    I have complained about differences between BSI syntax and DEC-10 Prolog
    syntax.  A number of things in DEC-10 Prolog syntax have been unpopular
    or misunderstood, and many of the changes are well motivated.  But they
    are changes which will be imposed on Prolog users without their consent.
    It doesn't matter how good the BSI syntax is (and it has merits), if
    Prolog users *have* to use it, it will COST them.

3.  BSI Prolog provides a Prolog-like syntax and a Lisp-like syntax (though
    I do not yet know how you say which one you want).  Neither of these
    syntaxes, despite their merits, is sufficiently compatible with DEC-10
    Prolog to read many of my files.  That is, anyone who has existing
    DEC-10 Prolog, ALS Prolog, Arity/Prolog, &c code and wants to use a BSI
    conforming processor will apparently be forced to make many changes to
    their files if they want to use the Prolog-like syntax.  This is why
    the strictest attainable backwards compatibility is so important.  If
    BSI processors *offered* a standard syntax rather than *imposing* it,
    and provided a standard way to select syntaxes additional to the
    Prolog-like and Lisp-like ones, then vendors could offer
    compatibility modules to help their customers convert to the standard.  

As an example, consider Common Lisp.  The native syntax of Common Lisp is
differs in a great many details from the syntax of Interlisp, yet on the
Xerox Lisp Machines the two dialects use the same reader, with the differences
being concentrated in read-tables.  I like Common Lisp syntax, someone else
here likes Interlisp, and we can both use the syntax of our choice.  (Even 
for the same files...)