Scryer-prolog: current_predicate(call/1) should fail

[stefan-kral]

My previous issue current_predicate/1 is (at least a bit) misleading... oopsie;)

_Originally posted by @stefan-kral in https://github.com/mthom/scryer-prolog/issues/146#issuecomment-502368534_

According to ISO/IEC 13211-1:1995 8.8.2.1 (Description of current_predicate/1):

current_predicate(PI) is true iff PI is a predicate indicator for one of the user-defined procedures in the database. [...]

(I added the emphasis.)

[jburse]

Current practice is to return also built-ins:

Inside a module, you would return those predicates that are visible through import as well. This allows for meta programming, using current_predicate/1 to check for existence of a predicate, before calling it. Otherwise you get an existence error. This should also work for built-ins.

For the module thingy check also the module standard, the predicate is found again in the module standard ISO/IEC 13211-2 First edition 2000-06-01 as 7.3.2 current_predicate/1 .

[stefan-kral]

Not with conforming processors like SICStus Prolog and GNU-Prolog.

The standard is quite clear on this:
Cf. 8.8.2.4 example #2: "current_predicate(current_predicate/1). Fails."

On Fri, 23 Aug 2019, 18:55 Jekejeke Prolog, [e-mail]
wrote:

Current practice is to return also built-ins:

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mthom/scryer-prolog/issues/153?email_source=notifications&email_token=AEAGOCSFNLH6SZXFFKTQZXLQGAJAXA5CNFSM4IJGBX32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5AYKAQ#issuecomment-524387586,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEAGOCWYIDEPJ7WXULTZGLTQGAJAXANCNFSM4IJGBX3Q
.

[jburse]

Its more practical to have the SWI-Prolog semantic. YAP does the same:

For example assume you make CLP(Z) a system module. Suddently
current_predicate((#=)/2) will fail, only because you changed the packaging.
The ISO core standard example and spec is nonsense here.

The spec in the module standard is also not better. The spec in the module
standard is more elaborate, since it shows how current_predicate/1 could
work in the presence of modules, but it does the same error

excluding system predicates. But what also helps, to further analyze
predicate indicators or callables, is a built-in predicate_property/2. You
find it only in the module standard.

[stefan-kral]

Then YAP is non-conforming in this case. But that does not change the
standard.

On Sat, 24 Aug 2019, 00:10 Jekejeke Prolog, [e-mail]
wrote:

Its more practical to have the SWI-Prolog sementic. YAP does the same:

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mthom/scryer-prolog/issues/153?email_source=notifications&email_token=AEAGOCVWWSD4AO5TOFHYDUDQGBN4TA5CNFSM4IJGBX32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5BOLFY#issuecomment-524477847,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEAGOCRZYAPHKJ37DW7YKBDQGBN4TANCNFSM4IJGBX3Q
.

[jburse]

Nobody wants to change the standard. I didn't say the standard is wrong
or should be changed. I only said what the current practice outside of the
standard is. The standard is one thing. The current practice is another thing.

The wording of my first post was "Current practice is...".

The wording of my second post was "Its more practical...".

There are a couple of things that you should not do like in the standard.
For example allowing "- 1" as a number. There are more things, when you
follow them, this will break your neck and only cause problems.

But the standard contains also things, which are useful to follow.

[XVilka]

I guess it can be closed now?

[pmoura]

This allows for meta programming, using current_predicate/1 to check for existence of a predicate, before calling it. Otherwise you get an existence error. This should also work for built-ins.

Checking if a predicate exists can be accomplished using predicate_property/2 (which handily takes a a predicate call instead of a predicate indicator). No need to break current_predicate/1 compliance for this use case.

[stefan-kral]

?- current_predicate(call/X).
false.

Better now! Closing...