Here is a small issue that is currently of interest due to
the focus on DCGs:

http://www.complang.tuwien.ac.at/ulrich/iso-prolog/3steps

Ulrich Neumerkel schrieb:
> Here is a small issue that is currently of interest due to
> the focus on DCGs:
>
> http://www.complang.tuwien.ac.at/ulrich/iso-prolog/3steps
>

This means :- char_conversion('|',';') would not do for various
reasons? Like lists cannot be parsed anymore etc..

Interestingly DEC10 had '|' as synonym for ';' in goal contexts
and '..' as synonym for '|' in list contexts. Not archivable
with char_conversion at all.

The disadvantage of having separate operators '|' and ';' is
that we would need two definitions, for example for phrase/3,
i.e.:

   phrase((A;B),I,O) :- phrase(A,I,O); phrase(B,I,O).
   phrase((A|B),I,O) :- phrase(A,I,O); phrase(B,I,O).

Or would be the bottom line that A;B is not part of DCG?

Bye

Jan Burse schrieb:

> Or would be the bottom line that A;B is not part of DCG?

SWI allows it:

1 ?- [user].
|: abc --> def ; ghi.
|:
% user://1 compiled 0.00 sec, 872 bytes
true.

2 ?- listing.

abc(A, B) :-
         (   def(A, B)
         ;   ghi(A, B)
         ).
true.

3 ?-

Jan Burse <janburse@fastmail.fm> writes:
>Ulrich Neumerkel schrieb:
>> Here is a small issue that is currently of interest due to
>> the focus on DCGs:
>>
>> http://www.complang.tuwien.ac.at/ulrich/iso-prolog/3steps
>>
>
>This means :- char_conversion('|',';') would not do for various
>reasons? Like lists cannot be parsed anymore etc..
>
>Interestingly DEC10 had '|' as synonym for ';' in goal contexts
>and '..' as synonym for '|' in list contexts. Not archivable
>with char_conversion at all.

There was never a .. .  However, in versions about 1978-09,
there used to be ,..  meaning | for lists. It is for this
reason that we still have =.. and not boum(2).

>The disadvantage of having separate operators '|' and ';' is
>that we would need two definitions, for example for phrase/3,
>i.e.:

To get best portability between systems that go
step 1 and step 2 but not necessarily step 3, one would
have to use '|' in place of |


>   phrase((A;B),I,O) :- phrase(A,I,O); phrase(B,I,O).
>   phrase((A|B),I,O) :- phrase(A,I,O); phrase(B,I,O).
   phrase((A'|'B),I,O) :- phrase(A,I,O); phrase(B,I,O).

This would work in all standard compilant systems
with step 1.  Regardless of step 2!

>Or would be the bottom line that A;B is not part of DCG?

No. The bottom line is that we have two nonterminals
(or control constructs): (;)//2 and ('|')//2.

For most users the difference will remain invisible anyway.
But for systems like B, CIAO, SWI, YAP it is necessary
to have ('|')//2 explicitly defined.

Ulrich Neumerkel schrieb:

> There was never a .. .  However, in versions about 1978-09,
> there used to be ,..  meaning | for lists. It is for this
> reason that we still have =.. and not boum(2).

Yes, exactly (for example DEC10 manual as of 10 November 1982).
But I doubt that ,.. is an atom, wouldn't it be tokenized
as , and ..?

Boum must come from the Colmerauer camp since it sounds french
to me. An ancient name/2 predicate which can also take full
terms?

> To get best portability between systems that go
> step 1 and step 2 but not necessarily step 3, one would
> have to use '|' in place of |
>
>
>>    phrase((A;B),I,O) :- phrase(A,I,O); phrase(B,I,O).
>>    phrase((A|B),I,O) :- phrase(A,I,O); phrase(B,I,O).
>     phrase((A'|'B),I,O) :- phrase(A,I,O); phrase(B,I,O).
>
> This would work in all standard compilant systems
> with step 1.  Regardless of step 2!

What is the reason here. Why is there a difference between
A|B and A'|'B? Note my first (A|B) is not a list.

I guess this is a printing routine error of the Prolog you
have at hand. Since you also do not print '!', but !.

I checked SWI, it can parse without the single quotes,
but insists in printing it with quotes:

1 ?- X = (A | B).
X = (A'|'B).

2 ?- X = !.
X = !.

> No. The bottom line is that we have two nonterminals
> (or control constructs): (;)//2 and ('|')//2.

Any places where this is important? Where lets say the
semantics of (;)/2 and (|)/2 might differ?

And a further question, any reason to use _//_ instead
of _/_ to denote predicate identifications?

Bye

Ulrich Neumerkel schrieb:
> There was never a .. .  However, in versions about 1978-09,
> there used to be ,..  meaning | for lists. It is for this
> reason that we still have =.. and not boum(2).

Interesting archeological result, .. had a use once(*)
as a cut after the head of a clause. I found it
when googling for boum:

 > The only control operators were placed at the end of
 > clauses as punctuation marks, and their function was
 > to perform cuts in the search space. The annotations:
 >
 > .. performed a cut after the head of the clause,
 > .; performed a cut after execution of the whole rule,
 > ;. performed a cut after production of at least one answer,
 > ;; had no effect.
 >
 > These extra-logical operators were exotic enough to cause
 > their users problems and were therefore subsequently abandoned.
 > Curiously, this punctuation had been introduced by Alain
 > following his discovery of the optional and mandatory
 > transformation rules of the linguist, Noam Chomsky [1965].

Bye

(*)
The birth of Prolog, Alain Colmerauer1 and Philippe Roussel,
November 1992

Jan Burse <janburse@fastmail.fm> writes:
>Ulrich Neumerkel schrieb:
>
>> There was never a .. .  However, in versions about 1978-09,
>> there used to be ,..  meaning | for lists. It is for this
>> reason that we still have =.. and not boum(2).
>
>Yes, exactly (for example DEC10 manual as of 10 November 1982).
>But I doubt that ,.. is an atom, wouldn't it be tokenized
>as , and ..?
>
>Boum must come from the Colmerauer camp since it sounds french
>to me. An ancient name/2 predicate which can also take full
>terms?
>
>> To get best portability between systems that go
>> step 1 and step 2 but not necessarily step 3, one would
>> have to use '|' in place of |
>>
>>
>>>    phrase((A;B),I,O) :- phrase(A,I,O); phrase(B,I,O).
>>>    phrase((A|B),I,O) :- phrase(A,I,O); phrase(B,I,O).
>>     phrase((A'|'B),I,O) :- phrase(A,I,O); phrase(B,I,O).
>>
>> This would work in all standard compilant systems
>> with step 1.  Regardless of step 2!
>
>What is the reason here. Why is there a difference between
>A|B and A'|'B? Note my first (A|B) is not a list.

The difference is that in SICStus Prolog (A|B) == (A;B).
So your two clauses would be redundant.

The intention of this approach is to harmonize syntax
(as much as possible).  (A'|'B) is the same in all systems.
So if systems will only agree on step 1 and 2, we still
have obtained a better degree of portability than is
now the case.


>
>I guess this is a printing routine error of the Prolog you
>have at hand. Since you also do not print '!', but !.

It has something to do with reading, not with printing.

>> No. The bottom line is that we have two nonterminals
>> (or control constructs): (;)//2 and ('|')//2.
>
>Any places where this is important? Where lets say the
>semantics of (;)/2 and (|)/2 might differ?

It is important that ('|')//2 is defined for DCGs.

A case of difference would be CHR, here ; is disjunction
and | commit.  So here the meaning is different.

>And a further question, any reason to use _//_ instead
>of _/_ to denote predicate identifications?

F/N is a predicate indicator.

G//N is a nonterminal indicator. It refers to a nonterminal
within a grammar.

Jan Burse <janburse@fastmail.fm> writes:
>Ulrich Neumerkel schrieb:
>> There was never a .. .  However, in versions about 1978-09,
>> there used to be ,..  meaning | for lists. It is for this
>> reason that we still have =.. and not boum(2).
>
>Interesting archeological result, .. had a use once(*)
>as a cut after the head of a clause. I found it
>when googling for boum:
>
> > The only control operators were placed at the end of
> > clauses as punctuation marks, and their function was
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

In Prolog 0 - as it is called today - the sequence .. was
not an operator to be used in a clause.

Ulrich Neumerkel wrote:
> 
> It is important that ('|')//2 is defined for DCGs.

Important?? I don't know. You can write portable DCGs with
semicolons, and you can write your "portable DCG translator" as

phrase((A;B),I,O) :- phrase(A,I,O); phrase(B,I,O).
phrase('|'(A,B),I,O) :- phrase(A,I,O); phrase(B,I,O).

or put the op declaration into the DCG translator.

I agree that this is a useful syntax extension, but DCGs
are not the reason.

-- Joachim

On 15 Jun., 01:08, ulr...@mips.complang.tuwien.ac.at (Ulrich
Neumerkel) wrote:
> The difference is that in SICStus Prolog (A|B) == (A;B).
> So your two clauses would be redundant.

Oki Doki, in SICStus we can escape synonym with quotes. Right?

> G//N is a nonterminal indicator. It refers to a nonterminal
> within a grammar.

Ok, G//N = G/N+2. Right?

Bye

Joachim Schimpf <jschimpf@users.sourceforge.net> writes:
>or put the op declaration into the DCG translator.

How's that possible?  How can you put the declaration into
the DCG translator?

Operators are effectively global.  That is, if I want
to use DCGs and CHRs in the same file/module, the
operator declarations have to be compatible.

>I agree that this is a useful syntax extension, but DCGs
>are not the reason.

They are not a reason for ECLIPSE since you can switch
to any syntax you like, but they are a reason for B,
CIAO, SWI, YAP.

jb <bursejan@gmail.com> writes:
>On 15 Jun., 01:08, ulr...@mips.complang.tuwien.ac.at (Ulrich
>Neumerkel) wrote:
>> The difference is that in SICStus Prolog (A|B) == (A;B).
>> So your two clauses would be redundant.
>
>Oki Doki, in SICStus we can escape synonym with quotes. Right?

In any standard conformant system a name under quotes is not
rewritten to something else. So this is in no way specific
to SICStus.

>> G//N is a nonterminal indicator. It refers to a nonterminal
>> within a grammar.
>
>Ok, G//N = G/N+2. Right?

Effectively that's the case with most systems.  But
you would not write functor//1 in place of functor//3.

The point of using // is to clearly indicate that this
is a nonterminal to be used within a DCG.  Ideally
the name spaces would be different.  But they are
not.  What can be assumed here safely and what not,
is still subject to debate.

ulrich@mips.complang.tuwien.ac.at (Ulrich Neumerkel) writes:
>Effectively that's the case with most systems.  But
>you would not write functor//1 in place of functor//3.
                                            functor/3

On 2010-06-15, Ulrich Neumerkel <ulrich@mips.complang.tuwien.ac.at> wrote:
> Joachim Schimpf <jschimpf@users.sourceforge.net> writes:
>>or put the op declaration into the DCG translator.
>
> How's that possible?  How can you put the declaration into
> the DCG translator?
>
> Operators are effectively global.  That is, if I want
> to use DCGs and CHRs in the same file/module, the
> operator declarations have to be compatible.
>
>>I agree that this is a useful syntax extension, but DCGs
>>are not the reason.
>
> They are not a reason for ECLIPSE since you can switch
> to any syntax you like, but they are a reason for B,
> CIAO, SWI, YAP.

I think CIAO, SWI and YAP allow for structured and local extension of
the syntax (using operators). CIAO does this using the :- module(Name,
Exports, Extensions), where each Extension basically includes a file
that holds operator definitions and imports other requirements. SWI and
YAP can import and export operators. You definitely know some of this
:-)

	Cheers --- Jan

Jan Wielemaker <janw@hppc323.few.vu.nl> writes:
>On 2010-06-15, Ulrich Neumerkel <ulrich@mips.complang.tuwien.ac.at> wrote:
>> Joachim Schimpf <jschimpf@users.sourceforge.net> writes:
>>>or put the op declaration into the DCG translator.
>>
>> How's that possible?  How can you put the declaration into
>> the DCG translator?
>>
>> Operators are effectively global.  That is, if I want
>> to use DCGs and CHRs in the same file/module, the
>> operator declarations have to be compatible.
>>
>>>I agree that this is a useful syntax extension, but DCGs
>>>are not the reason.
>>
>> They are not a reason for ECLIPSE since you can switch
>> to any syntax you like, but they are a reason for B,
>> CIAO, SWI, YAP.
>
>I think CIAO, SWI and YAP allow for structured and local extension of
>the syntax (using operators). CIAO does this using the :- module(Name,
>Exports, Extensions), where each Extension basically includes a file
>that holds operator definitions and imports other requirements. SWI and
>YAP can import and export operators. You definitely know some of this
>:-)

There are mechanism to keep operators "as local as possible".
Yes.  But if you want to use in the same file/module both CHR and DCGs,
their operators have to be compatible.  That's what I mean by
"effectively" global.

On 2010-06-15, Ulrich Neumerkel <ulrich@mips.complang.tuwien.ac.at> wrote:
> Jan Wielemaker <janw@hppc323.few.vu.nl> writes:
>>On 2010-06-15, Ulrich Neumerkel <ulrich@mips.complang.tuwien.ac.at> wrote:
>>> Joachim Schimpf <jschimpf@users.sourceforge.net> writes:
>>>>or put the op declaration into the DCG translator.
>>>
>>> How's that possible?  How can you put the declaration into
>>> the DCG translator?
>>>
>>> Operators are effectively global.  That is, if I want
>>> to use DCGs and CHRs in the same file/module, the
>>> operator declarations have to be compatible.
>>>
>>>>I agree that this is a useful syntax extension, but DCGs
>>>>are not the reason.
>>>
>>> They are not a reason for ECLIPSE since you can switch
>>> to any syntax you like, but they are a reason for B,
>>> CIAO, SWI, YAP.
>>
>>I think CIAO, SWI and YAP allow for structured and local extension of
>>the syntax (using operators). CIAO does this using the :- module(Name,
>>Exports, Extensions), where each Extension basically includes a file
>>that holds operator definitions and imports other requirements. SWI and
>>YAP can import and export operators. You definitely know some of this
>>:-)
>
> There are mechanism to keep operators "as local as possible".
> Yes.  But if you want to use in the same file/module both CHR and DCGs,
> their operators have to be compatible.  That's what I mean by
> "effectively" global.

??? Does Eclipse have something more local?  Yes, you can import
conflicting syntax.  use_module/2 even allows you to control what you
import and Prolog's canonical term-syntax can always be used to
resolve possible operator conflicts.  I can't really see you can
achieve much more locality.

	Cheers --- Jan

Jan Wielemaker <janw@hppc323.few.vu.nl> writes:
>On 2010-06-15, Ulrich Neumerkel <ulrich@mips.complang.tuwien.ac.at> wrote:
>> There are mechanism to keep operators "as local as possible".
>> Yes.  But if you want to use in the same file/module both CHR and DCGs,
>> their operators have to be compatible.  That's what I mean by
>> "effectively" global.
>
>??? Does Eclipse have something more local?  Yes, you can import
>conflicting syntax.  use_module/2 even allows you to control what you
>import and Prolog's canonical term-syntax can always be used to
>resolve possible operator conflicts.  I can't really see you can
>achieve much more locality.

How do you use CHR and DCGs in the same file?  If both would
have conflicting priorities for ('|')//2 one of them would be
in yeopardy.  That's why it is so important to keep their
priorities compatible.

Ulrich Neumerkel schrieb:
> The point of using // is to clearly indicate that this
> is a nonterminal to be used within a DCG.  Ideally
> the name spaces would be different.  But they are
> not.  What can be assumed here safely and what not,
> is still subject to debate.

So we could prevent Prolog texts such as:

	inc --> [def].
	inc(X,Y) :- Y is X+1.

Or

	inc --> {def(X,Y)}.
	def --> [abc].

Which would then be considered errorneous?

Bye

Jan Burse <janburse@fastmail.fm> writes:
>Ulrich Neumerkel schrieb:
>> The point of using // is to clearly indicate that this
>> is a nonterminal to be used within a DCG.  Ideally
>> the name spaces would be different.  But they are
>> not.  What can be assumed here safely and what not,
>> is still subject to debate.
>
>So we could prevent Prolog texts such as:
>
>	inc --> [def].
>	inc(X,Y) :- Y is X+1.
>
>Or
>
>	inc --> {def(X,Y)}.
>	def --> [abc].
>
>Which would then be considered errorneous?

Your example touches the delicate questions very directly.

In your example nonterminals and terminals are all
mixed up.  In most of the situations this is an error,
but sometimes - very rarely so - it does make sense.

Consider what in grammars is frequently the dollar sign
which means  at_end//0.  In that particular case,
an implementation needs to write

at_end([], Xs) :-
   call(Xs = []).

So such cases should be expressible - somehow.

The current idea is to have call//1 as a nonterminal,
which expands to call/3.  Coincidentally - all
implementations perform that expansion already. Even
those that do not offer call/N.  Providence!

So now, we can write:

at_end_predicate([], Xs) :-
   call(Xs = []).

at_end -->
   call(at_end_predicate).

In most situations the extra level of a predicate
is not needed.  And yes, you can use lambdas for that
as well:

at_end -->
   call(\[]^[]^true).

In this manner cross-referencing and the like can
distinguish unintended uses - such as the examples
you gave from intended ones.

From the point of view of a standard there are several
ways how to deal with such a situation:

Demand that other uses are rejected.  This would rule
out all existing systems.  So something would be
demanded that is not current practice.

Describe the situations where we can rely on DCGs.
The exact wording is the most delicate thing.


OK. That is one problem.

And then, there is another problem:

Which predicates and nonterminals can a programmer
use safely at the same time?  I.e., how
much of the expansion mechanism current implemetations
do becomes visible to the programmer?  That is
one of the more difficult things...

Please refer to

http://www.sju.edu/~jhodgson/wg17/Drafts/
http://www.sju.edu/~jhodgson/wg17/Drafts/DCGs/

for the current drafts.  I have not yet found the
the time to comment on them officially.  As usual,
I am not too happy with the current status.

E.g. how would the current draft rule out the
following translation:

p --> \+ q.

into

p(Xs0,Xs) :- \+ q(Xs0,Xs).  % Incorrect!!


In any case, please read the drafts - and please do comment!

ulrich@mips.complang.tuwien.ac.at (Ulrich Neumerkel) writes:
>Jan Burse <janburse@fastmail.fm> writes:
>>Ulrich Neumerkel schrieb:
>>> The point of using // is to clearly indicate that this
>>> is a nonterminal to be used within a DCG.  Ideally
>>> the name spaces would be different.  But they are
>>> not.  What can be assumed here safely and what not,
>>> is still subject to debate.
>>
>>So we could prevent Prolog texts such as:
>>
>>	inc --> [def].
>>	inc(X,Y) :- Y is X+1.
>>
>>Or
>>
>>	inc --> {def(X,Y)}.
>>	def --> [abc].
>>
>>Which would then be considered errorneous?
>
>Your example touches the delicate questions very directly.
>
>In your example nonterminals and terminals are all
>mixed up.  In most of the situations this is an error,
>but sometimes - very rarely so - it does make sense.
>
>Consider what in grammars is frequently the dollar sign
>which means  at_end//0.  In that particular case,
>an implementation needs to write
>
>at_end([], Xs) :-
>   call(Xs = []).
>
>So such cases should be expressible - somehow.
>
>The current idea is to have call//1 as a nonterminal,
>which expands to call/3.  Coincidentally - all
>implementations perform that expansion already. Even
>those that do not offer call/N.  Providence!
>
>So now, we can write:
>
>at_end_predicate([], Xs) :-
>   call(Xs = []).
>
>at_end -->
>   call(at_end_predicate).
>
>In most situations the extra level of a predicate
>is not needed.  And yes, you can use lambdas for that
>as well:
>
>at_end -->
>   call(\[]^[]^true).

Using library(lambda), the lambda itself is not
even needed in this case! So we can shorten it to:

at_end -->
   call([]^[]^true).

http://www.complang.tuwien.ac.at/ulrich/Prolog-inedit/lambda.pl

Ulrich Neumerkel wrote:
> Joachim Schimpf <jschimpf@users.sourceforge.net> writes:
>> or put the op declaration into the DCG translator.
> 
> How's that possible?

Even if your Prolog system can't do that, the unmentioned part
of my statement still means that DCGs are not an issue:

> You can write portable DCGs with
> semicolons, and you can write your "portable DCG translator" as
> 
> phrase((A;B),I,O) :- phrase(A,I,O); phrase(B,I,O).
> phrase('|'(A,B),I,O) :- phrase(A,I,O); phrase(B,I,O).

I have personally never written a DCG with bars.
And if I had thousands of lines of legacy DCG with unquoted bars,
I'd rather convert a|b to a;b rather than a'|'b.

-- Joachim

On Wed, 16 Jun 2010 09:27:25 +0000, Ulrich Neumerkel wrote:


> E.g. how would the current draft rule out the following translation:
> 
> p --> \+ q.
> 
> into
> 
> p(Xs0,Xs) :- \+ q(Xs0,Xs).  % Incorrect!!
> 
> 

SWI gives

p(A, A) :-
        \+ q(A, _).

while SICStus gives

p(A, B) :-
        (   q(A, _) ->
            fail
        ;   B=A
        ).

Quite different :-(

B-Prolog ... even more different:

p(A, B) :-
        '\\+'(q, A, B).


Cheers

Bart Demoen

Bart Demoen <bmd@cs.kuleuven.be> writes:
>On Wed, 16 Jun 2010 09:27:25 +0000, Ulrich Neumerkel wrote:
>
>
>> E.g. how would the current draft rule out the following translation:
>> 
>> p --> \+ q.
>> 
>> into
>> 
>> p(Xs0,Xs) :- \+ q(Xs0,Xs).  % Incorrect!!
>> 
>> 
>
>SWI gives
>
>p(A, A) :-
>        \+ q(A, _).

No more! I fixed that recently.  Evidently you don't do
"git pull" on a daily basis :-).

p(A, B) :-
   \+ q(A, _),
   B=A.

>while SICStus gives
>
>p(A, B) :-
>        (   q(A, _) ->
>            fail
>        ;   B=A
>        ).
>
>Quite different :-(
>
>B-Prolog ... even more different:
>
>p(A, B) :-
>        '\\+'(q, A, B).

But let us be clear here: While the concrete implementations
in SWI, SICStus and B differ, their actucal behaviour w.r.t
execution of phrase/3 is the same.

What is missing in the current document is a clear descriptioin
that rules out the incorrect translation I suggested and the
incorrect one SWI used to employ.

Joachim Schimpf <jschimpf@users.sourceforge.net> writes:
>Ulrich Neumerkel wrote:
>> Joachim Schimpf <jschimpf@users.sourceforge.net> writes:
>>> or put the op declaration into the DCG translator.
>> 
>> How's that possible?
>
>Even if your Prolog system can't do that, the unmentioned part
>of my statement still means that DCGs are not an issue:

>> You can write portable DCGs with
>> semicolons, and you can write your "portable DCG translator" as
>> 
>> phrase((A;B),I,O) :- phrase(A,I,O); phrase(B,I,O).
>> phrase('|'(A,B),I,O) :- phrase(A,I,O); phrase(B,I,O).
>
>I have personally never written a DCG with bars.

Different "schools".

>And if I had thousands of lines of legacy DCG with unquoted bars,
>I'd rather convert a|b to a;b rather than a'|'b.

You misunderstand here something!

The '|' notation is rather for translators that read such
terms.  Within a DCG and with step 1 and step 2 there is no
need to rewrite your grammar at all!

On Jun 16, 1:50=A0pm, Bart Demoen <b...@cs.kuleuven.be> wrote:
> On Wed, 16 Jun 2010 09:27:25 +0000, Ulrich Neumerkel wrote:
> > E.g. how would the current draft rule out the following translation:
>
> > p --> \+ q.
>
> > into
>
> > p(Xs0,Xs) :- \+ q(Xs0,Xs). =A0% Incorrect!!
>
> SWI gives
>
> p(A, A) :-
> =A0 =A0 =A0 =A0 \+ q(A, _).
>
> while SICStus gives
>
> p(A, B) :-
> =A0 =A0 =A0 =A0 ( =A0 q(A, _) ->
> =A0 =A0 =A0 =A0 =A0 =A0 fail
> =A0 =A0 =A0 =A0 ; =A0 B=3DA
> =A0 =A0 =A0 =A0 ).
>
> Quite different :-(
>
> B-Prolog ... even more different:
>
> p(A, B) :-
> =A0 =A0 =A0 =A0 '\\+'(q, A, B).

The reference implementation in the current draft (well, at least in
the draft *I* edited) gives:

p(A, B) :- q(A, B), A =3D B.

However, the SICStus translation seems preferable in the sense that it
makes calls to p/2 deterministic (since p//0 calls \+/1), while DCGs
draft translation will not if q/2 itself is not deterministic.

Cheers,

Paulo

On Jun 16, 1:51=A0pm, ulr...@mips.complang.tuwien.ac.at (Ulrich
Neumerkel) wrote:
> Bart Demoen <b...@cs.kuleuven.be> writes:
> >On Wed, 16 Jun 2010 09:27:25 +0000, Ulrich Neumerkel wrote:
>
> >> E.g. how would the current draft rule out the following translation:
>
> >> p --> \+ q.
>
> >> into
>
> >> p(Xs0,Xs) :- \+ q(Xs0,Xs). =A0% Incorrect!!
>
> >SWI gives
>
> >p(A, A) :-
> > =A0 =A0 =A0 =A0\+ q(A, _).
>
> No more! I fixed that recently. =A0Evidently you don't do
> "git pull" on a daily basis :-).
>
> p(A, B) :-
> =A0 =A0\+ q(A, _),
> =A0 =A0B=3DA.

Sadly, this and other "fixes" have been siting collecting dust in the
DCGs draft proposal (reference implementation) for some years now.

Cheers,

Paulo

Paulo Moura <pjlmoura@gmail.com> writes:
>On Jun 16, 1:50=A0pm, Bart Demoen <b...@cs.kuleuven.be> wrote:
>The reference implementation in the current draft (well, at least in
>the draft *I* edited) gives:
>
>p(A, B) :- q(A, B), A =3D B.
You mean probably:

p(A, B) :- \+ q(A, B), A = B.
           ^^
Yes.

There is no place in the document that describes the
properties of relevance.  So only the execution of the
reference implementation gives an answer.

And on the page of the current draft (2010-04-01) I read:

http://www.sju.edu/~jhodgson/wg17/Drafts/DCGs/

Reference implementation
    Not part of the proposed ``standard'' but useful

Paulo Moura <pjlmoura@gmail.com> writes:
>On Jun 16, 1:51=A0pm, ulr...@mips.complang.tuwien.ac.at (Ulrich
>Neumerkel) wrote:
>> Bart Demoen <b...@cs.kuleuven.be> writes:
>> >On Wed, 16 Jun 2010 09:27:25 +0000, Ulrich Neumerkel wrote:
>>
>> >> E.g. how would the current draft rule out the following translation:
>>
>> >> p --> \+ q.
>>
>> >> into
>>
>> >> p(Xs0,Xs) :- \+ q(Xs0,Xs). =A0% Incorrect!!
>>
>> >SWI gives
>>
>> >p(A, A) :-
>> > =A0 =A0 =A0 =A0\+ q(A, _).
>>
>> No more! I fixed that recently. =A0Evidently you don't do
>> "git pull" on a daily basis :-).
>>
>> p(A, B) :-
>> =A0 =A0\+ q(A, _),
>> =A0 =A0B=3DA.
>
>Sadly, this and other "fixes" have been siting collecting dust in the
>DCGs draft proposal (reference implementation) for some years now.

Sadly?  SWI is now better.  That's not that sad.

But which other "fixes" are you referring to?

On Jun 16, 2:16=A0pm, ulr...@mips.complang.tuwien.ac.at (Ulrich
Neumerkel) wrote:
> Paulo Moura <pjlmo...@gmail.com> writes:
> >On Jun 16, 1:50=3DA0pm, Bart Demoen <b...@cs.kuleuven.be> wrote:
> >The reference implementation in the current draft (well, at least in
> >the draft *I* edited) gives:
>
> >p(A, B) :- q(A, B), A =3D3D B.
>
> You mean probably:
>
> p(A, B) :- \+ q(A, B), A =3D B.
> =A0 =A0 =A0 =A0 =A0 =A0^^
> Yes.

Correct. Sorry for the typo.

> There is no place in the document that describes the
> properties of relevance. =A0So only the execution of the
> reference implementation gives an answer.
>
> And on the page of the current draft (2010-04-01) I read:
>
> http://www.sju.edu/~jhodgson/wg17/Drafts/DCGs/
>
> Reference implementation
> =A0 =A0 Not part of the proposed ``standard'' but useful

In the latest version of the DCGs draft with me as editor (dated from
May 28, 2010; I received so far no communication that a new editor
have been appointed), available here:

http://logtalk.org/plstd/dcgs.pdf

There is no "Not part of the proposed ``standard'' but useful"
sentence. The draft you refer to dated from April 1, 2010 carries my
name as editor but contains changes that I didn't make. The correct
procedure, would be to *move* my name to the list of previous editors
in page 1 and change the "Editor:" field at the top of the document to
whoever made the changes. Just another WG17 screw-up after the lame
events at Pasadena.

Cheers,

Paulo

Paulo Moura <pjlmoura@gmail.com> writes:
>On Jun 16, 2:16=A0pm, ulr...@mips.complang.tuwien.ac.at (Ulrich
>Neumerkel) wrote:
>> Paulo Moura <pjlmo...@gmail.com> writes:
>> >On Jun 16, 1:50=3DA0pm, Bart Demoen <b...@cs.kuleuven.be> wrote:
>> >The reference implementation in the current draft (well, at least in
>> >the draft *I* edited) gives:
>>
>> >p(A, B) :- q(A, B), A =3D3D B.
>>
>> You mean probably:
>>
>> p(A, B) :- \+ q(A, B), A =3D B.
>> =A0 =A0 =A0 =A0 =A0 =A0^^
>> Yes.
>
>Correct. Sorry for the typo.
>
>> There is no place in the document that describes the
>> properties of relevance. =A0So only the execution of the
>> reference implementation gives an answer.
>>
>> And on the page of the current draft (2010-04-01) I read:
>>
>> http://www.sju.edu/~jhodgson/wg17/Drafts/DCGs/
>>
>> Reference implementation
>> =A0 =A0 Not part of the proposed ``standard'' but useful
>
>In the latest version of the DCGs draft with me as editor (dated from
>May 28, 2010; I received so far no communication that a new editor
>have been appointed), available here:
>
>http://logtalk.org/plstd/dcgs.pdf
>
>There is no "Not part of the proposed ``standard'' but useful"
>sentence. The draft you refer to dated from April 1, 2010 carries my
>name as editor but contains changes that I didn't make. The correct
>procedure, would be ...

Please discuss the personal issues with the persons involved
and not with people that are not involved with it.

From a normative point of view the fundamental problem persists:

SWI(recently), SICStus, B, ISO all use a syntactically different
translation.  Are they the same?  Which aspect is of importance
and which is irrelevant?

In my understanding SWI and SICStus are in a sense equivalent,
but your ISO translation is different.  In your translation:

p(A, B) :- \+ q(A, B), A = B.

the variable B within the negation is handed into.  The other
systems essentially use a fresh new variable.

If we then consider the goal   ?- phrase(p, Xs, []).
we might see a difference somewhere, since in the
ISO case phrase(q, Xs, []) will be called, and in the
other implementations phrase(q, Xs, _) is called.

To cite 11 Reference implementations:

"The reference implementations provided in this section
do not preclude alternative or optimized implementations".

So: What is the normative relevance of the reference
implementation?  What is its exact purpose? What can
it rule out and what not?

On Jun 16, 2:23=A0pm, ulr...@mips.complang.tuwien.ac.at (Ulrich
Neumerkel) wrote:
> Paulo Moura <pjlmo...@gmail.com> writes:
> >On Jun 16, 1:51=3DA0pm, ulr...@mips.complang.tuwien.ac.at (Ulrich
> >Neumerkel) wrote:
> >> Bart Demoen <b...@cs.kuleuven.be> writes:
> >> >On Wed, 16 Jun 2010 09:27:25 +0000, Ulrich Neumerkel wrote:
>
> >> >> E.g. how would the current draft rule out the following translation=
:
>
> >> >> p --> \+ q.
>
> >> >> into
>
> >> >> p(Xs0,Xs) :- \+ q(Xs0,Xs). =3DA0% Incorrect!!
>
> >> >SWI gives
>
> >> >p(A, A) :-
> >> > =3DA0 =3DA0 =3DA0 =3DA0\+ q(A, _).
>
> >> No more! I fixed that recently. =3DA0Evidently you don't do
> >> "git pull" on a daily basis :-).
>
> >> p(A, B) :-
> >> =3DA0 =3DA0\+ q(A, _),
> >> =3DA0 =3DA0B=3D3DA.
>
> >Sadly, this and other "fixes" have been siting collecting dust in the
> >DCGs draft proposal (reference implementation) for some years now.
>
> Sadly? =A0SWI is now better. =A0That's not that sad.

I'm not talking about SWI-Prolog per se or any other single Prolog
implementation.

> But which other "fixes" are you referring to?

Everything that is correct (or deemed correct) in the current draft
and in the reference implementation and is broken in Prolog
implementations of DCGs. And by "Prolog implementations" I mean all
currently available Prolog implementations that include DCGs support,
not just a couple of them. This is not the place to go implementation
by implementation, bug by bug.

Cheers,

Paulo

Paulo Moura <pjlmoura@gmail.com> writes:
>> But which other "fixes" are you referring to?
>
>Everything that is correct (or deemed correct) in the current draft
>and in the reference implementation and is broken in Prolog
>implementations of DCGs. And by "Prolog implementations" I mean all
>currently available Prolog implementations that include DCGs support,
>not just a couple of them. This is not the place to go implementation
>by implementation, bug by bug.

So you are unaware of any other problems in SWI?

On Jun 16, 2:39=A0pm, ulr...@mips.complang.tuwien.ac.at (Ulrich
Neumerkel) wrote:
> Paulo Moura <pjlmo...@gmail.com> writes:
> >On Jun 16, 2:16=3DA0pm, ulr...@mips.complang.tuwien.ac.at (Ulrich
> >Neumerkel) wrote:
> >> Paulo Moura <pjlmo...@gmail.com> writes:
> >> >On Jun 16, 1:50=3D3DA0pm, Bart Demoen <b...@cs.kuleuven.be> wrote:
> >> >The reference implementation in the current draft (well, at least in
> >> >the draft *I* edited) gives:
>
> >> >p(A, B) :- q(A, B), A =3D3D3D B.
>
> >> You mean probably:
>
> >> p(A, B) :- \+ q(A, B), A =3D3D B.
> >> =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0^^
> >> Yes.
>
> >Correct. Sorry for the typo.
>
> >> There is no place in the document that describes the
> >> properties of relevance. =3DA0So only the execution of the
> >> reference implementation gives an answer.
>
> >> And on the page of the current draft (2010-04-01) I read:
>
> >>http://www.sju.edu/~jhodgson/wg17/Drafts/DCGs/
>
> >> Reference implementation
> >> =3DA0 =3DA0 Not part of the proposed ``standard'' but useful
>
> >In the latest version of the DCGs draft with me as editor (dated from
> >May 28, 2010; I received so far no communication that a new editor
> >have been appointed), available here:
>
> >http://logtalk.org/plstd/dcgs.pdf
>
> >There is no "Not part of the proposed ``standard'' but useful"
> >sentence. The draft you refer to dated from April 1, 2010 carries my
> >name as editor but contains changes that I didn't make. The correct
> >procedure, would be ...
>
> Please discuss the personal issues with the persons involved
> and not with people that are not involved with it.

WG17 screw-ups are *community* issues, not personal issues. And a
clear sign that WG17 must be replaced as the main Prolog
standardization venue. But if you want to see this as a personal
issue, I believe I have the right to alert readers that a public
document that you cite is misusing my name.

> From a normative point of view the fundamental problem persists:
>
> SWI(recently), SICStus, B, ISO all use a syntactically different
> translation. =A0Are they the same? =A0Which aspect is of importance
> and which is irrelevant?
>
> In my understanding SWI and SICStus are in a sense equivalent,
> but your ISO translation is different. =A0In your translation:

Not *my* translation but the DCGs draft translation. Even if I
currently use it myself.

> p(A, B) :- \+ q(A, B), A =3D B.
>
> the variable B within the negation is handed into. =A0The other
> systems essentially use a fresh new variable.
>
> If we then consider the goal =A0 ?- phrase(p, Xs, []).
> we might see a difference somewhere, since in the
> ISO case phrase(q, Xs, []) will be called, and in the
> other implementations phrase(q, Xs, _) is called.

Good point. This needs to be sorted out.

> To cite 11 Reference implementations:
>
> "The reference implementations provided in this section
> do not preclude alternative or optimized implementations".
>
> So: What is the normative relevance of the reference
> implementation? =A0What is its exact purpose? What can
> it rule out and what not?

Sounds like good questions for the next WG17 meeting.

Cheers,

Paulo

On Jun 16, 2:57=A0pm, ulr...@mips.complang.tuwien.ac.at (Ulrich
Neumerkel) wrote:
> Paulo Moura <pjlmo...@gmail.com> writes:
> >> But which other "fixes" are you referring to?
>
> >Everything that is correct (or deemed correct) in the current draft
> >and in the reference implementation and is broken in Prolog
> >implementations of DCGs. And by "Prolog implementations" I mean all
> >currently available Prolog implementations that include DCGs support,
> >not just a couple of them. This is not the place to go implementation
> >by implementation, bug by bug.
>
> So you are unaware of any other problems in SWI?

When I find a problem in a Prolog compiler, including SWI-Prolog, I
prefer to send a mail to the developer with a bug report and, if
possible, a suggested solution.

Cheers,

Paulo

Paulo Moura <pjlmoura@gmail.com> writes:
>On Jun 16, 2:39=A0pm, ulr...@mips.complang.tuwien.ac.at (Ulrich
>Neumerkel) wrote:

>> SWI(recently), SICStus, B, ISO all use a syntactically different
>> translation. =A0Are they the same? =A0Which aspect is of importance
>> and which is irrelevant?
>>
>> In my understanding SWI and SICStus are in a sense equivalent,
>> but your ISO translation is different. =A0In your translation:
>
>Not *my* translation but the DCGs draft translation. Even if I
>currently use it myself.
>
>> p(A, B) :- \+ q(A, B), A =3D B.
>>
>> the variable B within the negation is handed into. =A0The other
>> systems essentially use a fresh new variable.
>>
>> If we then consider the goal =A0 ?- phrase(p, Xs, []).
>> we might see a difference somewhere, since in the
>> ISO case phrase(q, Xs, []) will be called, and in the
>> other implementations phrase(q, Xs, _) is called.
>
>Good point. This needs to be sorted out.

How?

Here is one possibility:

Every nonterminal NT can be decorated as  (epsilon, NT, epsilon)
where epsilon//0 is a name not used otherwise and defined
as

epsilon --> [].

In the case p --> \+ q.  this would mean that we
can equally well use p --> epsilon, \+ q, epsilon.

An implementation that exposes here is difference
(what exact difference?) would not be acceptable.

Disclaimer: This is only a try.

On Jun 16, 2:11=A0pm, Paulo Moura <pjlmo...@gmail.com> wrote:
> On Jun 16, 1:50=A0pm, Bart Demoen <b...@cs.kuleuven.be> wrote:
>
>
>
>
>
> > On Wed, 16 Jun 2010 09:27:25 +0000, Ulrich Neumerkel wrote:
> > > E.g. how would the current draft rule out the following translation:
>
> > > p --> \+ q.
>
> > > into
>
> > > p(Xs0,Xs) :- \+ q(Xs0,Xs). =A0% Incorrect!!
>
> > SWI gives
>
> > p(A, A) :-
> > =A0 =A0 =A0 =A0 \+ q(A, _).
>
> > while SICStus gives
>
> > p(A, B) :-
> > =A0 =A0 =A0 =A0 ( =A0 q(A, _) ->
> > =A0 =A0 =A0 =A0 =A0 =A0 fail
> > =A0 =A0 =A0 =A0 ; =A0 B=3DA
> > =A0 =A0 =A0 =A0 ).
>
> > Quite different :-(
>
> > B-Prolog ... even more different:
>
> > p(A, B) :-
> > =A0 =A0 =A0 =A0 '\\+'(q, A, B).
>
> The reference implementation in the current draft (well, at least in
> the draft *I* edited) gives:
>
> p(A, B) :- q(A, B), A =3D B.

As Ulrich already pointed out in this thread, there is a typo above.
The draft translation is, of course:

p(A, B) :- \+ q(A, B), A =3D B.

> However, the SICStus translation seems preferable in the sense that it
> makes calls to p/2 deterministic (since p//0 calls \+/1), while DCGs
> draft translation will not if q/2 itself is not deterministic.

Sorry for the "deterministic" issue non-sense that followed from my
typo.

Cheers,

Paulo

Paulo Moura schrieb:
 > As Ulrich already pointed out in this thread, there is a typo above.
 > The draft translation is, of course:
 >
> p(A, B) :- \+ q(A, B), A = B.

I don't think this is a practically useful
definition. I can give you real world grammars
that use the SWI and SICStus definition and
would not work with the above definition.

Here is an artificial example, we want to
exclude leading zeros in numbers, so "0"
and "123" would be numbers, but for example
"01" not:

   number([X|Y]) --> \+ "0", digit(X), rest(Y).
   number("0") --> "0".
   rest([]) --> [].
   rest([X|Y]) --> digit(X), rest(Y).

The example only works with SWI or SICStus
definition. But with the "logtalk" definition,
the problem is that "0" might consume the
input and fail in the rare case where B is also
instantiated.

Namely if B is not instantiated, i.e. if
it is not bound to a list, then the
definition has the following logical
meaning:

   p(A, B) :- ~exists C q(A, C), A=B

That is since B is not instantiated, it
might be instantiated by q, but loses the
instantiation because of the negation of
failure, amounting to an existential
quantifier.

That B is not instantiated happens often
because of the left right bahviour of prolog
and the definition of conjunction in
DCGs:

    a(X, Y) :- b(X, H), c(H, Y).

So any negation that sits inside a b from
above would have an uninstantied B, because
H is uninstantied in the first place.
If B is instantiated we would have the
following logical meaning:

   p(A, B) :- ~q(A, B), A=B

So phrase(number, "1") will fail. But if
we go from the beginning with the SWI or
SICStus definition, which reads more or
less as follows:

   p(A, B) :- \+ q(A, _), A=B

We will from the beginning have an existential
quantifier for the second argument inside
the negation. Which makes the construct so
useful.

The SWI and SICStus negation in DCGs is
not only practical useful, but it can
also be efficiently be used in bottom up
parsers. Such as chart parsers.

The trick is to build the chart from the
right, so that when we reach \+ all the
necessary information is already available.
The \+ will then behave a little bit strange,
in that it will scan multiple levels, but this
is fine, since in practical application this
is exactly what some times is needed, the
\+ would be deployed when we don't know so
much about the length of the grammatical
category we want to exclude.

If we want to limit the length of the
grammatical category we want to exclude,
we would anyway need other means than
simply the logtalk definition. It would
indeed limit the length if B were instantiated,
but we have seen in the example that A=B would
then destroy everything.

Bye

Ulrich Neumerkel schrieb:
> Please refer to
>
> http://www.sju.edu/~jhodgson/wg17/Drafts/
> http://www.sju.edu/~jhodgson/wg17/Drafts/DCGs/
>

I am just reading on page 13:

	GRBody is a variable
	| instantiation error

Actually a naked GRBody would be translatable
very easily. Suppose I have a grammar rule
as follows:

    bla(Terminals) --> foo, Terminals, bar.

This could be translated as follows:

    bla(Terminals, I, O) :-
       foo(I, H),
       phrase(Terminals, H, J),
       bar(J, O).

But maybe this flexibility is too dangerous.
On the otherhand it would be very symmetric
to certain expansion techniques, techniques
that would derive the expansion from phrase/3.

Has anybody already developped something like
this? So that we have a single source for the
semantics of DCG, or is the other way around
that phrase/3 invokes the expansion?

I have seen SWI Prolog creating some '$append'(..)
for an incomplete terminal sequence. Of course
the trick applies also here:

    bla(Terminals) --> [foo | Terminals]

Could be translated as follows:

    bla(Terminals, I, O) :-
       foo(I, H),
       phrase(Terminals, H, O).

Bye

Jan Burse <janburse@fastmail.fm> writes:
>Ulrich Neumerkel schrieb:
>> Please refer to
>>
>> http://www.sju.edu/~jhodgson/wg17/Drafts/
>> http://www.sju.edu/~jhodgson/wg17/Drafts/DCGs/
>>
>
>I am just reading on page 13:
>
>	GRBody is a variable
>	| instantiation error
>
>Actually a naked GRBody would be translatable
>very easily. Suppose I have a grammar rule
>as follows:
>
>    bla(Terminals) --> foo, Terminals, bar.
>
>This could be translated as follows:
>
>    bla(Terminals, I, O) :-
>       foo(I, H),
>       phrase(Terminals, H, J),
>       bar(J, O).

I assume you are citing on page 13 8.1.1.3 Errors,
subclause a. Yes?

Error a is here for the built-in phrase/3.
Id est:  ?- phrase(G, Xs0,Xs)

shall produce an instantiation error.  Which
seems reasonable to me - in analogy to call(G).

>Has anybody already developped something like
>this?

SWI does it like this.

>I have seen SWI Prolog creating some '$append'(..)
>for an incomplete terminal sequence. Of course
>the trick applies also here:
>
>    bla(Terminals) --> [foo | Terminals]
>
>Could be translated as follows:
>
>    bla(Terminals, I, O) :-
>       foo(I, H),
>       phrase(Terminals, H, O).

Oh no! That's definitely not a good idea!
Mixing the lists and general terminals...

I find even the fact that SWI does not terminate
for the follow program highly undesirable:

a(H,T) --> [H|T].

?- phrase(a(H,T), Xs0,Xs).


I would an error during translation refusing this.
But maybe Jan can enlighten us on the motivation?

Jan Burse schrieb:
> So phrase(number, "1") will fail. But if

Oops, sorry, maybe the above works, on
my own given grounds, because the negation
sits inside a conjunction. Would need
a simpler example, but examples can be
constructed where SWI/SICS and the draft
would show differnt results. But I must
admit they are really border cases.

Bye

On Jun 16, 5:51=A0pm, Jan Burse <janbu...@fastmail.fm> wrote:
> Paulo Moura schrieb:
> =A0> As Ulrich already pointed out in this thread, there is a typo above.
> =A0> The draft translation is, of course:
> =A0>
>
> > p(A, B) :- \+ q(A, B), A =3D B.
>
> I don't think this is a practically useful
> definition. I can give you real world grammars
> that use the SWI and SICStus definition and
> would not work with the above definition.

I agree that the above translation is wrong and the correct one is:

p(A, B) :- \+ q(A, _), A =3D B

or an equivalent definition (as e.g. the one in SICStus Prolog).

> Here is an artificial example, we want to
> exclude leading zeros in numbers, so "0"
> and "123" would be numbers, but for example
> "01" not:
>
> =A0 =A0number([X|Y]) --> \+ "0", digit(X), rest(Y).
> =A0 =A0number("0") --> "0".
> =A0 =A0rest([]) --> [].
> =A0 =A0rest([X|Y]) --> digit(X), rest(Y).

Thanks for the example.

> The example only works with SWI or SICStus
> definition. But with the "logtalk" definition,
> the problem is that "0" might consume the
> input and fail in the rare case where B is also
> instantiated.

I already fixed the bug above in the Logtalk development version
(r5622). But we're not discussing here the Logtalk implementation but
the *DCGs draft reference implementation*. Which I cannot fix. That's
up to WG17.

I must confess that I'm a bit puzzled by this bug. I found DCGs
standardization documents dated from 2005 (e.g ST85N.DOC) where the
correct translation was present both in Logtalk and in some Prolog
compilers.

Cheers,

Paulo

Jan Burse <janburse@fastmail.fm> writes:
>Jan Burse schrieb:
>> So phrase(number, "1") will fail. But if
>
>Oops, sorry, maybe the above works, on
>my own given grounds, because the negation
>sits inside a conjunction. Would need
>a simpler example, but examples can be
>constructed where SWI/SICS and the draft
>would show differnt results. But I must
>admit they are really border cases.

Your intuition is right.  Here is a very tiny exemple:

a --> "a".

na --> \+ a.

naISO(Xs0,Xs) :- \+ a(Xs0,Xs), Xs0 = Xs.

?- phrase(na, "a","a").
false.

?- phrase(naISO, "a","a").
true.

ulrich@mips.complang.tuwien.ac.at (Ulrich Neumerkel) writes:
>Jan Burse <janburse@fastmail.fm> writes:
>>Jan Burse schrieb:
>>> So phrase(number, "1") will fail. But if
>>
>>Oops, sorry, maybe the above works, on
>>my own given grounds, because the negation
>>sits inside a conjunction. Would need
>>a simpler example, but examples can be
>>constructed where SWI/SICS and the draft
>>would show differnt results. But I must
>>admit they are really border cases.
>
>Your intuition is right.  Here is a very tiny exemple:
>
>a --> "a".
>
>na --> \+ a.
>
>naISO(Xs0,Xs) :- \+ a(Xs0,Xs), Xs0 = Xs.
>
>?- phrase(na, "a","a").
>false.
>
>?- phrase(naISO, "a","a").
>true.

It is not only the translation that is incorrect, but
also the "interpreter" in appendix A.  The interpreter
is essentially:

xphrase(\+ G, S0,S) :- \+ xphrase(G, S0,S), S0 = S.
xphrase([C], [C|S],S).

?- phrase(\+"a","a","a").
false.

?- xphrase(\+"a","a","a").
true.


In any case a good example, why depending exclusively
on a reference implementation is not the ideal approach
in a normative context.

To understand this error we had to resort on our "fuzzy"
intuition.  I really would have preferred to resort
on clear algebraic properties in stead.

Ulrich Neumerkel schrieb:
> To understand this error we had to resort on our "fuzzy"
> intuition.  I really would have preferred to resort
> on clear algebraic properties in stead.

Very difficult, since we would not only need
to drop depth-first and resort to something like
breadth first, also we would need some stratification
and fairness. No clue how we could feasibly
depart from a procedural negation as failure.

But maybe we could use another logic, something
like minimal logic. Never tried it for grammars.
In databases minimal logic amounts to having
data base constraints as rules for falsum:

    _|_ :- violation1.

         ...

    _|_ :- violationn.

Now if we ask ~ Query, this is translated to
asking (Query :- _|_), which amounts add adding the
assumption Query, and try to derive _|_. So minimal
logic negation checks whether the state described
by the query violates the database constraints.

Here is an example:

    /* uniqueness constraint on p/1 */
    _|_ :- p(X), p(Y), X\=Y.

    /* we have already something for p/1 */
    p(a).

    ?- ~p(b)
    Yes
    ?- ~p(a)
    No

The query ?- ~p(b), will invoke ?- (p(b) :-
_|_), will add the assumption p(b) to the database
and then derive _|_ and thus succeed. On the
other hand when we add the assumption p(a),
we cannot derive _|_, and thus ?- ~p(a) will fail.

What would this mean for grammars? No clue
right now? Did somebody already apply minimal
logic to grammar rules?

Bye

Ulrich Neumerkel schrieb:
> To understand this error we had to resort on our "fuzzy"
> intuition.  I really would have preferred to resort
> on clear algebraic properties in stead.

Algreba already does ring another bell. In
algebra we sometimes see something like
intersection of two grammars.

So did somebody already find a parallel grammar
conjunction useful? Something like:

   phase(A ',,' B,I,O) :- phrase(A,I,O), phrase(B,I,O). ?

Bye

Jan Burse <janburse@fastmail.fm> writes:
>Ulrich Neumerkel schrieb:
>> To understand this error we had to resort on our "fuzzy"
>> intuition.  I really would have preferred to resort
>> on clear algebraic properties in stead.
>
>Very difficult, since we would not only need
>to drop depth-first and resort to something like
>breadth first, also we would need some stratification
>and fairness. No clue how we could feasibly
>depart from a procedural negation as failure.

What I would like to have is not to define the entire
meaning with some other formalism, but simply certain
properties, that phrase/3 and a grammar have to obey to.

Take steadfastness of phrase/3 in the last argument.

If we have a goal phrase(NT, Xs0,Xs) the following
should hold for all NT, Xs0, Xs:

    phrase(NT, Xs0,Xs) <=> phrase(NT, Xs0, XsC), XsC = Xs

with XsC a fresh new variable.  So if you find
a counterexample to this, we know that our implemtation
is wrong.

Similarly, it should be possible to introduce in any
place in a grammar an epsilon//0 without affecting
the grammar.

I like such properties much more than a complete
semantics that is suceptible to the same problems
as concrete implementations.  The biggest advantage
is that counterexamples happen to be very very short
and readable.

Ulrich Neumerkel schrieb:
> Take steadfastness of phrase/3 in the last argument.
>
> If we have a goal phrase(NT, Xs0,Xs) the following
> should hold for all NT, Xs0, Xs:
>
>      phrase(NT, Xs0,Xs)<=>  phrase(NT, Xs0, XsC), XsC = Xs
>
> with XsC a fresh new variable.  So if you find
> a counterexample to this, we know that our implemtation
> is wrong.

Ok, I understand. Some program properties.

I was always wondering why the grammar rules in DEC10
where called DCG and were only a very small subset,
no negation etc.. Really logically only ; and ,.
Although DEC10 has cut and everything.

DCG is acronym for *definite" clause grammars. If I
take the adjective *definite* as in J.W.Lloyds definition
of different logic programming classes, then this means
recursive but no negation at all.

Well if there is no negation at all, a lot of
program properties are automatically granted.

Actually the DCG proposal should be renamed to grammar
rules proposal. The adjective *definite* should be
removed from the vocabulary in connection with Prolog
grammar rules.

Bye

On Wed, 16 Jun 2010 12:51:31 +0000, Ulrich Neumerkel wrote:

> No more! I fixed that recently.  Evidently you don't do "git pull" on a
> daily basis :-).

I do have a life !

> But let us be clear here: While the concrete implementations in SWI,
> SICStus and B differ, their actucal behaviour w.r.t execution of
> phrase/3 is the same.

That is a very strong statement - I trust you have a certificate of that statement ?

Cheers

Bart Demoen

bart demoen <bmd@cs.kuleuven.be> writes:
>On Wed, 16 Jun 2010 12:51:31 +0000, Ulrich Neumerkel wrote:
>
>> No more! I fixed that recently.  Evidently you don't do "git pull" on a
>> daily basis :-).
>
>I do have a life !
>
>> But let us be clear here: While the concrete implementations in SWI,
>> SICStus and B differ, their actucal behaviour w.r.t execution of
>> phrase/3 is the same.
>
>That is a very strong statement - I trust you have a certificate of that statement ?

If you cite my statement without the actual context, it is in fact
a very strong statement - that even tends to be wrong:  Currently,
B does not seem to have an implementation for (\+)//1.

But my statement was just referring to the translations you showed
for the rule

p --> \+ q.

And there, all three translations did not show any defect.

On Mon, 14 Jun 2010 12:47:19 +0000, Ulrich Neumerkel wrote:

> Here is a small issue that is currently of interest due to the focus on
> DCGs:
> 
> http://www.complang.tuwien.ac.at/ulrich/iso-prolog/3steps

I think I lost track of the essence of all this.
It seems that the proposal implies that

	| is not always the same as '|'

That would make | veeeery special: I can't recall any other character
that has this property - getting the advice to read the fineprint 
in the standard would be most unhelpful for me and probably for most other
eager Prolog users.

Progress in this area should also mean simplification: it is one of the 
strengths of Prolog that it has a simple syntax, a syntax that is the 
same at the object and the meta-level. Arbitrary exceptions to simple 
rules better be abandoned, and new exceptions should not be allowed.

In the past, some systems made the mistake to replace | by ; in some 
contexts, well, too bad for them but let the Prolog language and
community not be burdened with the consequences anymore.

Cheers

Bart Demoen

bart demoen <bmd@cs.kuleuven.be> writes:
>On Mon, 14 Jun 2010 12:47:19 +0000, Ulrich Neumerkel wrote:
>
>> Here is a small issue that is currently of interest due to the focus on
>> DCGs:
>> 
>> http://www.complang.tuwien.ac.at/ulrich/iso-prolog/3steps
>
....
>In the past, some systems made the mistake to replace | by ; in some 
>contexts, well, too bad for them but let the Prolog language and
>community not be burdened with the consequences anymore.

If all three steps are implemented, we would have exactly the
situation you describe.

But what, if we do not reach consenus here?  In fact, I already
received very determined resistance!

If that resistance continues it would be still better if step 1
and step 2 would be codified.  That's not the very perfect
world.  But it is much better to take two steps than to take none.

For most users of DCGs having only step 1 and step 2 would be
perfect anyway.  CHR users would be best served with all 3 steps
present.

On Wed, 16 Jun 2010 20:10:01 +0000, Ulrich Neumerkel wrote:


> For most users of DCGs having only step 1 and step 2 would be perfect
> anyway.  CHR users would be best served with all 3 steps present.

CHR users should not be taken into account for a Prolog standard.
Come to think of it, DCG users shouldn't either. DCG is evil and a historical
incident. Letting ISO Prolog be influenced too much by either is wrong.

But to get back to CHR: nothing essential would change to CHR if the | would
be replaced by ... what is commit represented by in Prolog, ah, yes, it is !

Cheers

Bart Demoen

bart demoen <bmd@cs.kuleuven.be> writes:
>On Wed, 16 Jun 2010 20:10:01 +0000, Ulrich Neumerkel wrote:
>> For most users of DCGs having only step 1 and step 2 would be perfect
>> anyway.  CHR users would be best served with all 3 steps present.
>
>CHR users should not be taken into account for a Prolog standard.
>Come to think of it, DCG users shouldn't either. DCG is evil and a historical
>incident. Letting ISO Prolog be influenced too much by either is wrong.

I can only regret such reactions.  You do know that for years
DCGs are codified.  So far, the documents do not cover ('|')//2
at all, even if it is used by quite some.  I try to change
that.  And looking at the same time into the direction of extensions
where we can anticipate syntactical collisions due to other uses of
the |.  And that is CHRs.

>But to get back to CHR: nothing essential would change to CHR if the | would
>be replaced by ... what is commit represented by in Prolog, ah, yes, it is !

I beg to differ.  If you use ! in place of | as an operator in ISO
Prolog, then you would have to write in place of  p :- !, q.
rather p :- (!), q.

Let me express my hope that you will reconsider your position.  People
often critisize that WG17 is not moving fast enough.  We could change
that a bit.  But we need a constructive atmosphere.

On Wed, 16 Jun 2010 21:32:22 +0000, Ulrich Neumerkel wrote:


>>But to get back to CHR: nothing essential would change to CHR if the |
>>would be replaced by ... what is commit represented by in Prolog, ah,
>>yes, it is !
> 
> I beg to differ.  If you use ! in place of | as an operator in ISO
> Prolog, then you would have to write in place of  p :- !, q. rather p :-
> (!), q.

I didn't mean to use ! as an operator - that would be real silly.
I meant to write

X=<Y <=> X=Y, !, something. 

instead of

X=<Y <=> X=Y | something. 

Cheers

Bart Demoen

Bart Demoen wrote:
> I didn't mean to use ! as an operator - that would be real silly.
> I meant to write
>
> X=<Y <=>  X=Y, !, something.
>
> instead of
>
> X=<Y <=>  X=Y | something.
>
> Cheers

That is really funny, why not:

   X =< Y <=> X=Y -> something.

So |/2 would be synonymous for ->/2.

Bye

On Fri, 18 Jun 2010 14:37:27 +0200, Jan Burse wrote:

> Bart Demoen wrote:
>> I didn't mean to use ! as an operator - that would be real silly. I
>> meant to write
>>
>> X=<Y <=>  X=Y, !, something.
>>
>> instead of
>>
>> X=<Y <=>  X=Y | something.
>>
>> Cheers
> 
> That is really funny, why not:
> 
>    X =< Y <=> X=Y -> something.

Fine with me - lots of things are fine, except making strange decisions for
| versus '|' based on an accidental CHR syntax


> So |/2 would be synonymous for ->/2.

I hope you meant replacement instead of synonymous: it is the synonyme
thing that got us into this mud :-(

Cheers

Bart Demoen

Jan Burse schrieb:
> I have seen SWI Prolog creating some '$append'(..)
> for an incomplete terminal sequence. Of course
> the trick applies also here:
>
>     bla(Terminals) --> [foo | Terminals]
>
> Could be translated as follows:
>
>     bla(Terminals, I, O) :-
>        foo(I, H),
>        phrase(Terminals, H, O).

Practially this is also seen here (a test case):

http://www.sju.edu/~jhodgson/wg17/GRIND.TXT

expand(( a(15)-->[abc|xyz] ),
    (a(15,_1361,_1362):-'C'(_1361,abc, T2),xyz( T2,_1362))).

But it is than later excluded in the SICStus test cases.

LoL

Bye

On 16 Juni, 22:09, bart demoen <b...@cs.kuleuven.be> wrote:
> On Mon, 14 Jun 2010 12:47:19 +0000, Ulrich Neumerkel wrote:
> > Here is a small issue that is currently of interest due to the focus on
> > DCGs:
>
> >http://www.complang.tuwien.ac.at/ulrich/iso-prolog/3steps
>
> I think I lost track of the essence of all this.
> It seems that the proposal implies that
>
> =A0 =A0 =A0 =A0 | is not always the same as '|'
>
> That would make | veeeery special: I can't recall any other character
> that has this property - getting the advice to read the fineprint
> in the standard would be most unhelpful for me and probably for most othe=
r
> eager Prolog users.
>
> Progress in this area should also mean simplification: it is one of the
> strengths of Prolog that it has a simple syntax, a syntax that is the
> same at the object and the meta-level. Arbitrary exceptions to simple
> rules better be abandoned, and new exceptions should not be allowed.
>
> In the past, some systems made the mistake to replace | by ; in some
> contexts, well, too bad for them but let the Prolog language and
> community not be burdened with the consequences anymore.
>
> Cheers
>
> Bart Demoen

Some people have existing code that uses the | syntax, but let's not
be burdened by legacy code :->

The availability of | as an alternative to ; is mentioned in
textbooks; witness The Craft of Prolog by RAOK.
--Mats

Mats Carlsson <matsc@sics.se> writes:
>On 16 Juni, 22:09, bart demoen <b...@cs.kuleuven.be> wrote:
>> On Mon, 14 Jun 2010 12:47:19 +0000, Ulrich Neumerkel wrote:
>> > Here is a small issue that is currently of interest due to the focus on
>> > DCGs:
>>
>> >http://www.complang.tuwien.ac.at/ulrich/iso-prolog/3steps
>>  | is not always the same as '|'
>>
>> That would make | veeeery special: I can't recall any other character
>> that has this property - getting the advice to read the fineprint
>> in the standard would be most unhelpful for me and probably for most othe=

>Some people have existing code that uses the | syntax, but let's not
>be burdened by legacy code :->
>
>The availability of | as an alternative to ; is mentioned in
>textbooks; witness The Craft of Prolog by RAOK.

My attempt here is to create as much harmony as possible.
By taking the first two steps we would solve portability
problems for all code pertaining to DCGs.

Only translators would have to be aware of the presence of (;)/2
and ('|')/2.  Since the translator is usually provided by
the implementor this cannot be such big a trouble.

That would be much better than what we have now.

But, indeed, it would not be perfect.  Isn't going two steps
not better than not moving at all?

Bart Demoen <bmd@cs.kuleuven.be> writes:
>On Wed, 16 Jun 2010 21:32:22 +0000, Ulrich Neumerkel wrote:
>
>
>>>But to get back to CHR: nothing essential would change to CHR if the |
>>>would be replaced by ... what is commit represented by in Prolog, ah,
>>>yes, it is !
>> 
>> I beg to differ.  If you use ! in place of | as an operator in ISO
>> Prolog, then you would have to write in place of  p :- !, q. rather p :-
>> (!), q.
>
>I didn't mean to use ! as an operator - that would be real silly.
>I meant to write
>
>X=<Y <=> X=Y, !, something. 
>
>instead of
>
>X=<Y <=> X=Y | something. 

Do you really believe that this would be an option for
CHR developers?