🚀 go-pugleaf

In article <245@gould.doc.ic.ac.uk>, cdsm@ivax.doc.ic.ac.uk (Chris Moss) writes:
> >Consider the difference between
> >
> >	foo(X, P, Q, L) :- bag(X, (P & Q), L).
> >				  ^^^^^^^
> >and
> >	de_morgan((P & Q), (R | S)) :- de_morgan(P, R), de_morgan(Q, S).
> >		  ^^^^^^^
> >The first is code, and the treatment of it in the grimoire is appropriate.
> ...
> >I hereby wager US$100, payable once to Chris Moss, that if the next draft
> >of the grimoire attempts to maintain this rigid distinction between code
> >and data, I will be able to find inconsistencies like the ones above in
> >it. 

> Oh dear, I foresee difficulties. I regard both of those as DATA. The
> present syntax does. If we're going to have to agree on where the
> dividing line is, it won't be very fruitful for me. Or is there a
> neutral judge?
> Is that your point?

What matters is not what I regard these examples as, nor yet what Chris
Moss regards them as, but what the actual text of the standard says.

I have in my possession three drafts of BSI Prolog syntax.  In each of
them, anything of the form X & Y is code, not data.  I could cite the
relevant rules, but if you've kept the messages so far you'll have one
where I cite a rule mentioning 'and_symbol', and there is only one rule
which uses 'and_symbol', and the abstract representation it constructs
is a CODE (sys(and,[~P~,~Q~])) representation, not a data one (which
might be func('&',[P,Q]) or func(',',[P,Q]), or it might not).

	-- honesty attack: one of the drafts doesn't actually allow
	-- (P & Q) as an argument at all, but that seems to be a mistake.
	-- I'm talking about the interpretation it would receive if it
	-- were allowed.

I am rather surprised that Chris Moss regards the (P & Q) in
bag(X, (P & Q), L) as *data*.  It is functionally no different from
the (P & Q) in ((P & Q) & fail | true), which I presume is to be regarded
as code.  If a BSI Prolog compiler were to compile the argument of fail_if/1,
or the 2nd argument of bag/3, the programmer would have no way of telling.

Since the whole point of distinguishing between code and data in the syntax
is alleged to be that this permits better error messages, the fact that an
arbitrarily large chunk of code (the second argument to bag/3, or the first
argument to fail_if/1 or once/1) may be misread as data (if Chris Moss is
right) and so may provoke quite the wrong sort of error message means that
the attempt has failed.

I don't agree that we "have to agree on where the dividing line is".
My point is that there ISN'T any such dividing line, and that any attempt
to impose a such a dividing line on Prolog will resemble Solomon's judgement,
without, I fear, its happy consequence.

I realised after sending my original message proposing the wager that I
should suggest judges.  My first idea was to suggest
	Udi Shapiro
	Ken Bowen
	Seif Haridi
if they would be willing, but then I realised that each of them is associated
with a Prolog system which has not been allowed to influence the BSI work and
is as incompatible with BSI Prolog as DEC-10 Prolog or more so, so they might
not be accepted as impartial.  (I'm sure they would be, but it would be best
not to put them in such a position.)  So how about John Lloyd, if he's
willing?  Ok, he was at Melbourne, and Melbourne have an Edinburgh-compatible
Prolog called NU Prolog, so the BSI standard will hurt them, but he isn't at
Melbourne any more, and would welcome something which was closer to logic.

Definition:
	if the BSI grimoire assigns a term an abstract interpretation whose
	principal functor is sys/2, that is a CODE reading.  If it assigns
	an abstract representation which is a variable, a constant, or a
	compound term whose principal functor is func/2, that is a DATA
	reading.  This applies to the drafts I have discussed in this
	newsgroup.  A different criterion may be needed for the draft to
	which the wager applies.

Explanation:
	the BSI grimoire assigns to data terms an abstract representation
	which embeds the space of terms into the space of terms in such
	a way that two terms unify if and only if their abstract
	representations unify.  It assigns to code terms an abstract
	representation which, taken literally, is quite different from
	any data term.  The intent is, I believe, to avoid overspecifying
	the representation of the control structures (e.g. whether (a,b)
	is stored as ','(a,b), '&'(a,b), or even perhaps [AND (a) (b)].
	Thus the syntactic difference between code and data MAY show up
	as a difference in what you actually get, or it may not.  To win
	my wager, I have to show that the next draft of the grimoire
	assigns an inappropriate kind of representation in one example,
	or that it is ambiguous with respect to which kind of representation
	you get at some point.  The ambiguity or inappropriateness is to be
	determined by reference to the abstract representation only.

	There is a BSI document which defines consult/1 by listing code for
	it, which clearly and explicitly calls read/1.  Not being on the
	committee, I haven't read all the documents as carefully as I might,
	so they might have abandoned this link between code syntax and read/1.

By the way, it's a one-way wager:  if I lose, I pay Chris Moss $100, if I
win, he pays me nothing.