Gap in Section 7.6.2 and some Insecurity Arising from it

[Jan Burse]

Dear All

Section 7.6.2 of the ISO standard defines
"Converting a term to the body of a clause".
But it only covers the following meta predicates
with goal arguments:

(,)/2
(;)/2
call/l
catch/3

In particular section 7.6.2 a) requires that
a naked variable X is converted into a
callable call(X).

Now here is a funny example from some
existing Prolog system:

| ?- call((Z=!, a(X), Z)).
Z = !
X = 1 ?;
Z = !
X = 2
yes
| ?- findall(Z-X,call((Z=!, a(X), Z)),L).
L = [!-1]

I guess the first query does what already
the examples in 7.8.3.4 suggests:

Succeeds, unifying X with 1, and Z with !. On
re-execution, succeeds, unifying X with 2, and
Z with !. On re-execution, fails.
[This behaviour arises because the argument
of call/l is converted to a goal before it is executed,
and 'Z' becomes the goal 'call(Z)', and is executed as
as 'call(!)' which is equivalent to true.]

And eventually the findall/3 is missing the
conversion of Z into call(Z). Which is not
explicitly mandated by ISO.

Shouldn't ISO implicitly mandate that the second
argument of findall/3 is also converted?

Bye

[bart demoen]

On Fri, 04 Nov 2011 22:44:27 +0100, Jan Burse wrote:


> Now here is a funny example from some existing Prolog system:

No, it is not funny.

Please tell us which sysytem - it is not SICStus, not SWI, not hProlog
[just naming the systems I trust AND just checked]

PLEASE, DO NOT ALARM THIS NEWSGROUP ABOUT "FUNNY" RESULTS

WITHOUT

TELLING US WHICH SYSTEM CAUSED THE RESULTS

and without a good reason to spread the word that "hey, some
Prolog systems do not react as I expected" because you are not
the one to set the trend.

It is probably Yap (which as I can check implements it wrongly)

After a long time without any postings in comp.lang.prolog, I was really
looking forward to something good, but unfortunately, it was JB with a
new post :-(

Difficult to be more detrimental and non-constructive to LP than JB ?
Right :-(

Please JB, go away, go to some other newsgroup or language and cause
havoc there.




--- Posted via news://freenews.netfront.net/ - Complaints to ne...@netfront.net ---

[Jan Burse]

bart demoen schrieb:

> PLEASE, DO NOT ALARM THIS NEWSGROUP ABOUT "FUNNY" RESULTS

I wasn't alarming the newsgroup about some Prologsystem
working wrongly. Prologsystems might have reasons to work
differently from ISO. I was asking the following question:

> Shouldn't ISO implicitly mandate that the second
> argument of findall/3 is also converted?

Do you have something to contribute on that? Then please
let us know. If you have some aversion against me, then
write me at janb...@fastmail.fm and tell me f2f.

Bye

[Jan Burse]

bart demoen schrieb:
> It is probably Yap

Could you tell us more why you think it is Yap.
Does it exactly reproduce the example I gave?

Bye

[bart demoen]

Just so that people in this newsgroup know, I got the following "threat"
from JB by private email:

If you continue with this B.S. I will write an official letter
to your institution and deposit a contestation. I will just
copy paste what you have written.


And to answer his question: I did not check whether Yap "exactly"
reproduces the example JB gave, but

1) Yap gave that answer - perhaps not in the same literally, lexical
form, I didn't care to check its answer char by char - still,
it was the gist of Yap's answer

2) I wrote "probably", for the same reasons as in 1)


Please, can JB disappear from this newsgroup ?

Has anybody else noticed how unproductive and unpleasant
comp.lang.prolog has become since JB showed up ?

Other newsgroups have their nuisances (not to say trolls), and
comp.lang.prolog has been mostly spared of them ... can we keep it
the old way ?

One more time: JB, please leave this building !

Bart Demoen

[Paulo Moura]

On Nov 4, 9:44 pm, Jan Burse <janbu...@fastmail.fm> wrote:
> Dear All
>
> Section 7.6.2 of the ISO standard defines
> "Converting a term to the body of a clause".
> But it only covers the following meta predicates
> with goal arguments:
>
>     (,)/2
>     (;)/2
>     call/l
>     catch/3
>
> In particular section 7.6.2 a) requires that
> a naked variable X is converted into a
> callable call(X).
>
> Now here is a funny example from some
> existing Prolog system:
>
>      | ?- call((Z=!, a(X), Z)).
>      Z = !
>      X = 1 ?;
>      Z = !
>      X = 2
>      yes
>      | ?- findall(Z-X,call((Z=!, a(X), Z)),L).
>      L = [!-1]

Sounds like you found a bug. I would not use the word "funny". Which
Prolog system(s) and version(s)? Simply writing "some existing Prolog
system" is not really useful.

> I guess the first query does what already
> the examples in 7.8.3.4 suggests:
>
>      Succeeds, unifying X with 1, and Z with !. On
>      re-execution, succeeds, unifying X with 2, and
>      Z with !. On re-execution, fails.
>      [This behaviour arises because the argument
>      of call/l is converted to a goal before it is executed,
>      and 'Z' becomes the goal 'call(Z)', and is executed as
>      as 'call(!)' which is equivalent to true.]
>
> And eventually the findall/3 is missing the
> conversion of Z into call(Z). Which is not
> explicitly mandated by ISO.
>
> Shouldn't ISO implicitly mandate that the second
> argument of findall/3 is also converted?

I wonder if that's really necessary. I doubt it. Btw, using Logtalk
2.43.2 with *any* compatible back-end Prolog compiler:

?- logtalk::assertz(a(1)).
yes
?- logtalk::assertz(a(2)).
yes
?- logtalk << call((Z=!, a(X), Z)).
X = 1,
Z = ! ? ;

X = 2,
Z = !
?- logtalk << findall(Z-X,call((Z=!, a(X), Z)),L).
L = [!-1,!-2]
?-

Cheers,

Paulo

[Jan Burse]

Paulo Moura schrieb:

> Sounds like you found a bug. I would not use the word "funny". Which
> Prolog system(s) and version(s)? Simply writing "some existing Prolog
> system" is not really useful.

I am currently in the process of running my ~700 test
cases against a number of Prolog systems. But I have
not yet completed this process. So I have found one
Prolog system with this problem. But at the end of the
day I might find more Prolog systems.

I didn't want to mention just one Prolog system when
it could be that other Prolog systems have the same
problem or similar problems.

Dict.leo.org gives one german translation for funny
that reads "seltsam". My intention was to use in with
this meaning. The German word "seltsam" is close to
the English "strange". I am usually using the word
with this meaning in the context of Prolog.

I didn't mean by "funny" some like "facetious" or
some such. This was used by B. Dameon for his disgraceful
mobbing. But everybody is free to jump on his band-
wagon and distract from the subject matter. On my
side I am very patient and can easily clarify each
B.S. from B.D. now and in the future.

Bye

[k...@kymhorsell.com]

Jan Burse <janb...@fastmail.fm> wrote:
> bart demoen schrieb:
>> It is probably Yap
> Could you tell us more why you think it is Yap.

...

The Law of Hasty Induction. :)

--
As the North magnetic pole and its sub surface molten iron core
move across the North Pole towards Siberia from Canada we
will see climatic changes - in fact the only reason there is climatic
change in the Northern Hemisphere.
-- noon...@microsoft.com[aka 121.222.249.219], 07 Aug 2011 06:02 EST

[Jan Burse]

Jan Burse schrieb:

> I didn't mean by "funny" some like "facetious" or
> some such. This was used by B. Dameon for his disgraceful
> mobbing.

I even have an excel with the following name:

funny_test_cases_2010_12_02.xls

It had around ~50 test cases in it. But most of
them are resolved.

Bye

[k...@kymhorsell.com]

Jan Burse <janb...@fastmail.fm> wrote:
> Jan Burse schrieb:
>> I didn't mean by "funny" some like "facetious" or
>> some such. This was used by B. Dameon for his disgraceful
>> mobbing.
> I even have an excel with the following name:

...

Just ignore it. People threatining you professionally over one word
usually go into the "kook" file at the relevant establishment, let
alone over a matter like a word that has several innocuous interpretations. :)

The number of times someone has written a supposed employer (so far
the "hit" ratio has been less than 10% -- but that follows from
the population from which the sample is drawn :) complaining their work
or (in 2 cases) their father's work has been made to look foolish by
something I've written must run into the dozen or so.

As I said, usually filed in the circular cabinet and reflects badly on
the originator.

It may be illuminating to do a little reading on extroverted thinking
personality types (usuaully under "personology" or "neo-Jungian
personality types" or somesuch on Google) and what some have called
"the frankenstein complex" or "fallah stage" characterised by degradation
of creativity (not a strong point of ET anyway) and associated angry
outbursts of frustration.

Yes, I was a practicing psychiatrist (*) a couple decades back.

Not that there's anything wrong with that. :)

(*) And introverted thinking (IT) personality with overtones of overcompensation :) .

--
Scientists are always changing their story and as a Conservative, I
have no tolerance for ambiguity. It proves that all science is lies
and the only thing we can trust is right wing rhetoric.
-- BONZO@27-32-240-172 [daily nymshifter], 14 Jan 2011 14:46 +1100

[Jan Burse]

Hi,

It is tempting to psychologize, but I have no ambition.

Bye

k...@kymhorsell.com schrieb:

[k...@kymhorsell.com]

Jan Burse <janb...@fastmail.fm> wrote:
> Hi,
> It is tempting to psychologize, but I have no ambition.
> Bye

...

OK, we'll stick with the behavioral therapy. ;)

--
[When complaining loudly about someone's arithmetic:]
"Androcles" <Headm...@Hogwarts.physics_ae>, 30 Dec 2010 10:53 UTC:
> Einstein's calculation is tau = t * sqrt(1-v^2/c^2),
> ref: http://www.fourmilab.ch/etexts/einstein/specrel/www/figures/img61.gif
> 2.2usec * sqrt(1-0.999^2) = 0.098362 usec
> and NOT the measured 64 usec [~= 2.2/sqrt(1-.999^2) -ed].
You have got t and tau around the wrong way.
-- Peter Webb, 31 Dec 2010
The only error is Einstein's, you snipping ignorant cunt.
-- "Androcles" <Headm...@Hogwarts.physics_2011j>, 07 Jan 2011 04:20 UTC

[Chip Eastham]

I'd like to second Bart's request that the Prolog implementation be named.

Certainly there _may_ be other implementations with this or other
funny/peculiar behavior, but if Jan B. knows a specific one, it
should be a bug report for that one, yes?

Anyway I checked against a fairly old version of Amzi! Prolog,
version 7.6.9 (current version is 9.5 something), where for the
sake of a quick test I just defined a(1). a(2). a(3).


Also I ran in interpreted mode, a distinction that not
infrequently needs to be made in bug reports.

?- call((Z=!, a(X), Z)).

Z = !

X = 1 ;
no

As to the second part of Jan B's test, in Amzi!
the query findall(Z-X,call((Z=!,a(X),Z)),L)
returns an empty list L.

I attribute this to a weakness in Amzi!'s handling
of compound goals in the second argument of findall.
If I explicitly define a predicate for the purpose:

burse(Z,X) :- Z=!, a(X), Z.

then the result of findall(Z-X,burse(Z,X),L) is
L = [!-1], consistent with the first part of
Jan B's test.

regards, chip

[Jan Burse]

Chip Eastham schrieb:
> Certainly there_may_ be other implementations with this or other

> funny/peculiar behavior, but if Jan B. knows a specific one, it
> should be a bug report for that one, yes?

I have already issued a bug report to the vendor of the
prolog system. But I repeat myself the question was and
still is in my post as follows:

> Shouldn't ISO implicitly mandate that the second
> argument of findall/3 is also converted?

Now if I recall, a few weeks ago, I think Ulrich Neumerkel
hinted something in the thread "ISO Section 7.6 Converting
..., known Gap?", but discussion quickly went away from
findall/3 to setof/3 and bagof/3.

The teste case is not my invention, it is found in
verbatim ISO 7.8.3.4. So attribution to me is not necessary,
by accident I put it into a findall/3 so that I can check
for the redo result, and thus spotted the problem.

Bye

[Jan Burse]

Hi Chip,

BTW: The following XXX-Prolog result is not ISO compliant:

?- call((Z=!, a(X), Z)).

Z = !
X = 1 ;
no

In the ISO document we have exactly for the above test
case the following output description including the []
comment which is also from the ISO document:

ISO 7.8.3.4:
a(1).
a(2).

call((Z=!, a(x), Z))

Succeeds, unifying X with 1, and Z with !. On
re-execution, succeeds, unifying X with 2, and
Z with !. On re-execution, fails.
[This behaviour arises because the argument
of call/l is converted to a goal before it is executed,
and 'Z' becomes the goal 'call(Z)', and is executed as
as 'call(!)' which is equivalent to true.]

Bye

Chip Eastham schrieb:

[Ulrich Neumerkel]

Jan Burse <janb...@fastmail.fm> writes:
>And eventually the findall/3 is missing the

>conversion of Z into call(Z). ...

The conversion for findall/3 is present in 13211-1, it is thus not missing.

>Shouldn't ISO implicitly mandate that the second
>argument of findall/3 is also converted?

ISO does this already.

The description of findall(Template, Goal, Instances) does
use call(Goal). Please refer to 8.10.1.1 b which reads:

b) Executes call(Goal),

Therefore, the conversion of 7.6.2 does take place at this step.

For such reasons it is important to state that call(Goal) is
executed and not Goal alone which would be ambiguous as for 7.6.2.


Generally speaking, this group would benefit from reports of progress
towards ISO from Jekejeke and other systems. Letting people guess
about errors in "another" system is not funny.

[Jan Burse]

Ulrich Neumerkel schrieb:

> ISO does this already.
>
> The description of findall(Template, Goal, Instances) does
> use call(Goal). Please refer to 8.10.1.1 b which reads:
>
> b) Executes call(Goal),

Hi Ulrich,

Is this already enough for the example at hand?
The example has already a call/1 wrapped around
the findall goal. Namely the query reads:

| ?- findall(Z-X,call((Z=!, a(X), Z)),L).
L = [!-1]

The rules (table 21 and table 22) for the
execution of call/1 in 7.8.3 then say that
we should go from:

Table 21: Before
call(G)

Table 22: After
G
call(G)

But we don't have a G' in table 22, where G'
would be the converted goal G.

So the idea is probably not to dynamically
invoke the conversion 7.6.2 of a term to a
body of a clause in call/1. The assumption
for 7.8.3 is probably that this conversion
is already done.

If this assumption is true, then for
findall/3 a conversion either during
the conversion of a clause (7.6.2) or
during the execution of findall (8.10.1)
would be necessary.

This conversion is not explicitly mentioned,
but it is probably common sense. If the
point of conversion is left open to the
implementor, i.e. clause or execution,
then we might get different results in
assert/retract across Prologsystems.

Bye

[Jan Burse]

Ulrich Neumerkel schrieb:

> Generally speaking, this group would benefit from reports of progress
> towards ISO from Jekejeke and other systems. Letting people guess
> about errors in "another" system is not funny.

It should be possible to intellectually deal with
the following example:

| ?- call((Z=!, a(X), Z)).
Z = !
X = 1 ?;
Z = !
X = 2
yes
| ?- findall(Z-X,call((Z=!, a(X), Z)),L).
L = [!-1]

Without the need to specify either the Prolog system,
neither its release number nor whether it is compiled
or interpreted. The above examples has a ?- in front,
so that everything should be clear.

(Only problem is that ISO does not define a query
answer loop, so hidden assumption here is that a
query is treated as a clause body)

And no, the example is not from Jekejeke. I am really
astonished how a dumb comment of one person can
draw a couple of people into dumbness. This dumb
comment of this one person practically spoiled my
weekend and it seems to further spoil the week.

Bye

[Jan Burse]

Ulrich Neumerkel schrieb:
> b) Executes call(Goal),

I wrote:

> So the idea is probably not to dynamically
> invoke the conversion 7.6.2 of a term to a
> body of a clause in call/1. The assumption
> for 7.8.3 is probably that this conversion
> is already done.

Or that this conversion is done again
especially where the body was converted
to call(X) with X a variable.

Guess we can construct examples that would
not work correctly without this provisio.

Bye

[Paulo Moura]

On Nov 8, 7:48 am, Jan Burse <janbu...@fastmail.fm> wrote:
> Ulrich Neumerkel schrieb:
>
> > Generally speaking, this group would benefit from reports of progress
> > towards ISO from Jekejeke and other systems.  Letting people guess
> > about errors in "another" system is not funny.
>
> It should be possible to intellectually deal with
> the following example:
>
>      | ?- call((Z=!, a(X), Z)).
>      Z = !
>      X = 1 ?;
>      Z = !
>      X = 2
>      yes
>      | ?- findall(Z-X,call((Z=!, a(X), Z)),L).
>      L = [!-1]
>
> Without the need to specify either the Prolog system,
> neither its release number nor whether it is compiled
> or interpreted. The above examples has a ?- in front,
> so that everything should be clear.

One thing that's clear above is that you found inconsistent behavior
in a Prolog system. A way to deal with inconsistencies is to ask for
more information. Bart, me, Chip, and Ulrich, all asked for
disclosure of the details of the system affected. You're are still
withholding that information. Let's see:

$ bp
B-Prolog Version 7.6b5, All rights reserved, (C) Afany Software
1994-2011.

This edition of B-Prolog is for evaluation, learning, and non-profit
research purposes only, and a license is needed for any other uses.
Please visit http://www.probp.com/license.htm for the detail.


Type 'help' for usage.
| ?- assertz(a(1)),
assertz(a(2)).

yes

| ?- call((Z=!, a(X), Z)).
Z = !
X = 1 ?;
Z = !
X = 2
yes
| ?- findall(Z-X,call((Z=!, a(X), Z)),L).
L = [!-1]

yes
| ?-

Btw, Neng-fa, B-Prolog author, both publicly and privately, always
welcomes bug reports and is always eager (in my personal experience)
to fix and improve B-Prolog. Of course, you may be talking about some
other Prolog system. For example:

$ cxprolog
CxProlog version 0.97.5

[main] ?- assertz(a(1)), assertz(a(2)).
yes

[main] ?- call((Z=!, a(X), Z)).

Z = !
X = 1 ? ;

no

[main] ?- findall(Z-X,call((Z=!, a(X), Z)),L).
Z = _G37
X = _G38
L = [!-1] ? ;
no

In this case, the inconsistency found on B-Prolog is not present. Like
Neng-Fa, Artur Miguel Dias, the author of CxProlog, also welcomes bug
reports.

I could go on, testing every single Prolog system and Prolog version
that I have installed in my laptop (both in its native operating-
systems and on the operating-systems I'm running under virtualization)
but I don't have the time.

> (Only problem is that ISO does not define a query
> answer loop, so hidden assumption here is that a
> query is treated as a clause body)
>
> And no, the example is not from Jekejeke. I am really
> astonished how a dumb comment of one person can
> draw a couple of people into dumbness. This dumb
> comment of this one person practically spoiled my
> weekend and it seems to further spoil the week.

And you don't find dumb and insulting replying to simple requests of
full disclosure of the information that you're withholding by (1)
persisting in that attitude and (2) saying that others should be able
to "intellectually deal" (sic) with your example without such
information? Sigh. You're cornering yourself.

Paulo

[Jan Burse]

Paulo Moura wrote:
> Btw, Neng-fa, B-Prolog author, both publicly and privately, always
> welcomes bug reports and is always eager (in my personal experience)
> to fix and improve B-Prolog.

I can confirm this. That is also why I wrote (05.11.2011 13:13):
> I have already issued a bug report to
> the vendor of the prolog system.

Paulo Moura wrote:
> And you don't find dumb and insulting replying to simple requests of
> full disclosure of the information that you're withholding by (1)
> persisting in that attitude and (2) saying that others should be able
> to "intellectually deal" (sic) with your example without such
> information? Sigh. You're cornering yourself.

What did you gain now that you know XXX-Prolog does
have this problem and YYY-Prolog does not have this
problem? Any insight so far? Nothing yet.

You have to work with the text body of the standard.
Basically my post was not a bug report, for this
purpose I can directly go to the vendor, I don't need
to waste comp.lang.prolog.

So basically I wanted to venture into what can be
called "paper refinement". The only person so far who
was able to respond to this was Ulrich Neumerkel.

Paulo Moura wrote:
> I could go on, testing every single Prolog system
> and Prolog version that I have installed in my laptop

> (both in its native operatingsystems and on the

> operating-systems I'm running under virtualization)
> but I don't have the time.

Nobody is asking this from you. Better fetch a copy
of the ISO standard and start "thinking". I hope
you hear the bell ringing now.

Best Regards

[Ulrich Neumerkel]

Jan Burse <janb...@fastmail.fm> writes:
>Ulrich Neumerkel schrieb:
>> ISO does this already.
>>
>> The description of findall(Template, Goal, Instances) does
>> use call(Goal). Please refer to 8.10.1.1 b which reads:
>>
>> b) Executes call(Goal),
>
>Hi Ulrich,
>
>Is this already enough for the example at hand?
>The example has already a call/1 wrapped around
>the findall goal. Namely the query reads:
>
> | ?- findall(Z-X,call((Z=!, a(X), Z)),L).
> L = [!-1]
>
>The rules (table 21 and table 22) for the
>execution of call/1 in 7.8.3 then say that
>we should go from:
>
>Table 21: Before
> call(G)
>
>Table 22: After
> G
> call(G)
>
>But we don't have a G' in table 22, where G'
>would be the converted goal G.

In 7.8.3.1 Description of call/1, we have step f

f) Else convert the term G to a goal goal (7.6.2).

and later

h) Push (goal, NN) on to currentgoal of CCS.

Thus, the conversion takes place.

I agree with you that this is not consistent with
Table 22. There, the entry should read:

N+1 ((goal, N-1), ...) sigma nil
^^^^ new

So, yes that's a good thing for the next corrigendum!
Maybe there are more cases like that.

There has been quite some changes between CD1 (N92) and the
IS. For the sake of curiosity, N92 demanded that resatisfying
a call is like fail ...

[Jan Burse]

Ulrich Neumerkel schrieb:

> In 7.8.3.1 Description of call/1, we have step f
>
> f) Else convert the term G to a goal goal (7.6.2).

Perfect, missed that, thank you very much.

[Jan Burse]

Ulrich Neumerkel schrieb:

> There has been quite some changes between CD1 (N92) and the
> IS. For the sake of curiosity, N92 demanded that resatisfying
> a call is like fail ...

What is N92, some link?

[Jan Burse]

Jan Burse schrieb:

Ok, I see, some precursor to the current general core standard.

http://www.complang.tuwien.ac.at/ulrich/iso-prolog/doclist-2011-01-27.html
N92
Part 1, General core -- Committee Draft 1.0, vii + 1 + 150 pages, March
1992. = SC22 N1133; ballot results in SC22 N1205, N1210.

[Ulrich Neumerkel]

Not clear what you mean. Lets consider:

mynot(X) :- X, !, fail ; true.

In this case during preparation for execution, this clause
is converted to

mynot(X) :- call(X), !, fail ; true.

Such that

?- mynot((!,fail)).

succeeds.

And in fact, SWI, YAP 6.2.1 (I have not installed 6.3, yet), GNU,
Ciao, SICStus, ECLiPSe succeed as well. The only systems that
fail are B and Jekejeke.

YAP and ECLiPSe differ for some other cases and both differently.
E.g. ECLiPSe fails if mynot/1 has been asserta-ed dynamically.

Now, consider mynot((X=!,X,fail)). This will be executed
as call((X=!,X,fail;true)). Which means that this is converted
to X=!, call(X), fail ; true and then it is executed.


You might ask if this convention in ISO makes sense.

I think it does. It permits you to reason about a goal X in
a relatively predictible manner.

1mo Robustness. Many programs have goals like mynot/1 above
and do not anticipate that someone will perform a !. For this
reason alone, it is a good idea that mynot/1 above "shields" the
effects of X for the common case.

2do Consistency.

If you see something which essentially corresponds to

... var(G), ..., G ...

Then you know *for sure* that G will never cut to the outside.
Never. No matter what goals are in between the var(G) (the point
where you know for sure that G is a variable) and G.
No matter where this code occurs. Be it directly in the
body of a clause, be it as an argument to call/1 or an argument
to findall/3, setof/3 whatever.

As a consequence, this means that writing G as a goal in a rule
is always equivalent to call(G).

G can only cut within a call/1 or another meta-argument.

[Ulrich Neumerkel]

Please correct:

ulr...@mips.complang.tuwien.ac.at (Ulrich Neumerkel) writes:
>Now, consider mynot((X=!,X,fail)). This will be executed

should read: mynot((X=!,X,fail;true))

[Paulo Moura]

The only thing I hear is the sound of my keyboard keys while I add
your mail addresses to the junk filter of my mail program in order to
complement the mental note to not bother to read any more of your
posts in this newsgroup in the future.

Paulo

[Ulrich Neumerkel]

Jan Burse <janb...@fastmail.fm> writes:
>Jan Burse schrieb:
>> Ulrich Neumerkel schrieb:
>>> There has been quite some changes between CD1 (N92) and the
>>> IS. For the sake of curiosity, N92 demanded that resatisfying
>>> a call is like fail ...
>>
>> What is N92, some link?
>
>Ok, I see, some precursor to the current general core standard.

We have:

1992-03 First Committee Draft aka CD1 aka 1st CD aka N92

1993-03 Revised Commitee Draft aka CD2 aka 2nd CD aka N110
which would be called in more recent terminology
Final commitee draft aka FCD.

1994-03 Draft International Standard aka DIS aka DIS1 aka 1st DIS aka N128

1995-01 Final Draft International Standard aka FDIS

1995-06 International Standard aka IS aka ISO/IEC 13211-1

2007-11 Technical Corrigendum 1 aka TC1 aka COR1

2011-03 Draft Technical Corrigendum 2 aka DTC2 aka DCOR2

2011-06 Revised Draft Technical Corrigendum 2 aka Revised DCOR2 aka N4626



Of course, the one and only relevant document is the IS and the two
corrigenda. But prior documents are often helpful to understand how
the standard moves - and to prevent that it moves back...

[Jan Burse]

Ulrich Neumerkel schrieb:

> Guess we can construct examples that would
>>not work correctly without this provisio.

I wrote the above (09:17) before you hinted me
(14:06) that I missunderstood 7.8.3.1 and that
this provisio is always there.

[Jan Burse]

Ulrich Neumerkel schrieb:

> YAP and ECLiPSe differ for some other cases and both differently.
> E.g. ECLiPSe fails if mynot/1 has been asserta-ed dynamically.

I guess there will be a wide spectrum of behaviour in the wild.

> And in fact, SWI, YAP 6.2.1 (I have not installed 6.3, yet),
> GNU, Ciao, SICStus, ECLiPSe succeed as well. The only systems
> that fail are B and Jekejeke.

The system I tested didn't completely fail:

> | ?- call((Z=!, a(X), Z)).
> Z = !
> X = 1 ?;
> Z = !
> X = 2
> yes

> | ?- findall(Z-X,call((Z=!, a(X), Z)),L).
> L = [!-1]

It only failed when in the context of findall/3.

From the post of C. Eastham and P. Moura you can extract
some additional Prologsystem Names, not on your list,
that also show some failure.

I am not sure whether I have a test case for when
asserted-ed dynamically. Have to check. Also don't know
what C. Eastham and P. Moura did see in this respect.

But only some insight can be gained from such lists,
when the discrepancies are named. And then in principle
we can forget about the Prologsystem names, deal
directly with the discrepancies and name these.

Bye

[Ulrich Neumerkel]

Jan Burse <janb...@fastmail.fm> writes:
>Ulrich Neumerkel schrieb:
>> YAP and ECLiPSe differ for some other cases and both differently.
>> E.g. ECLiPSe fails if mynot/1 has been asserta-ed dynamically.
>
>I guess there will be a wide spectrum of behaviour in the wild.
>
> > And in fact, SWI, YAP 6.2.1 (I have not installed 6.3, yet),
> > GNU, Ciao, SICStus, ECLiPSe succeed as well. The only systems
> > that fail are B and Jekejeke.
>
>The system I tested didn't completely fail:
>
>> | ?- call((Z=!, a(X), Z)).
>> Z = !
>> X = 1 ?;
>> Z = !
>> X = 2
>> yes
>> | ?- findall(Z-X,call((Z=!, a(X), Z)),L).
>> L = [!-1]
>
>It only failed when in the context of findall/3.

>

>But only some insight can be gained from such lists,
>when the discrepancies are named. And then in principle
>we can forget about the Prologsystem names, deal
>directly with the discrepancies and name these.

Further insight can often be gained by looking at the concrete
implementation:

B-Prolog Version 7.6b5, All rights reserved, (C) Afany Software 1994-2011.

...
| ?- findall(Z-X,(Z=!, (X=1;X=2), Z),L).
L = [!-1]
yes
| ?- findall(Z-X,call( (Z=!, (X=1;X=2), Z) ),L).
L = [!-1]
yes
| ?- findall(Z-X,call(call( (Z=!, (X=1;X=2), Z) ) ),L).
L = [!-1,!-2]
yes
| ?- (Z=!, (X=1;X=2), Z).

Z = !
X = 1

yes
| ?- call( (Z=!, (X=1;X=2), Z) ).

[Jan Burse]

Ulrich Neumerkel schrieb:

> Further insight can often be gained by looking at the concrete
> implementation:
>
> B-Prolog Version 7.6b5, All rights reserved, (C) Afany Software 1994-2011.
> ...
> | ?- findall(Z-X,(Z=!, (X=1;X=2), Z),L).
> L = [!-1]
> yes
> | ?- findall(Z-X,call( (Z=!, (X=1;X=2), Z) ),L).
> L = [!-1]
> yes
> | ?- findall(Z-X,call(call( (Z=!, (X=1;X=2), Z) ) ),L).
> L = [!-1,!-2]
> yes
> | ?- (Z=!, (X=1;X=2), Z).
> Z = !
> X = 1
> yes
> | ?- call( (Z=!, (X=1;X=2), Z) ).
> Z = !
> X = 1 ?;
> Z = !
> X = 2
> yes

I consider 3 kinds of insight:
Insight 1) a Prolog system decides to follow some strategy.
Insight 2) a Prolog system has a bug inside its own strategy and
Insight 3) a Prolog system has not yet decided to follow some strategy
and the behaviour is emergent.

I even didn't know about the many behaviours of
B-Prolog and I don't know whether they belong to
1), 2) and 3).

I isolated the two queries in my post and wanted to
make them Prologsystem independent, since I assumed an
ISO strategy for call/1 and wanted to know what the
correct ISO strategy for findall/3 is.

I didn't wanted to know 1), 2) and 3) for all Prolog
systems in the world. How did I come to my example,
well I wrote it already:

Jan Burse wrote 05.11.2011, 13:13:
> The teste case is not my invention, it is found in
> verbatim ISO 7.8.3.4. So attribution to me is not necessary,
> by accident I put it into a findall/3 so that I can check
> for the redo result, and thus spotted the problem.

I think the moment has come now, that this thread in
itself has brought the proof that it is sometimes
of advantage to focus on an artificial example and
a specific question.

Probably the only thing we might still discuss is whether
the examples in 7.8.3.4 is normative or not. Whether it
would eventually be permitted to derive from the
example. Not sure.

Best Regards

[Jan Burse]

Jan Burse schrieb:

> I didn't wanted to know 1), 2) and 3) for all Prolog
> systems in the world.

Since it might involve looking at many behaviours,
it is rather a test case coverage problem and not
a test case correctness problem.

Bye

[Ulrich Neumerkel]

Jan Burse <janb...@fastmail.fm> writes:

>Probably the only thing we might still discuss is whether
>the examples in 7.8.3.4 is normative or not. Whether it
>would eventually be permitted to derive from the
>example. Not sure.

Not sure what you mean by it. If you think there is an
inconsistency, don't hesitate to tell us!

One inconsistency has been removed recently:

http://www.complang.tuwien.ac.at/ulrich/iso-prolog/dtc2#U3

Do you see another one? Apart from Table 22?

[Jan Burse]

Ulrich Neumerkel schrieb:

Not immediately.

[Olafur Gunnlaugsson]

Þann 04/11/2011 23:07, skrifaði bart demoen:
> On Fri, 04 Nov 2011 23:29:01 +0100, Jan Burse wrote:
>
>> bart demoen schrieb:
>>> It is probably Yap
>>
>> Could you tell us more why you think it is Yap. Does it exactly
>> reproduce the example I gave?
>
>
> Just so that people in this newsgroup know, I got the following "threat"
> from JB by private email:
>
> If you continue with this B.S. I will write an official letter
> to your institution and deposit a contestation. I will just
> copy paste what you have written.

That is an outrageous threat, especially in a private mail


> Has anybody else noticed how unproductive and unpleasant
> comp.lang.prolog has become since JB showed up ?
>
> Other newsgroups have their nuisances (not to say trolls), and
> comp.lang.prolog has been mostly spared of them ... can we keep it
> the old way ?

Alas I have not monitored the newsgroup for over a decade except on an
occasional basis so cannot comment although I have the feeling it like
much of the Usenet has been going downhill since ca 1991 :-)

or that I am getting more cranky as I age, probably a bit of both ....

But JB advertised on sundry Prolog related lists for beta testers and
when he appeared on Facebook again asking for beta testers sounding a
bit desperate and since I had some free time I basically sent him a
message saying "I´ll bite", in response I got one cordial e-mail with
info and then a strange message via one of the social networks that was
basically a very odd brush-off, almost incomprehensible

I thought it was just me ....... kind of sad to see it is not .....

killfile time again

[Jan Burse]

Olafur Gunnlaugsson schrieb:

> message saying "I´ll bite", in response I got one cordial e-mail with
> info and then a strange message via one of the social networks that was
> basically a very odd brush-off, almost incomprehensible

There is nothing strange. We have just discontinued
facebook completely and are now exclusively
on Google+.

Problem is being on too many social sites is a real
time sink. And not all social sites have good stream
search. Google+ is pretty good in that.

Best Regards

[Jan Burse]

Olafur Gunnlaugsson schrieb:

> message saying "I´ll bite", in response I got one cordial e-mail with
> info and then a strange message via one of the social networks that was

> basically a very odd brush-off, almost incomprehensible.

Problem is that Google+ business pages aired only
yesterday, before we had a kind of a kludge on Google+.

Our proper announcement is from yesterday:
http://www.jekejeke.ch/idatab/doclet/blog/en/docs/ext/01_general/098_help/topic_999957.html

[Ulrich Neumerkel]

Olafur Gunnlaugsson <oligun...@gmail.com> writes:
>> Other newsgroups have their nuisances (not to say trolls), and
>> comp.lang.prolog has been mostly spared of them ... can we keep it
>> the old way ?
>
>Alas I have not monitored the newsgroup for over a decade except on an
>occasional basis so cannot comment although I have the feeling it like
>much of the Usenet has been going downhill since ca 1991 :-)

My memory may fail, but as far as I can remember there have always been
tensions between academic and commercial parties. Also, and particularly
so in the 1980s with all its 5th generation craze (a precursor of the
dot com bubble). It is also not that special to Prolog.

[Jan Burse]

Jan Burse schrieb:
> Section 7.6.2 of the ISO standard defines
> "Converting a term to the body of a clause".
> But it only covers the following meta predicates
> with goal arguments:
>
> (,)/2
> (;)/2
> call/l
> catch/3

Just for the record, some correction:

It only effectively covers the following meta
predicates with goal arguments:

(,)/2
(;)/2
(->)/2

So the *it* in the ISO comment of the examples in 7.8.3.4:

call((Z=!, a(X), Z))
...
[This behaviour arises because the argument
of call/l is converted to a goal before *it* is executed,
and 'Z' becomes the goal 'call(Z)', and is executed as
as 'call(!)' which is equivalent to true.]

My initial reading was that the *it* refers
to the call/1 itself. But the *it* does not
not refer to the call/1 itself, but to the
argument. Since call/1 is anyway not touched
by 7.6.2. The phrasing in 7.6.2 b) is:

If T is a term whose principal functor appears in
table 9 then G is the corresponding control construct
>>> If the principal functor of T is call/l or catch/3 or
throw/l then the arguments of T and G are identical, <<<
else if the principal functor of T is ( ’ , ’ ) /2 or
( ; ) /2 or ( ->) /2 then each argument of T shall also
be converted to a goal.

Therefore we have:

?- call((Z=!, a(X), Z)).
Z = !,
X = 1 ;
Z = !,
X = 2.

?- Z=!, call((a(X),Z)).
Z = !,
X = 1.

Oki, Doki.

Bye

P.S.: Many Prolog systems fail for the above,
we have on Windows 7, 64-bit in the top level:

SWI 5.11.30: Ok
YAP 6.2.1: Nok, first call not as in ISO example.
GNU 1.4.0: Nok, first call not as in ISO example.
Ciao 1.14.2: Nok, first call not as in ISO example.
SICStus 4.2.0: Nok, first call not as in ISO example.
ECLiPSe Version 6.0 #183: Nok, first call not as in ISO example.
B-Prolog 7.6: Ok
Jekejeke Prolog 0.9.1: Nok, first call not as in ISO example.

[Ulrich Neumerkel]

Jan Burse <janb...@fastmail.fm> writes:
...

>Therefore we have:
>
> ?- call((Z=!, a(X), Z)).
> Z = !,
> X = 1 ;
> Z = !,
> X = 2.
>
> ?- Z=!, call((a(X),Z)).
> Z = !,
> X = 1.
>
>Oki, Doki.

Yes.

>P.S.: Many Prolog systems fail for the above,
>we have on Windows 7, 64-bit in the top level:
>
> SWI 5.11.30: Ok
> YAP 6.2.1: Nok, first call not as in ISO example.
> GNU 1.4.0: Nok, first call not as in ISO example.
> Ciao 1.14.2: Nok, first call not as in ISO example.
> SICStus 4.2.0: Nok, first call not as in ISO example.
> ECLiPSe Version 6.0 #183: Nok, first call not as in ISO example.
> B-Prolog 7.6: Ok
> Jekejeke Prolog 0.9.1: Nok, first call not as in ISO example.

GNU is definitely OK, and SICStus too.

Ciao (1.15.0-14221) differs in the *second* case.

Other systems that are OK, are IF and XSB.

[Jan Burse]

Ulrich Neumerkel schrieb:

> GNU is definitely OK, and SICStus too.

How comes? Which versions did you check?
The results I showed are from today and
with the indicated versions, I don't
think I have produced wrong results...

> Ciao (1.15.0-14221) differs in the *second* case.

Ok, I didn't use this version, have
to check.

> Other systems that are OK, are IF and XSB.

Which versions did you check? Will
do some additional checks as well.

BTW:

Amzi! and CxProlog seem also to fail,
judging from the e-mails of C. Eastham
and P. Moura.

Bye

[Jan Burse]

U. Neumerkel schrieb:

>> GNU is definitely OK, and SICStus too.

Yes agreed, they are Ok, I was confused by
the question mark in the REPL. Sorry.

> Ciao (1.15.0-14221) differs in the *second* case.

> Other systems that are OK, are IF and XSB.

So the updated list is now:

SWI 5.11.30: Ok
YAP 6.2.1: Nok, first call not as in ISO example.

GNU 1.4.0: Ok
Ciao 1.15.0: Nok, second call not as in ISO example.
SICStus 4.2.0: Ok

ECLiPSe Version 6.0 #183: Nok, first call not as in ISO example.
B-Prolog 7.6: Ok
Jekejeke Prolog 0.9.1: Nok, first call not as in ISO example.

IF (Version ?): Ok
XSB (Version ?): Ok
Amzi! Prolog 7.6.9: Nok, first call not as in ISO example.
(second call?) (newer version?)
CxProlog 0.97.5: Nok, first call not as in ISO example.
(second call?)

Looks like 50:50.

Bye

[Jan Burse]

Ulrich Neumerkel schrieb:

> One inconsistency has been removed recently:
>
> http://www.complang.tuwien.ac.at/ulrich/iso-prolog/dtc2#U3
>
> Do you see another one? Apart from Table 22?

More thinking about:

http://www.complang.tuwien.ac.at/ulrich/iso-prolog/dtc2#call

It has a failure outcome (8.15.4.3):

e) Goal cannot be converted to a goal
— type_error(callable, Goal).

But there is no test case for this. In general the examples are
all positive (success or failure), but no negative one (exception).

So from the examples I guess I can use atoms such as (,)/2
in the closure position, so what is the result of:

call(',', write(3), 3).

Should this give:

type_error(callable, (write(3), 3)) ?

And then maybe to make clear that the call(Goal) will most
probably do a conversion of the Goal according to 7.6.2, it
might be useful to give such an example as well:

call(',', Z=!, (a(X), Z)).

With facts a(1) and a(2) should this give:

On call: Z=!, X=1
On redo: Z=!, X=2
On redo: fail. ?

Right?

Bye

[Ulrich Neumerkel]

Jan Burse <janb...@fastmail.fm> writes:
>Ulrich Neumerkel schrieb:
>> One inconsistency has been removed recently:
>>
>> http://www.complang.tuwien.ac.at/ulrich/iso-prolog/dtc2#U3
>>
>> Do you see another one? Apart from Table 22?
>
>More thinking about:
>
> http://www.complang.tuwien.ac.at/ulrich/iso-prolog/dtc2#call
>
>It has a failure outcome (8.15.4.3):
>
> e) Goal cannot be converted to a goal

> - type_error(callable, Goal).

>
>But there is no test case for this. In general the examples are
>all positive (success or failure), but no negative one (exception).
>
>So from the examples I guess I can use atoms such as (,)/2
>in the closure position, so what is the result of:
>
> call(',', write(3), 3).
>
>Should this give:
>
> type_error(callable, (write(3), 3)) ?

Yes. It should give exactly the same error in the defined
first argument of error/2 as call(','(write(3),3))
that is call((write(3),3)). GNU does this correctly.

Take the procedural description of 8.15.4.1.:

a) Let call(p(X1, ..., XM), Y2, ..., YN) be the goal to be
executed, M >=0,

b) Execute call(p(X1, ..., XM, Y2, ..., YN)) instead.

I note that SWI differs - probably because the translation is
specialized for concrete predicates and control constructs are
handled in passing. Also, the example call(;, (true->fail), X=1).
succeeds in SWI, but should fail. YAP, B, GNU, SICStus 4, XSB
fail correctly.

>And then maybe to make clear that the call(Goal) will most
>probably do a conversion of the Goal according to 7.6.2, it
>might be useful to give such an example as well:

We already discussed this: call(Goal) does perform the conversion.

> call(',', Z=!, (a(X), Z)).
>
>With facts a(1) and a(2) should this give:
>
> On call: Z=!, X=1
> On redo: Z=!, X=2
> On redo: fail. ?
>
>Right?

Yes right.

[Jan Wielemaker]

On 2011-11-15, Ulrich Neumerkel <ulr...@mips.complang.tuwien.ac.at> wrote:
> I note that SWI differs - probably because the translation is
> specialized for concrete predicates and control constructs are
> handled in passing. Also, the example call(;, (true->fail), X=1).
> succeeds in SWI, but should fail. YAP, B, GNU, SICStus 4, XSB
> fail correctly.

Funny what people try. ;/2 is a really strange thing (as you know).
There are some choices. One is to force call/2 and call/3 (there are no
higher arity control structures) to check for something that results in
->/2, ,/2 or ;/2, build the term and call call/1. Another is to make
these invalid. I think that would be perfectly acceptable, but it would
only work if these things are no longer known as predicates.

I wonder whether it makes sense to demand implementations to handle this
or whether it makes more sense to declare the behaviour implementation
defined. I.e., this probably requires 20 lines of code in the virtual
machine that provides overhead for every call/2 and call/3 to solve
something nobody ever uses.

Cheers --- Jan

[Ulrich Neumerkel]

The perception what nobody ever uses may change over time. Here
is one such example: CD1 of 1992-03 demanded that a goal call(G)
is effectively executed as call((G,!)). Why? Because "nobody ever
uses it differently" and it simplified some implementations. (The
"trampoline code" for G could be immediately freed after the cut.)

You are specializing SWI for the frequent case when a continuation
will refer to a predicate and not a control structure. In that context
you perceive that case. But there are many other things to consider.

Any implementation defined/implementation specific feature reduces
the usefulness of a standard. The meaning of control structures
is entirely defined - so introducing ambiguity is no help to the
user. It only makes things more complex to them. Every deviation
that looks tiny to you causes costs in other places. Costs that
do not improve Prolog's reliablity.

And at least, above 5 systems simply comply.

To many Prologs call/N is relatively new - although it has been
proposed 1984-07-25. By making things irregular to users
(and saving you 20 lines and three comparisons at runtime) the
burder is put onto users not necessarily known as avid manual readers.

[Jan Burse]

Ulrich Neumerkel schrieb:
>> >Right?
> Yes right.

And how about the coverage (*)? Don't you think some
test case (aka. examples) are missing:

8.4.3 sort/2
No test case for instantiation_error
No test case for type_error(list)
8.4.4 keysort/2
No test case for instantiation_error
No test case for type_error(list)
No test case for type_error(pair)
8.15.4 call/2..8
No test case for instantiation_error
No test case for type_error(callable)
9.4.6 xor/2 – bitwise exclusive or
No test case for instantiation_error
No test case for type_error(integer)

Bye

(*)
http://en.wikipedia.org/wiki/Code_coverage

[Jan Burse]

Jan Burse schrieb:

> And how about the coverage (*)? Don't you think some
> test case (aka. examples) are missing:

Taking the other predicate defintions and their
test cases (aka. examples) as the standard for
coverage.

Bye

[Ulrich Neumerkel]

Jan Burse <janb...@fastmail.fm> writes:
>Ulrich Neumerkel schrieb:
>>> >Right?
>> Yes right.
>
>And how about the coverage (*)? Don't you think some
>test case (aka. examples) are missing:
>
> 8.4.3 sort/2
> No test case for instantiation_error
> No test case for type_error(list)

...

You are talking about the example subclauses (x.y.z.4).

The purpose of a standard is not to provide an exhausting set
of examples that can be used for conformity assessment. Test
cases should be derivable from the document. But they do not
have to be part of it. Please refer to other standards, like
9899 to see that.

Also the original document does not mention examples for each
and every case. Compared to other standards, however, 13211-1
is quite prolix. So it is easy to get the impression that
examples have to cover the entire behaviour.

Think of it: One of the most complex built-in predicate of
13211-1:1995 is setof/3. It contains in 8.10.3.4 an entire set
of 24 examples going over more than 4 columns. And, I may add,
these examples are really needed.

But none tests for the three error conditions specified in
8.10.3.3 - cases you mention for sort/2 and other built-ins.

Conformity assessment is definitely important, but it is something
different to a standard document defining the core language.
It might go into an entirely new document, though.

Just look at the current table for syntax:

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

[Jan Burse]

Ulrich Neumerkel schrieb:

> Just look at the current table for syntax:
>
> http://www.complang.tuwien.ac.at/ulrich/iso-prolog/conformity_assessment
>

The big advantage of inline test cases (aka. examples)
is that they provide a natural reference to the predicate,
the use case, the failure outcome that are tested.

The problem with these so called "conformity_assesment"
documents so far, as I have seen them, is that they lack
a clear reference to what they are testing. For example
the "conformity_assesment" for syntax, could refer to the
syntax clauses in ISO core standard.

If this reference would be given, then two checks would
be simple: Correctness and coverage.

If there is the possibility to inline test cases (aka.
examples) with a good coverage. Then this oportunity should
be taken, so that a single document can be produced. For
section 6.4/6.5, i.e. the syntax, it is probably the right
thing to do a separate document, since it is very dense in
definitions, so that injecting examples, which would be
many, would destroy reading.

But a predicate is a small unit, and it has a document
structure with a slot for examples. So why not fill that
slot, once and for all. Maybe also consider mentioning
exception variations, such as order of exception testing,
and form of culprit.

Bye

[Jan Wielemaker]

Yes. However, let is look at call(;, (true->fail), X=1) and how this
may happen. You want this to fail if you started with the control
structure, broke it appart and gave it to call/3. I cannot really
imagine this scenario to be realistic. I can imagine a more realistic
scenario, where we have two lists of goals and we want to know that for
each pair at least one is true. So, we call

maplist(;, Goals1, Goals2).

But now there are ! or -> in the goal lists, producing really unexpected
results. So, I need to explain the poor use that he needs to define

or(A,B) :- A ; B.

and then to

maplist(or, Goals1, Goals2).

I can understand this and you can, but it will surely confuse 99%
of the Prolog programmers. I'm in favour of leaving the behaviour
of control structures undefined for call/N, N>1.

Cheers --- Jan

[Ulrich Neumerkel]

Jan Wielemaker <j...@invalid.invalid> writes:
>On 2011-11-15, Ulrich Neumerkel <ulr...@mips.complang.tuwien.ac.at> wrote:
>> The perception what nobody ever uses may change over time. Here

>> is one such example: ...

>> And at least, above 5 systems simply comply.
>
>Yes. However, let is look at call(;, (true->fail), X=1) and how this
>may happen. You want this to fail if you started with the control
>structure, broke it appart and gave it to call/3. I cannot really
>imagine this scenario to be realistic. I can imagine a more realistic
>scenario, where we have two lists of goals and we want to know that for
>each pair at least one is true. So, we call
>
> maplist(;, Goals1, Goals2).
>
>But now there are ! or -> in the goal lists, producing really unexpected
>results. So, I need to explain the poor use that he needs to define
>
> or(A,B) :- A ; B.
>
>and then to
>
> maplist(or, Goals1, Goals2).
>
>I can understand this and you can, but it will surely confuse 99%
>of the Prolog programmers. I'm in favour of leaving the behaviour
>of control structures undefined for call/N, N>1.

Your proverbial poor user will be confused anyway, if he uses
control constructs in such a manner as you indicate. After all,
he might realise after some time that Goals1 is a list of exactly
one element. So essentially he has the goal

maplist(;, [Goal1], [Goal2]).

Of course, this goal can be replaced by call(;(Goal1,Goal2)).
in ISO, YAP, B, GNU, SICStus 4, XSB.

In SWI, however, you will now have to explain your poor user
the difference between

maplist(;, [Goal1], [Goal2]).

and

call(;(Goal1,Goal2)).

By leaving details as such open, you are obstructing meaningful
optimizations that are otherwise possible.

You said you cannot imagine this scenario to be realistic.

[Ulrich Neumerkel]

Jan Burse <janb...@fastmail.fm> writes:
>Ulrich Neumerkel schrieb:
>
>> Just look at the current table for syntax:
>>
>> http://www.complang.tuwien.ac.at/ulrich/iso-prolog/conformity_assessment
>>
>
>The big advantage of inline test cases (aka. examples)
>is that they provide a natural reference to the predicate,
>the use case, the failure outcome that are tested.
>
>The problem with these so called "conformity_assesment"
>documents so far, as I have seen them, is that they lack
>a clear reference to what they are testing. For example
>the "conformity_assesment" for syntax, could refer to the
>syntax clauses in ISO core standard.
>
>If this reference would be given, then two checks would
>be simple: Correctness and coverage.

But that is an entirely different project. And I cannot
see for the moment much merit to it.

Even worse, several cases depend on more than one subclause.
Please study other such efforts - like POSIX conformance
testing (ISO 13210).

In the meantime what I do is to collect problematic cases
such that implementors can improve and users can better
assess the situation.

[Jan Burse]

Ulrich Neumerkel schrieb:

> Even worse, several cases depend on more than one subclause.

I did the following annotation when a test
case matches multiple standard sections:

A -> B; C ISO 7.8.8.4, Corrigendum 1
^ The predicate ^ The annotation

In the above you even have dependence on
different documents.

Schould be also possible for syntax test
cases I guess.

Bye

[Ulrich Neumerkel]

There is much more dependence than two sebclauses. Virtually every test
case depends on 6 and on 7.7 - to start with.

I very much doubt that a single other language has something in that
direction.

[Jan Burse]

Ulrich Neumerkel schrieb:

Well you need only to refer the salient subclause,
not the whole world. I guess you can figure it out.

Bye

[Jan Burse]

Hi,

Ulrich Neumerkel wrote:
> Not sure what you mean by it. If you think there is an
> inconsistency, don't hesitate to tell us!
>

> One inconsistency has been removed recently:
>
> http://www.complang.tuwien.ac.at/ulrich/iso-prolog/dtc2#U3
>
> Do you see another one? Apart from Table 22?

Not sure whether this an inconsistency. It is only
an inconsistency when we interpret the G in the
c) failure outcome of call/1 to refer to the main
goal and not to the non-convertible sub goal that is
encountered during the body conversion in 7.6.2.

The other existing test cases in the ISO core standard
suggest that the long culprit is the right thing.
But it could also be that the culprit, whether long
or short is implementation dependent, and that the
corresponding examples should be accordingly marked.

A short reality check reveals. Non-lazy indicates
that the error is detected before execution:

Query I:
?- write(3), 3.

GNU Prolog 1.4.0: long culprit, non-lazy
uncaught exception: error(type_error(callable,
(write(3),3)),top_level/0)

SICStus Prolog 4.2.0: short culprit, non-lazy
Type error in 3/0
expected callable, but found 3
goal: user:(write(3),3)

SWI Prolog 5.11.30: long culprit, non-lazy
ERROR: '$execute_goal2'/2: Type error: `callable'
expected, found `write(3),3'

B-Prolog 7.6b5: short culprit, lazy
3
*** error(type_error(callable,3),call/1)

Query II:
?- [user].
p :- write(3), 3.

GNU Prolog 1.4.0: short culprit, non-lazy
user:1: fatal error: body goal is not callable (3)

SICStus Prolog 4.2.0: short culprit, non-lazy
Type error in assertz/1
expected callable, but found 3
goal: assertz((p:-write(3),3))

SWI Prolog 5.11.30: long culprit, non-lazy
ERROR: user://1:13:
'$record_clause'/2: Type error: `callable'
expected, found `write(3),3'

B-Prolog 7.6b5: short culprit, lazy
?- p.
3
*** error(type_error(callable,3),call/1)

Bye

[Ulrich Neumerkel]

Jan Burse <janb...@fastmail.fm> writes:

You should have used call((write(3), 3)) instead to
avoid interaction with the toplevel. In fact B-Prolog
is conforming here, provided you use call((write(3), 3)).

Also, it does not help much to show the implementation
dependent messages. The error term (7.12.1) is the only
thing of relevance.

>Query II:
> ?- [user].
> p :- write(3), 3.

...

Here you consider what is known as preparation for
execution (7.5.1). This phase is entirely implementation
dependent. So your observations about errors displayed
do not show anything of normative relevance.

We can only talk about the state thereafter when no
error condition applied. What to do with read-terms
that do not conform is left undefined in 13211-1.
See 7.4.1 c.

[Jan Burse]

Ulrich Neumerkel schrieb:

> Here you consider what is known as preparation for
> execution (7.5.1). This phase is entirely implementation
> dependent.

Yes and no. I guess it a little unclear, but I doubt
that it allows for an "entirely" implementation dependent
realization. Since we have the following phrase in
section 7.5.1:

... This process converts the read-terms in a
Prolog text to the clauses of user-defined
procedures in the database.

There is no explicit forward reference to 7.6.2, the
conversion. But applying exemplar reasoning, should
suffice to show that 7.6.2 is intended. Namely in
Section 8.8 we have given a Prolog text:

...
legs(A, 7) :- A, call(A).
...

And then the following example in Section 8.8.1.4:

...
clause(legs(C, 7), Body).
Succeeds, unifying Body with (call(C), call(C)).
...

So there is evidence that the preparation 7.5.1 needs
at least to follow part of 7.6.2., namely the wrapping
of a naked goals X to call(X).

An "entirely" implementation dependent realization would
render Prolog systems quite arbitrarily, and would make
Prolog texts as an exchange medium for what they stand
for useless.

I think the more important sections of 7.5.1 are:

... The means by which a Prolog processor is asked to
prepare standard-conforming Prolog texts (6.2) to
execution shall be implementation defined. ...

Which I read the Prolog systems is free to provide a
[user] or a consult... menu entry etc..

And then:

... The manner in which a Prolog processor prepares
standard-conforming Proog texts for executio shall
be implementation dependent. ...

Here I am not 100% sure what the intention is. I guess
it has to do with the moment by when the Prolog text is
converted, and the amount of Prolog text that is converted.

For example when one tries the p :- write(3),3 clause
example, one sees that not all Prolog systems immediately
display an error message.

I am not refering to lazy vs. non-lazy. But for the example
some Prolog systems start only showing an error when
encontering ^D resp. ^Z (eof).

Also I see that Prolog systems sometimes refuse the
whole Prolog text when a single error occurs in the
Prolog text, and some just continue with the rest.

And it might be difficult to get an error term, since
errors during Prolog text preperation usually don't
permeate to the call site. I cannot do:

?- catch([user],E,true).

So this might be a reason also why there is no negative
example for it. It would be simple to add:

legs(A, 8) :- write(3), 1.

And then say at least: If the a Prolog text is accepted,
then it should not have included the above clause for
execution, or the whole Prolog text might be rejected.

Bye

[Jan Burse]

Ulrich Neumerkel schrieb:

> Here you consider what is known as preparation for
> execution (7.5.1). This phase is entirely implementation
> dependent.

And here is evidence that you are entirely wrong:

Section 7.4.3 Clauses:

...

A clause-term in Prolog text (6.2.1.2) enables
a clause of a user-defined procedure to be added
to the database.

...

A clause Clause of a clause-term clause. shall
satisfy the same constraints as those required
for a successful execution of the built-in predicate
assertz (Clause) (8.9.2) except that no error shall
occur because Clause refers to a static procedure,
and clause shall be converted to a clause c and
added to the database in the same way.

...

And then in Section 8.9.2.1 Description of assertz:

...

d) Converts (7.6.1) the term Body to a goal G.

e) Constructs the clause with Head H and Body B.

...

There is a typo in the above, B should be corrected to G.

And then in Section 8.9.2.3 Errors:

...

c) Body cannot be converted to a goal
-- type_error(callable, Body)

...

So there is a preference for the long culprit here.

Oki, Doki.

Bye

[Jan Burse]

Ulrich Neumerkel schrieb:

> What to do with read-terms
> that do not conform is left undefined in 13211-1.
> See 7.4.1 c.

It reads:

c) The action to be taken if the read-terms forming
Prolog text do not conform to the requirements of this
part of ISO/IEC 132 11.

Maybe this wants to leave open things like user
interaction during consult etc.. Not sure whether
this might allow suppressing non-conformance checks
or modifying non-conformance conditions.

Bye

[Ulrich Neumerkel]

Jan Burse <janb...@fastmail.fm> writes:
>Ulrich Neumerkel schrieb:
>> Here you consider what is known as preparation for
>> execution (7.5.1). This phase is entirely implementation
>> dependent.
>
>And here is evidence that you are entirely wrong:

Would you please also cite my next sentences? Here they
are again:

| We can only talk about the state thereafter when no
| error condition applied. What to do with read-terms
| that do not conform is left undefined in 13211-1.
| See 7.4.1 c.

When there are error conditions, everything is left
implementation dependent.

>And then in Section 8.9.2.1 Description of assertz:
...

>There is a typo in the above, B should be corrected to G.

Excellent!

>So there is a preference for the long culprit here.

There is such preference in asserta/1. But there is no preference
in 7.5.1

[Jan Burse]

Ulrich Neumerkel schrieb:

> | We can only talk about the state thereafter when no
> | error condition applied. What to do with read-terms
> | that do not conform is left undefined in 13211-1.
> | See 7.4.1 c.
>
> When there are error conditions, everything is left
> implementation dependent.

See my post, I don't fully agree: