🚀 go-pugleaf

In article <771@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes:
cdsm> WRONG. The second is not allowed in the BSI form. You missed the 'h'
rok>
rok>  I jumped to the conclusion that rule 5.5
rok>should have had 'h' as its left-hand constraint because fairly serious
rok>nonsense would result if 5.5 wasn't fixed somehow.

almost right; that clause didn't do what it was intended to do and I've
entirely rephrased in draft 5 (in the post to you).

I feel I should confess to the large number of typos and errors in
the version you received. My only excuse is that most of the work was
done while I was recovering from a car accident and experiencing
quite a lot of back pain.  It's not a good excuse, but it's the only
one I have! For the same reason I didn't run that version through
Prolog, tho others had applied the treatment to earlier versions.

rok>Well, it depends what you mean by a symbol.  I regard "fred(" or ":-("
rok>as a single token.  It seems just as reasonable to do that as to regard
rok>"1.0e-4" as a single token, or do you want to allow spaces there too?

An intriguing viewpoint. Unfortunately not backed by the published
grammar for Quintus (manual version 10, release 2.0). May I quote:

term(0) --> functor ( arguments )
              {provided there is no space between functor and the '('}

functor --> name
   etc.

Nowhere in the definition of "name" does "(" appear.  I suggest you get
Quintus to modify their grammar to fit in with your views.  Incidentally,
the section on "Syntax of Tokens as character strings" in the Quintus
manual is even more imprecise. The only mention of '(' is in the
production:

punctuation-char --> () | [] | {} | , | |

which, if I can possibly understand it (the use of bold characters in the
manual is rather inconsistent), means that brackets can only be used in a
Prolog program if paired with no characters inbetween!

rok>Putting a space after a left parenthesis or before a right parenthesis
rok>is appallingly bad English punctuation, so it sounds as though you must
rok>have a lot of trouble with your typists working on English too.

touche!

rok>Do you regard the fact that a typist is likely to mistake an iota for
rok>an i or an epsilon for an e as an argument that mathematiciains should
rok>not use Greek letters?  Should we outlaw vertical bars because bad
rok>typists think they are solidii or ells or capital Is?  

I think you're getting away from the point -- tho in the standard we DO
allow other Europeans to use their alphabetic characters with diacritical
marks.

rok>  Surely it is inconsistent to argue that
rok>	"RED O" and "REDO"
rok>are different, and that is a Good Thing, but
rok>	"red (O)" and "red(O)"
rok>being different is a Bad Thing?  Blanks are being treated as
rok>significant in both cases. 

Oh dear, you don't really mean this do you Richard?

rok>The only constraint is that if <atom> is a prefix operator, there must
rok>be no space between <atom> and "(".  Therefore :-(p,q) ***IS*** in the
rok>grammar.

agreed. In version 5 we have reluctantly invented the new category of
"reserved graphic symbol" which includes all the system operators and not
just ".". One can still get at the atomic symbols by quoting.

rok> The grimoire makes it plain that
rok> 	A , B
rok> and	A & B		<--- BIG MISTAKE
rok> are both mapped to sys(and,[A,B]), but whether either of these is the
rok> same as ','(A,B) or '&'(A,B) is not said.  
cdsm> 
cdsm> The only context in which they are the same is when they are passed to
cdsm> 'call' or another meta-primitive which maps terms to predicates.
rok>
rok>No, the grimoire says very very clearly that both (a,b) and (a&b)
rok>are mapped to the same Abstract, namely
rok>
rok>	sys(and, [func(a,[]), func(b,[])])
rok>

   I'll say it once, then not again. Richard I CAN'T STAND your upper class
   British accent! If I were you I wouldn't advertise it! :-)

You've made the point in another message I haven't had time to reply to
yet. The grammar as you have it ONLY describes clauses. In version 5 we've
provided both -- syntax for clause and for read and semantics for both
states -- actually I think the double semantics is probably an overkill.
The only things it really elucidates are the treatment of constructs such
as if-then-else. So maybe in a future version it'll get toned down.

rok>But the question of which symbols the programmer can declare as operators
rok>is surely a syntactic question.  If I want to know what operators I can
rok>declare in Algol 68, I look in the grammar.  

Agreed, and it is possible in the revision. Incidentally once upon a time
I liked Algol 68 too! My Ph.D. thesis contains a restatement of syntax and
semantics of a largish subset of the language in DCG form.

cdsm> Do people want: (3) the full freedom to use logical symbols or
cdsm> natural language symbols as they think fit?
rok>
rok>Everyone will go for (3), of course.  But that is something of a red
rok>herring, as BSI Prolog won't allow it.  Sure I'd like to be able to
rok>write
rok>	every group is a monoid.
rok>Oh, "natural language symbols" didn't mean that?  Silly me.

I think what I meant was obvious from context. One of the delights of
conversing in English not Prolog!

rok>This applies to the rules proper only.  It does not apply to the lines
rok>labelled "Constraint", "Abstract", "Priority", "Input", "Output".
rok>There are at least two problems with these additional lines.
rok>
rok>The first, of course, is that they use a two-dimensional format where
rok>the number of spaces is vitally significant:

Actually, it very rarely uses spaces - usually tabs! :-)

rok>One also has to watch out for the fact that some lines are omitted from
rok>some rules.  I believe it to be the case that to determine which attributes
rok>are relevant to what non-terminals it is necessary to examine the entire
rok>grammar.  

I took your suggestion of converting it directly to DCG form, and I hope
it is true now that no attributes are omitted. It should NOT be necessary.

rok>But the second, and biggest problem, is that not only are these new lines
rok>not part of BS6154, the whole thing is a new formalism which is not
rok>described in any of the documents that the BSI committee have sent me.

It IS described in the document itself. Admittedly only in English!

rok>What does it mean when a rule of the grimoire says
rok>
rok>Rule	 foo = 	baz,  [ ugh ] ;
rok>Abstract f(X,Y)	X	Y
rok>
rok>I *think* it means
rok>
rok>	 foo =	baz, ugh ;
rok>	 f(X,Y)  X    Y
rok>+
rok>	 foo =   baz ;
rok>	 f(X,[])
rok>
rok>but I can find nothing that says so.  

Correct; this IS in the current draft, together with the rest.

So much for now.
Chris Moss.