Quintus --> Sicstus
nev
maybe to SWI, the point is a free solution on Windows). Is there any
automatic solution for this job?
I have done some syntactic change, and now my problem is the Quintus put/1
procedure. The code calls put/1 like these:
put(45)
put("(")
Sicstus has not put/1, and put_code or put_char is not good.
I have lots of "Permission error" too, but I don't know how much should I
worry about these.
The whole code is there:
http://dream.inf.ed.ac.uk/software/press/
Jan Wielemaker
> I have a Quintus Prolog code, what I need to port to Sicstus (and later
> maybe to SWI, the point is a free solution on Windows). Is there any
> automatic solution for this job?
>
> I have done some syntactic change, and now my problem is the Quintus put/1
> procedure. The code calls put/1 like these:
> put(45)
> put("(")
> Sicstus has not put/1, and put_code or put_char is not good.
SWI's put_code accepts "a" to make porting old code easier.
There are two views: migrating the code (i.e. give up that it
runs on Quintus) or making the code portable. The lastest GIT
version of SWI-Prolog 5.9 (development stream) contains a more
and more populated portability framework. This was `invented'
my me and Vitor to achieve better portability between YAP and
SWI-Prolog.
It is quite easy to instantiate the same for Quintus.
> I have lots of "Permission error" too, but I don't know how much should I
> worry about these.
Typically, you should worry about all warnings and errors at this
stage.
Cheers --- Jan
> The whole code is there:
> http://dream.inf.ed.ac.uk/software/press/
I guess you must be dreaming if you expect someone to do the work
for you :-)
nev
news:slrnhpmu3...@hppc323.few.vu.nl...
>
> SWI's put_code accepts "a" to make porting old code easier.
Thanks. I'v tried first with SWI, but I think its syntax is more different
from Quintus then Sicstus, because I get very much syntax error.
> I guess you must be dreaming if you expect someone to do the work
> for you :-)
My mother said never give up your dreams. :)
Jan Wielemaker
> news:slrnhpmu3...@hppc323.few.vu.nl...
>>
>> SWI's put_code accepts "a" to make porting old code easier.
>
> Thanks. I'v tried first with SWI, but I think its syntax is more different
> from Quintus then Sicstus, because I get very much syntax error.
The syntax of these systems is very close. SWI-Prolog even accepts some
of the quoted-string extensions of Quintus. What differs is a number of
declarations (directives) using operators. Most of these can simply
be ignored, which is easily done by defining the corrent operator and
defining a `term-expansion' rule to map the declaration to nothing.
Commenting or deleting helps too :-)
Other issues may result from Quintus and SICStus operators that are
global, while SWI-Prolog operators are local. SWI-Prolog supports
global operators by declaring them outside modules (i.e. in `user').
>> I guess you must be dreaming if you expect someone to do the work
>> for you :-)
>
> My mother said never give up your dreams. :)
Good strategy :-)
Cheers --- Jan
nev
>
> The syntax of these systems is very close. SWI-Prolog even accepts some
> of the quoted-string extensions of Quintus. What differs is a number of
> declarations (directives) using operators. Most of these can simply
> be ignored, which is easily done by defining the corrent operator and
> defining a `term-expansion' rule to map the declaration to nothing.
Thanks. I have ported the code to SICStus and it works well.
Now I want to go to SWI. The compilation completed, but I have semantic
error.:
% Initialize Looping Check
initialize_loop_check :-
abolish(seen_eqn/1),
assert((seen_eqn(_) :- fail)).
The last line is failed, and therefor the program terminates.
Chip Eastham
> "Jan Wielemaker" <j...@hppc323.few.vu.nl> wrote in message
Hi, nev:
Dare I ask what the final assert accomplishes?
Once abolished, in the absence of further assert's
concerning seen_eqn/1, any such goal will fail
(just because there are no matches available to
seen_eqn/1). Furthermore the rule:
"seen_eqn(_) :- fail"
won't prevent success for additional assert's for
seen_eqn/1 after this one.
regards, chip
nev
news:e38a43b0-9f62-4a7f...@q16g2000yqq.googlegroups.com...
>
> Dare I ask what the final assert accomplishes?
I don't know, but that assert works on SICStus, and doesn't fails.
> Once abolished, in the absence of further assert's
> concerning seen_eqn/1, any such goal will fail
> (just because there are no matches available to
> seen_eqn/1). Furthermore the rule:
>
> "seen_eqn(_) :- fail"
Thanks. I've simply deleted that line, and now works on SWI too.
At last: I've ported 500KB code from one Prolog to another two Prolog, while
I don't know Prolog at all. I feel myself like a blind watchmaker.
Jan Wielemaker
silent failing seems unlikely. Normally, this should succeed but
there might be some error. What is the message?
--- Jan
nev
>
> silent failing seems unlikely. Normally, this should succeed but
> there might be some error. What is the message?
There is no error message, call assert just return with 'Fail' according the
tracing.
Jan Wielemaker
Very odd. AFAIK, assert cannot fail. It can only succeed or produce errors.
Anyway, it doesn't seem to bother you :-) If it does, create a reproducable
case from it. As is, this runs fine. Possibly the rest of the code
intercepts error messages ...
--- Jan
Paulo Moura
> On Mar 14, 2:18 pm, "nev" <a> wrote:
>
>
>
>
>
> > "Jan Wielemaker" <j...@hppc323.few.vu.nl> wrote in message
>
> >news:slrnhpn6e...@hppc323.few.vu.nl...
>
> > > The syntax of these systems is very close. SWI-Prolog even accepts some
> > > of the quoted-string extensions of Quintus. What differs is a number of
> > > declarations (directives) using operators. Most of these can simply
> > > be ignored, which is easily done by defining the corrent operator and
> > > defining a `term-expansion' rule to map the declaration to nothing.
>
> > Thanks. I have ported the code to SICStus and it works well.
> > Now I want to go to SWI. The compilation completed, but I have semantic
> > error.:
>
> > % Initialize Looping Check
> > initialize_loop_check :-
> > abolish(seen_eqn/1),
> > assert((seen_eqn(_) :- fail)).
>
> > The last line is failed, and therefor the program terminates.
>
> Hi, nev:
>
> Dare I ask what the final assert accomplishes?
>
> Once abolished, in the absence of further assert's
> concerning seen_eqn/1, any such goal will fail
The behavior when calling an abolished predicate depends on the
"unknown" flag. The calls should fail only of the flag is set to
"fail".
> (just because there are no matches available to
> seen_eqn/1). Furthermore the rule:
>
> "seen_eqn(_) :- fail"
>
> won't prevent success for additional assert's for
> seen_eqn/1 after this one.
Is possible that this clause is asserted simply in order to prevent
errors if the "unknown" flag is set to "error". As a side note, assert/
1 is not a standard predicate. For portability, best to use assertz/1.
Cheers,
Paulo
nev
> On 2010-03-14, nev <a> wrote:
>> "Jan Wielemaker" <ja...@hppc323.few.vu.nl> wrote in message
>> news:slrnhpqgp...@hppc323.few.vu.nl...
>>>
>>> silent failing seems unlikely. Normally, this should succeed but
>>> there might be some error. What is the message?
>>
>> There is no error message, call assert just return with 'Fail' according
>> the
>> tracing.
>
> Very odd. AFAIK, assert cannot fail. It can only succeed or produce
> errors.
> Anyway, it doesn't seem to bother you :-)
As I understand Chip, he said that the line is unnecessary. But maybe I
misunderstood him, so I don't want to delete lines if it cause invalid code.
> If it does, create a reproducable
> case from it. As is, this runs fine. Possibly the rest of the code
> intercepts error messages ...
I've found there are 2 cases:
1. Consult the program immediately after the start of SWi. There are no
compiller errors, and the program doesn't works (as I written before).
2. Before consult the program consult this code:
:- dynamic apple/1.
apple(X) :- X = 'a'.
:- abolish(apple/1), assert((apple(_) :- fail)).
Then consult the program there is two compiller error.
In spite of these, the program works fine.
ERROR: c:/users/gazda/documents/press-swi/filin.pl:10:
No permission to redefine built-in predicate `assert/1'
Use :- redefine_system_predicate(+Head) if redefinition is intended
ERROR: c:/users/gazda/documents/press-swi/filin.pl:11:
No permission to redefine built-in predicate `assert/1'
Use :- redefine_system_predicate(+Head) if redefinition is intended
The two lines are:
assert((term_expansion((public), X) :- X = ' ')).
assert((term_expansion((mode), X) :- X = ' ')).
(after I declared these
:- op(1150, fx, user:(public)).
:- op(1150, fx, user:(mode)).
)
Chip Eastham
> "Jan Wielemaker" <j...@hppc323.few.vu.nl> wrote in message
>
> news:slrnhpqiq...@hppc323.few.vu.nl...
>
> > On 2010-03-14, nev <a> wrote:
The only idea I have is that after abolish/1, the 'dynamic'
property of apple/1 (or seen_eqn/1, or whatever) gets
reset in SWI-Prolog (presumably to 'static' as a default).
Some Prologs would complain about asserting a static
predicate, but not (as I understand it) SWI-Prolog. Also
the error msg seems to be about redefining assert (a
system predicate) rather than redefining apple/1.
So my idea is not necessarily helpful; I just mention it
as there could be some other side effect of abolish/1.
What happens if you perform the last step in two parts:
? abolish(apple/1).
? assert((apple(_) :- fail)).
regards, chip
Paulo Moura
> ...
> The only idea I have is that after abolish/1, the 'dynamic'
> property of apple/1 (or seen_eqn/1, or whatever) gets
> reset in SWI-Prolog (presumably to 'static' as a default).
Not really. A call to abolish/1 makes the system forget that the
predicate ever existed. Thus, all clauses of the predicate and all
predicate properties are wiped out.
Cheers,
Paulo
nev
>
> The only idea I have is that after abolish/1, the 'dynamic'
> property of apple/1 (or seen_eqn/1, or whatever) gets
> reset in SWI-Prolog (presumably to 'static' as a default).
It seems my program is originally bad. (declare dynamic, then lost the
properties in the first usage).
> Some Prologs would complain about asserting a static
> predicate, but not (as I understand it) SWI-Prolog. Also
> the error msg seems to be about redefining assert (a
> system predicate) rather than redefining apple/1.
Yes, but I don't redefine assert, and this error occurs only after the apple
code. Something changes in the state of the compiller.
> What happens if you perform the last step in two parts:
>
> abolish(apple/1).
> assert((apple(_) :- fail)).
In this case the first point happens. (works like when there is no "apple
code").
nev
retractall:
initialize_loop_check :- retractall(seen_eqn(_)).
"retractall/1 is useful for erasing all the clauses of a dynamic procedure
without forgetting that it is dynamic; abolish/1 will not only erase all the
clauses, but will also forget absolutely everything about the procedure.
retractall/1 only erases the clauses. This is important if the procedure is
called later on."
Thank you everyone for your help!
Joachim Schimpf
That's certainly not the case for ECLiPSe and presumably also other
systems that do any kind of optimizations (e.g. inlining) and/or have
different calling conventions (e.g. for meta-predicates, or based on
modes). Once you have compiled a call to such a predicate, you
can't simply go and change the properties.
BTW, ISO allows abolish only for dynamic predicates...
-- Joachim
Paulo Moura
wrote:
Yes, above I'm talking about *dynamic* predicates. I assumed that was
clear from the context. From section 8.9.4.1 of the ISO Prolog
standard (Part 1):
"NOTE --- abolish(Pred)" leaves the database in the same state as if
the procedures identified by Pred had never existed.
Moreover, in 8.9.4.3 (Errors):
"h) The predicate indicator Pred is that of a static procedure
--- permission_error(modify, static_procedure, Pred)"
Cheers,
Paulo
Jan Burse
> What happens if you perform the last step in two parts:
>
> ? abolish(apple/1).
> ? assert((apple(_) :- fail)).
>
> regards, chip
Instead of doing just abolish/1, you can do
abolish/1 and then dynamic/1, and then you
have a erase of the predicate and in the same
time it stays dynamic.
Instead:
?- abolish(apple/1), assert((apple(_) :- fail)).
Do that:
?- abolish(apple/1), dynamic(apple/1), assert((apple(_) :- fail)).
At least this is what you would need to do in ISO.
But well you can also do the following:
erase(P) :- abolish(P), dynamic(P).
?- erase(apple/1), assert((apple(_) :- fail)).
Also I think the assert((apple(_) :- fail)), is not
necessary, since after dynamic the predicate apple/1
is not anymore undefined. So any call apple/1 will
fail also without the assert, and not throw an undefined
predicate error.
So all you have to do is:
?- erase(apple/1).
Bye
Jan Burse
> That's certainly not the case for ECLiPSe and presumably also other
> systems that do any kind of optimizations (e.g. inlining) and/or have
> different calling conventions (e.g. for meta-predicates, or based on
> modes). Once you have compiled a call to such a predicate, you
> can't simply go and change the properties.
>
> BTW, ISO allows abolish only for dynamic predicates...
>
> -- Joachim
>
Yes, I noticed that ISO does not use a notion of
compiled and non-compiled, but rather they distinguish
between static and dynamic predicates. This is also
seen in the appendix.
But well, I would say static does not necessarily mean
non-modifiable. Although ISO leaves open the development
environment and such matters, I guess one can usually
re-consult a module, and thus the static predicates
are replaced with their newest version.
Such a Prolog would have internally a more powerful
abolish, without the ISO restriction that the external
predicate can only be applied to dynamic predicates.
But why is there the distinction between static and
dynamic predicates at all?
Probably its some didactic reason. So that we don't
accidental assert or retract over the "program". With
the positive side effect, that this can constitute
a nice invariant for some code optimizations. Or looking
at the downside, my dynamic predicates will lack some
performance?
Bye
Paulo Moura
> Chip Eastham wrote:
> > What happens if you perform the last step in two parts:
>
> > ? abolish(apple/1).
> > ? assert((apple(_) :- fail)).
>
> > regards, chip
>
> Instead of doing just abolish/1, you can do
> abolish/1 and then dynamic/1, and then you
> have a erase of the predicate and in the same
> time it stays dynamic.
>
> Instead:
>
> ?- abolish(apple/1), assert((apple(_) :- fail)).
>
> Do that:
>
> ?- abolish(apple/1), dynamic(apple/1), assert((apple(_) :- fail)).
>
> At least this is what you would need to do in ISO.
Hum? In the ISO Prolog standard, dynamic/1 is a directive, not a
predicate. And assert/1 is not specified, only asserta/1 and assertz/
1.
Moreover, asserting a clause for a new predicate (and above apple/1 is
a new predicate for the system given the previous call to abolish/1),
implicitly declares it dynamic. Thus, there is no need for the non-
standard dynamic/1 call in between.
Too bad the ISO Prolog standards are not freely available. It would
certainly help avoid misunderstandings on this matters :(
Cheers,
Paulo
Jan Burse
> Moreover, asserting a clause for a new predicate (and above apple/1 is
> a new predicate for the system given the previous call to abolish/1),
> implicitly declares it dynamic. Thus, there is no need for the non-
> standard dynamic/1 call in between.
Yes, you are right. In both respects. In the ISO
standard there is the example of asserta((foo(X) :-
X, call(X))), which implicitly makes
dynamic(foo/1).
I think this is less strict (assert works on undefined)
and also less symmetric (retract/clause works not
on undefined).
I was also not aware about this distinction of
directive and normal goal. But I guess the ISO standard
does not prohibit that directives are also built-ins.
It literally says:
A processor shall support correctly any directive
whose directive indicator is specified in subclause
7.4.2.x.
So supporting normal goals inside the text of a module
would not be forbidden. And I guess vice versa a directive
as a built-in would also not be forbidden.
But if dynamic/1 is not callable, then I think the system
is also less reflective.
For example with a callable dynamic/1 we could simulate the
ISO assert:
iso_assert((A:-B)) :-
functor(A,F,N),
dynamic(F/N),
non_iso_assert((A:-B)).
Finally I was also not aware that asserted clauses are the
same as reading in a module, where the predicate is introduced
with a dynamic/1 directive. I though that a dynamic/1 directive
is not followed by clauses for the same predicate. But ISO
standard says for my initial example, that this would be the
same as reading in the following text:
:- dynamic(foo/1).
foo(X) :- call(X), call(X).
Right?
Bye
Jan Burse
> So supporting normal goals inside the text of a module
> would not be forbidden. And I guess vice versa a directive
> as a built-in would also not be forbidden.
An ISO example of a predicate which is already
a directive and a built-in is set_prolog_flag/2.
Bye
Paulo Moura
> Paulo Moura wrote:
> > Moreover, asserting a clause for a new predicate (and above apple/1 is
> > a new predicate for the system given the previous call to abolish/1),
> > implicitly declares it dynamic. Thus, there is no need for the non-
> > standard dynamic/1 call in between.
> I was also not aware about this distinction of
> directive and normal goal. But I guess the ISO standard
> does not prohibit that directives are also built-ins.
I guess so but I have no free time to check.
> It literally says:
>
> A processor shall support correctly any directive
> whose directive indicator is specified in subclause
> 7.4.2.x.
What's the connection? Subclause 7.4.2.x specifies the different ISO
Prolog *directives*.
> So supporting normal goals inside the text of a module
> would not be forbidden. And I guess vice versa a directive
> as a built-in would also not be forbidden.
I think the philosophy of the standard is to ban using arbitrary
queries as directives. The directive initialization/1 should be used
instead.
> But if dynamic/1 is not callable, then I think the system
> is also less reflective.
>
> For example with a callable dynamic/1 we could simulate the
> ISO assert:
>
> iso_assert((A:-B)) :-
> functor(A,F,N),
> dynamic(F/N),
> non_iso_assert((A:-B)).
Is there a single Prolog compiler whose implementation of asserta/
assertz doesn't make the asserted predicate dynamic (if not already)?
> Finally I was also not aware that asserted clauses are the
> same as reading in a module, where the predicate is introduced
> with a dynamic/1 directive.
Why should it be any different?
> I though that a dynamic/1 directive
> is not followed by clauses for the same predicate.
Some misconception here. If you have a bunch of predicates defined in
a Prolog file and you want them to be loaded as dynamic you will need
to use the dynamic/1 directive in the same file before any clauses for
the predicates. Some Prolog compilers provide proprietary "consult"
built-in predicates that make all loaded code dynamic but you loose
portability if you use those built-ins.
> But ISO
> standard says for my initial example, that this would be the
> same as reading in the following text:
>
> :- dynamic(foo/1).
> foo(X) :- call(X), call(X).
>
> Right?
I assume you refer to the call:
asserta((foo(X) :- X, call(X)))
Yes, the end result would be the same.
Cheers,
Paulo
Jan Wielemaker
> On Mar 15, 7:05 pm, Jan Burse <janbu...@fastmail.fm> wrote:
>> Paulo Moura wrote:
>> But if dynamic/1 is not callable, then I think the system
>> is also less reflective.
reflective has more to do with the ability to inspect itself
(I think).
>> For example with a callable dynamic/1 we could simulate the
>> ISO assert:
>>
>> iso_assert((A:-B)) :-
>> functor(A,F,N),
>> dynamic(F/N),
>> non_iso_assert((A:-B)).
If I recall correctly, assertz is allowed on non-existing predicates.
So, making a dynamic predicate is possible by asserting a clause and
deleting it, as in
make_dynamic(F/N) :-
functor(Term, F, N),
asserta(Term),
retract(Term), !.
Of course, this is rediculous and totally flawed in multi-threaded
applications (because ISO doesn't have assertz/2 and erase/1). ISO is
pretty much wrong here: it only requires dynamic as a directive, but
it allows for an unsafe runtime work-around. I think any serious
implementation should provide dynamic as a predicate as well.
Cheers --- Jan
Paulo Moura
> ...
> If I recall correctly, assertz is allowed on non-existing predicates.
> So, making a dynamic predicate is possible by asserting a clause and
> deleting it, as in
>
> make_dynamic(F/N) :-
> functor(Term, F, N),
> asserta(Term),
> retract(Term), !.
>
> Of course, this is rediculous and totally flawed in multi-threaded
> applications (because ISO doesn't have assertz/2 and erase/1).
It surely would be nice if ISO Prolog specified asserta/2, assertz/2,
erase/1, and clause/3.
> ISO is
> pretty much wrong here: it only requires dynamic as a directive, but
> it allows for an unsafe runtime work-around.
That's a bit unfair. The ISO Prolog standard is dated from *1995*.
Moreover, requiring dynamic/1 as a directive doesn't forbid dynamic/1
also as a predicate.
> I think any serious
> implementation should provide dynamic as a predicate as well.
Sounds something that should be added to the Core Revision draft
proposal. You have my vote.
Cheers,
Paulo
Chip Eastham
Congratulations, nev, on finding this solution.
I like it; it's a portable and clean approach.
regards, chip
Jan Wielemaker
>> ...
>> If I recall correctly, assertz is allowed on non-existing predicates.
>> So, making a dynamic predicate is possible by asserting a clause and
>> deleting it, as in
>>
>> make_dynamic(F/N) :-
>> functor(Term, F, N),
>> asserta(Term),
>> retract(Term), !.
>>
>> Of course, this is rediculous and totally flawed in multi-threaded
>> applications (because ISO doesn't have assertz/2 and erase/1).
>
> It surely would be nice if ISO Prolog specified asserta/2, assertz/2,
> erase/1, and clause/3.
>
>> ISO is
>> pretty much wrong here: it only requires dynamic as a directive, but
>> it allows for an unsafe runtime work-around.
>
> That's a bit unfair. The ISO Prolog standard is dated from *1995*.
> Moreover, requiring dynamic/1 as a directive doesn't forbid dynamic/1
> also as a predicate.
You know I'm overall in favour of the ISO standard. SWI-Prolog implements
most of it faithfully. It has some places where it is more liberal and a
few where it takes different decisions for various reasons.
This is one of such mistakes. The definition and restrictions of abolish
are weird and almost ask for a runtime dynamic. That doesn't exist, but
they do support the common practice that assert/1 can be done to a sofar
unknown predicate, effectively creating a dynamic predicate at runtime.
Its not really a big deal. I guess most implementations agree on the
obvious meaningful extensions to this. Restricting abolish to dynamic
is one of the strange restrictions. If you want to remove the
clauses, use retractall/1 (as the OP found out!). Abolish was
originally there to wipe out definitions and be able to replaces them
at runtime. True, this is not a simple business in optimized and/or
multi-threaded Prolog systems. What for example if you abolish a
definition that has been inlined? It is also hard to see a good
solution for 100% reliable abolish with threads without harming
performance (too much). Probably, abolish should have been left out
of the standard.
Cheers --- Jan
Jan Burse
> definition that has been inlined? It is also hard to see a good
> solution for 100% reliable abolish with threads without harming
> performance (too much). Probably, abolish should have been left out
> of the standard.
Well actually my experience is that the abolish in
a multi-threaded interpreter is not so much a problem
if you DO NOT implement it as some retract all. You
can in one shot throw away all clauses by setting the
clause list of the predicate to empty(*). Can be done
synchronized and should be very efficient, isn't it?
Well there is some caveat since you might have other
goals calling this now abolished predicate, and suddenly
they need to throw an exception. And of course inlined
predicates are a problem, anyway for ordinary retract
and assert as well.
For the exception you can use a flag in the predicate,
so that the predicate is rehashed in all its upcoming
invocations. I consider this a small penalty, isn't it?
But I just see that there could by a glitch, when I don't
check this flag via synchronized. There could be one small
moment where the predicate goes through as defined without
any clauses, instead of undefined.
You are right, making abolish atomic AND efficient is non-trivial.
Best Regards
(*)
Works especially fine for the logical semantics of database
updates, as proposed by the ISO standard.
Jan Wielemaker
> Jan Wielemaker schrieb:
>> definition that has been inlined? It is also hard to see a good
>> solution for 100% reliable abolish with threads without harming
>> performance (too much). Probably, abolish should have been left out
>> of the standard.
>
> Well actually my experience is that the abolish in
> a multi-threaded interpreter is not so much a problem
> if you DO NOT implement it as some retract all. You
> can in one shot throw away all clauses by setting the
> clause list of the predicate to empty(*). Can be done
> synchronized and should be very efficient, isn't it?
Yes, but sooner or later you need to reclaim the old definition. I'm
not really saying it cannot be done, but it is far from trivial.
> Well there is some caveat since you might have other
> goals calling this now abolished predicate, and suddenly
> they need to throw an exception. And of course inlined
> predicates are a problem, anyway for ordinary retract
> and assert as well.
No. No sensible system will inline dynamic predicates, but any
implementation should be allowed to inline static code at will.
> For the exception you can use a flag in the predicate,
> so that the predicate is rehashed in all its upcoming
> invocations. I consider this a small penalty, isn't it?
> But I just see that there could by a glitch, when I don't
> check this flag via synchronized. There could be one small
> moment where the predicate goes through as defined without
> any clauses, instead of undefined.
>
> You are right, making abolish atomic AND efficient is non-trivial.
:-) It can be implemented safe-enough for most practical program
development problems (re-consult does something like this), but
absolutely safe and sound implementation as runtime behaviour is very
hard (if not impossible) without paying a price in synchronisation and
we would like to avoid that.
Cheers --- Jan
Jan Burse
>> clause list of the predicate to empty(*). Can be done
>> synchronized and should be very efficient, isn't it?
>
> Yes, but sooner or later you need to reclaim the old definition. I'm
> not really saying it cannot be done, but it is far from trivial.
Yes and no.
So I am assuming some GC, so the original list goes
up like a little balloon, to the roof, when it is
not used anymore.
The list contains clauses, and these clauses might
have many uses, not only in choice points, but also
through instantiations when the choice point has
already been given to the GC, for example by a cut,
and the instantiation refers to a skeleton inside
the clause.
Thus the GC has to deal with many little ballons,
eventually tied together. We could delegate this to
a GC of some host language, like a Java GC.
But isn't the question then how we can help the GC,
eventually in the later course of the execution.
Can we DYNAMICALLY analyze what previous instantiations
are not anymore used?
Bye
nev
this is not precise wording in the case of Prolog)
I have very much old files (from 1982), some of them tries override the
system's predicates, eg. I/O operations, arithmetics. Sometimes the compiler
puts a "permission error", but not allways. And if I delete something
important, I get "existence error" in runtime. I want to clean my code from
unnecessary predicates and keep the neccessary without running.
Ulrich Neumerkel
In SWI, you load your files. Then you say make/0 to get undefined predicates
listed.
Jan Burse
>> I have very much old files (from 1982), some of them tries override the
>> system's predicates, eg. I/O operations, arithmetics. Sometimes the compiler
>> puts a "permission error", but not allways. And if I delete something
>> important, I get "existence error" in runtime. I want to clean my code from
>> unnecessary predicates and keep the neccessary without running.
>
> In SWI, you load your files. Then you say make/0 to get undefined predicates
> listed.
Here you go, I guess this is done view list_undefined/0.
From the definition of this predicate I conclude that
it will not detect predicates which will become implicitly
dynamic by means of asserta/1 or assertz/1 during program
execution (as by the ISO standard).
Even if the asserta/1 or assertz/1 does not use a
constructed clause, i.e. something like:
assertz(foo(X))
And not something like:
Y=..[foo,X], assertz(Y).
Right?
Bye
Jan Wielemaker
It helps if you post the code fragment and the error message. Someone
is likely to be able to help you with proper advice.
--- Jan
Paulo Moura
> On 2010-03-15, Paulo Moura <pjlmo...@gmail.com> wrote:
> ...> ...
> >> ISO is
> >> pretty much wrong here: it only requires dynamic as a directive, but
> >> it allows for an unsafe runtime work-around.
>
> > That's a bit unfair. The ISO Prolog standard is dated from *1995*.
> > Moreover, requiring dynamic/1 as a directive doesn't forbid dynamic/1
> > also as a predicate.
>
> You know I'm overall in favour of the ISO standard. SWI-Prolog implements
> most of it faithfully. It has some places where it is more liberal and a
> few where it takes different decisions for various reasons.
With the risk of being politically incorrect, let me say that the
impact of the good ISO Prolog compliance of SWI-Prolog goes well
behind SWI-Prolog itself: due to its popularity, it provided and
continues to provide strong motivation for other Prolog compilers to
play close attention to the ISO Prolog standard :-)
> This is one of such mistakes. The definition and restrictions of abolish
> are weird and almost ask for a runtime dynamic. That doesn't exist, but
> they do support the common practice that assert/1 can be done to a sofar
> unknown predicate, effectively creating a dynamic predicate at runtime.
>
> Its not really a big deal. I guess most implementations agree on the
> obvious meaningful extensions to this. Restricting abolish to dynamic
> is one of the strange restrictions. If you want to remove the
> clauses, use retractall/1 (as the OP found out!). Abolish was
> originally there to wipe out definitions and be able to replaces them
> at runtime. True, this is not a simple business in optimized and/or
> multi-threaded Prolog systems. What for example if you abolish a
> definition that has been inlined? It is also hard to see a good
> solution for 100% reliable abolish with threads without harming
> performance (too much).
Every Prolog implementer I talk to about the origins and motivation of
the abolish/1 predicate and its (somehow at odds) specification in the
ISO Prolog standard shares the same opinion. The retractall/1 built-in
predicate is not in the ISO Prolog standard but is on the Core
Revision draft. More important, is a built-in predicate in most Prolog
compilers, making it a de facto standard. The question is: if abolish/
1 suddenly disappeared from the face of the Earth, it would be missed?
Would anyone notice?
> Probably, abolish should have been left out
> of the standard.
On the other hand, the standard provides no solution for asserting/
compiling clauses for a *static* predicate. All (or most all) Prolog
compilers provide consult/load files built-in predicates that load
clauses from a file as static predicates but that the programmer can
not take a list of clauses and do the same. SWI-Prolog provides a
compile_predicates/1 built-in. YAP provides a asserta_static/1 and
assertz_static/1 predicates. Other compilers provide their versions of
this functionality. There isn't, unfortunately, a standard solution.
Cheers,
Paulo
Ulrich Neumerkel
>On Mar 16, 8:29=A0am, Jan Wielemaker <j...@hppc323.few.vu.nl> wrote:
>Every Prolog implementer I talk to about the origins and motivation of
>the abolish/1 predicate and its (somehow at odds) specification in the
>ISO Prolog standard shares the same opinion. The retractall/1 built-in
>predicate is not in the ISO Prolog standard but is on the Core
>Revision draft. More important, is a built-in predicate in most Prolog
>compilers, making it a de facto standard. The question is: if abolish/
>1 suddenly disappeared from the face of the Earth, it would be missed?
>Would anyone notice?
If abolish/1 vanishes in SICStus 3, I would miss it. But that kind of
abolish/1 permits to remove static predicates, indeed.
>> Probably, abolish should have been left out
>> of the standard.
>
>On the other hand, the standard provides no solution for asserting/
>compiling clauses for a *static* predicate. All (or most all) Prolog
>compilers provide consult/load files built-in predicates that load
>clauses from a file as static predicates but that the programmer can
>not take a list of clauses and do the same. SWI-Prolog provides a
>compile_predicates/1 built-in. YAP provides a asserta_static/1 and
>assertz_static/1 predicates. Other compilers provide their versions of
>this functionality. There isn't, unfortunately, a standard solution.
The standard does not even specify how to compile regular code due
to the many differences that used to be between compilers and
interpreters. So dynamic (re-)compilation is clearly out of scope.
One view that was quite vehemently represented was the idea
to compile static predicates similar to C-Files producing
.o-Files and then to link them statically to the Prolog processor.
In such a context any attempt for more dynamic operations
would cause problems.
But nevertheless: I do not see any agreement on these issues lately.
It starts with the semantics. E.g. which directives processed while
compiling static predicates dynamically should be retained?
Jan Wielemaker
> On Mar 16, 8:29 am, Jan Wielemaker <j...@hppc323.few.vu.nl> wrote:
>> You know I'm overall in favour of the ISO standard. SWI-Prolog implements
>> most of it faithfully. It has some places where it is more liberal and a
>> few where it takes different decisions for various reasons.
>
> With the risk of being politically incorrect, let me say that the
> impact of the good ISO Prolog compliance of SWI-Prolog goes well
> behind SWI-Prolog itself: due to its popularity, it provided and
> continues to provide strong motivation for other Prolog compilers to
> play close attention to the ISO Prolog standard :-)
Many implementors want to be cover the ISO-Standard and meaningful
extensions and/or extensions found in other implementations. That
makes sense. It makes porting programs to an implementation easier.
As long as the implementors watch each other (and I have the
impression that is increasingly the case), it also establishes new
de-facto standard. Good.
Of course, the downside is that many developers use all the
functionality provided by the implementation on which the development
takes place, which is typically more than what ISO and commonly shared
extensions support :-(
People have mentioned the need for a strict ISO mode, but I guess the
standard is too small for that to be realistic. Ideally, we need a
comprehensive document with predicates, options, etc. and whether/how
this is implemented in each system. Something that is readily
available for web-browsers.
Yet better, this document should be machine-readable. In that case it
can be used by static checkers and it is possible to integrate the
data fairly easy in the manuals, IDE tools, etc. of the various
implementations.
In my opinion, developing such as document might be one of the most
useful enterprises in uniting the Prolog-world. This has been done
(partly) for aritmetic (was that by Ulrich?).
One option would be to start a Wiki, which 1 page per predicate. The
page documents the predicate and can provide example usage, etc. A
Wikipedia-like fact-box can document the portability. A lot of
material for this is freely available. Still of course, it is a
major enterprise to get it setup :-(
> compilers, making it a de facto standard. The question is: if abolish/
> 1 suddenly disappeared from the face of the Earth, it would be missed?
> Would anyone notice?
I see two cases of using abolish. One on dynamic code, which is
almost always wrong because it unintentionaly destroys the dynamic
attribute and there is no nice way to get this back and two is
correct, but not supported behaviour to wipe out a static predicate
and replace its definition.
>> Probably, abolish should have been left out
>> of the standard.
>
> On the other hand, the standard provides no solution for asserting/
> compiling clauses for a *static* predicate. All (or most all) Prolog
> compilers provide consult/load files built-in predicates that load
> clauses from a file as static predicates but that the programmer can
> not take a list of clauses and do the same. SWI-Prolog provides a
> compile_predicates/1 built-in. YAP provides a asserta_static/1 and
> assertz_static/1 predicates. Other compilers provide their versions of
> this functionality. There isn't, unfortunately, a standard solution.
I think that is a different issue. Nevertheless I think YAP is wrong
here (sorry, Vitor). Providing an assert_static/1 is something like
telling static isn't really static. At some point SWI-Prolog had a
similar interface, but I considered it unsafe.
compile_predicates/1 was proposed by Richard O'Keefe. The motivation
is that it works on the predicate level rather than the clause level.
Better, you can give multiple predicates. That allows the processor
to do whatever it likes to the -required by the standard- reflexive
dynamic definitions (compile, do optimizations over multiple
predicates, etc.) and finally do an atomic swap of the old dynamic
definitions by the new static ones. This can be safely implemented:
dynamic code is required to be modifyable and thus the system must
be capable to dispose the dynamic clauses safely.
Cheers --- Jan
Ulrich Neumerkel
>People have mentioned the need for a strict ISO mode, but I guess the
>standard is too small for that to be realistic.
ISO 13211-1 demands in 5.1 e such a strict mode that rejects *all*
implementation specific extensions. However, the precise way how this
strict mode is provided is not specified. That is, a conforming
implementation has to document how to enable strict mode in accordance
with 5.4.
The absence of one particular flag for strict mode is for very good
reasons. It permits a Prolog processor to offer several flags that
control extensions separately.
It would be, for example, very useful to have a strict mode for syntax
only. o yu remember iso_operators? Currently, the best way to ensure
this is to check text in IF or GNU.
One of the ideas of this mechanism is to give the user a
possibility to fathom how much code depends on a particular
implementation specific extension. This helps also to better
understand the "creeping" incompatibilities. Take syntax: We still
have no agreement how | should work as an infix operator. But it is
used heavily in DCG and CHR! This is a tiny nasty problem that you
only see if you face it. The point of a standard is to address such
things. Up to now most users do not see the problem, simply because
most implementations do not provide a strict syntax mode.
http://www.complang.tuwien.ac.at/ulrich/iso-prolog/syntax_extension
By demanding that "a mode" is able to switch off everything, it is
ensured that all extensions can be switched off. All else is left to
the creativity of implementors. Maybe they might take the chance?
>In my opinion, developing such as document might be one of the most
>useful enterprises in uniting the Prolog-world. This has been done
>(partly) for aritmetic (was that by Ulrich?).
http://www.complang.tuwien.ac.at/ulrich/iso-prolog/
There is a document about evable functors and once about built-ins.
My goal is much more benign: I would be happy to identify those
parts that block others and focus on those first.
Generally speaking, the least well known part of ISO 13211-1
is 5 Compliance.
These two DIN A4 pages define the way how implementation
specific extensions can be provided by a Prolog processor.
I wish implementors would read them.
Jan Wielemaker
Did we ever try to reach agreement on that? AFAIK, ISO dropped | (its
a bit hard to search this document properly, but it surely isn't in
the operator-table. That means | only appears as punctuation for list
head|tail. I'm not really sure what that means if we place | outside
the list context?
Anyway, in practice there is/was quite a bit of code using | as an
alternative to ;, notably in DCG. We, humble implementors, didn't
want to break compatibility. Appearently, we took two routes:
introduce it as an operator and deal with it in the DCG compiler and
normal compiler to be equivalent to ; or deal with it at the
syntax-level. The price of the latter is that you cannot use this
nice symbol for anything else, so I think that is the wrong choice.
On request of Tom Schrijvers, both YAP and SWI raised the priority of
| above ;. This is defensable. It allows for your (1;2|3;4) example
to have a more intuitive reading, while (a;(b;c)) is indistinguishable
from ((a;b);c) in the context where it is traditionally used.
I think that SICStus is wrong by changing | into ; in the reader.
This is a real burdon that makes portability of extensions such as
CHR hard.
If I quickly scan the rest of the table, things are not that severe.
Given the same operators (but the user can change these), the
interpretation is either consistent or some system produce an error
where others do not. There is something to be said for both.
Problems are easily identified and there is a simple fix.
> By demanding that "a mode" is able to switch off everything, it is
> ensured that all extensions can be switched off. All else is left to
> the creativity of implementors. Maybe they might take the chance?
I don't know. Zillions of options are hard to manage and have little
value: a global flag makes it still hard/impossible to combine code
that requires different setting of the flag. So, they only play a
role in indentifying portability issues. In my experience, there are
far more severe issues than the minor ISO incompatibilities when
porting code.
>>In my opinion, developing such as document might be one of the most
>>useful enterprises in uniting the Prolog-world. This has been done
>>(partly) for aritmetic (was that by Ulrich?).
>
> http://www.complang.tuwien.ac.at/ulrich/iso-prolog/
>
> There is a document about evable functors and once about built-ins.
>
> My goal is much more benign: I would be happy to identify those
> parts that block others and focus on those first.
These tables are very valuable. It would be even greater if they
covered more ground.
Cheers --- Jan
Ulrich Neumerkel
No. The purpose of the document is to survey the current state
in the hope of getting some consensus.
>On request of Tom Schrijvers, both YAP and SWI raised the priority of
>| above ;. This is defensable. It allows for your (1;2|3;4) example
>to have a more intuitive reading, while (a;(b;c)) is indistinguishable
>from ((a;b);c) in the context where it is traditionally used.
>
>I think that SICStus is wrong by changing | into ; in the reader.
>This is a real burdon that makes portability of extensions such as
>CHR hard.
Let's try to avoid distinguishing between right and wrong. Even
Prologs answer true/false or yes/no but not right/wrong.
SICStus represents the traditional approach that now faces CHR. I
wonder how this is currently handled within SICStus since it does
support CHR. Doesn't it?
What I hope is that with an agreement strict syntax can be
realistically enforced. Currently | as infix is a welcome
pretext to avoid offering a strict syntax mode in most systems.
>> By demanding that "a mode" is able to switch off everything, it is
>> ensured that all extensions can be switched off. All else is left to
>> the creativity of implementors. Maybe they might take the chance?
>
>I don't know. Zillions of options are hard to manage and have little
>value: ...
You only have zillions of options if you have zillions of different
kinds of extensions. See?
If an implementer believes to extend ISO Prolog he should at
least be prepared to take the burden to offer a way to switch
that thing off.
Also, by making the issue visible to users the self-extension
mechanism of 13211-1 might get started. Haven't we seen that recently
when discussing evaluation issues?
> In my experience, there are
>far more severe issues than the minor ISO incompatibilities when
>porting code.
You never mentioned such issues. And I fail to see them. That
argument is the "standard" killer argument - the reason why we have
no progress at all. Getting strict syntax would be progress.
>These tables are very valuable. It would be even greater if they
>covered more ground.
Thanks. The larger the tables the smaller the chance to get
anything changed. That's the old pitfall in standardization.
Jan Wielemaker
> Jan Wielemaker <ja...@hppc323.few.vu.nl> writes:
>>On 2010-03-20, Ulrich Neumerkel <ulr...@mips.complang.tuwien.ac.at> wrote:>
>>> http://www.complang.tuwien.ac.at/ulrich/iso-prolog/syntax_extension
>>
>>Did we ever try to reach agreement on that?
>
> No. The purpose of the document is to survey the current state
> in the hope of getting some consensus.
>
>>On request of Tom Schrijvers, both YAP and SWI raised the priority of
>>| above ;. This is defensable. It allows for your (1;2|3;4) example
>>to have a more intuitive reading, while (a;(b;c)) is indistinguishable
>>from ((a;b);c) in the context where it is traditionally used.
>>
>>I think that SICStus is wrong by changing | into ; in the reader.
>>This is a real burdon that makes portability of extensions such as
>>CHR hard.
>
> Let's try to avoid distinguishing between right and wrong. Even
> Prologs answer true/false or yes/no but not right/wrong.
I agree that right/wrong is dangerous wording. Still, if things need
changing there are some arguments. Number of systems that need to
change and compatibility are obvious, but consistency/cleanlyness/etc
are certainly aspects too.
> SICStus represents the traditional approach that now faces CHR. I
> wonder how this is currently handled within SICStus since it does
> support CHR. Doesn't it?
I don't know. Tom, Mats, ...?
>>> By demanding that "a mode" is able to switch off everything, it is
>>> ensured that all extensions can be switched off. All else is left to
>>> the creativity of implementors. Maybe they might take the chance?
>>
>>I don't know. Zillions of options are hard to manage and have little
>>value: ...
>
> You only have zillions of options if you have zillions of different
> kinds of extensions. See?
Yes, but that is a fact of life, isn't it. Extra syntax, extra
arithmetic types, extra predicates (which are in the strict sense
also extensions you need to be able to switch off), etc.
> If an implementer believes to extend ISO Prolog he should at
> least be prepared to take the burden to offer a way to switch
> that thing off.
>
> Also, by making the issue visible to users the self-extension
> mechanism of 13211-1 might get started. Haven't we seen that recently
> when discussing evaluation issues?
That discussion was certainly useful. I hope some implemetors will
relax and add floor(I->I). That would certainly have been my
conclusion if I would have encountered this problem. I don't see
much value in adding a flag integer_rounding_functions_float_only.
>> In my experience, there are
>>far more severe issues than the minor ISO incompatibilities when
>>porting code.
>
> You never mentioned such issues. And I fail to see them. That
> argument is the "standard" killer argument - the reason why we have
> no progress at all. Getting strict syntax would be progress.
I most certainly have mentioned such issues in various discussions on
this subject. More below. There *is* progress. Just, it isn't in
officially signed documents, but in (small) changes of Prolog
implementations that care. Most is demand-driven (or incident-driven
if you wish to be a bit more cynical :-).
You've probably seen lots of GIT commits for SWI-Prolog comming along
that enhance portability to SICStus. They are the result of the
desire to connect a large SICStus application (the Alpino NLP parser
suite) to SWI-Prolog, so we can use them tightly intergrated with the
SWI-Prolog web and semantic-web libraries. Here is a very brief
summary of the issues encountered. SICStus is version 3 here; maybe
some do not apply to 4.
* Arithmetic #/2 (SICStus) vs. xor/2 in SWI.
-> Fixed using :- arithmetic_function in SWI
* Arithmetic integer/1 in SICStus is like truncate/1, where
SWI's is like round/1. Round was actually more desirable,
bug SICStus round is (F->F), where SWI's is (F->I) (which is ISO).
-> Application now uses integer(round(F)) :-(
* SICStus has safe references in assertz/2, clause/3, etc.
-> Added to SWI
* SICStus can assert clauses with constraints.
-> Wrap assert, using copy_term/3 to create a normal clause.
* SICStus has call_residue/2. -> Fixed in the application to
use copy_term/3.
* SICStus has block/1 directive. Initially fixed by source-translation
using a when-wrapped predicate. Eventually, the application now
uses when/2.
* SICStus has bi-directional streams used in the socket library.
-> SWI added stream_pair/3 to create a linked pair of streams
that are handled by the I/O predicates.
* SICStus write/1 emits minimal spacing. Seems ISO describes
write this way, so this is now also the default in SWI, with
an option to write_term/3 to get the old behaviour.
* SICStus format ~a accepts strings. Added to SWI, but as
deprecated ([] is ambiguous).
* Lots of library issues, fixed by emulation (too long to describe
here).
Syntax errors (after defining some operators such as public): 0.
No progress?
>>These tables are very valuable. It would be even greater if they
>>covered more ground.
>
> Thanks. The larger the tables the smaller the chance to get
> anything changed. That's the old pitfall in standardization.
They are very valuable to us implementers if we get into a discussion
like Prolog X does it like this, you do it like that.
Cheers --- Jan
Ulrich Neumerkel
>On 2010-03-22, Ulrich Neumerkel <ulr...@mips.complang.tuwien.ac.at> wrote:
>> Jan Wielemaker <ja...@hppc323.few.vu.nl> writes:
>>>On 2010-03-20, Ulrich Neumerkel <ulr...@mips.complang.tuwien.ac.at> wrote:
>>>> By demanding that "a mode" is able to switch off everything, it is
>>>> ensured that all extensions can be switched off. All else is left to
>>>> the creativity of implementors. Maybe they might take the chance?
>>>I don't know. Zillions of options are hard to manage and have little
>>>value: ...
>> You only have zillions of options if you have zillions of different
>> kinds of extensions. See?
>Yes, but that is a fact of life, isn't it. Extra syntax, extra
>arithmetic types, extra predicates (which are in the strict sense
>also extensions you need to be able to switch off), etc.
Extra predicates must be disabled in strict mode. There is no
strict sense needed to come to that conclusion. Just read
5.1 e.
By insisting on this point your inclination is increased to put those
things into a library or into the standard. Both ways are preferable
to just adding extra predicates and thereby reducing portability.
>> If an implementer believes to extend ISO Prolog he should at
>> least be prepared to take the burden to offer a way to switch
>> that thing off.
>>
>> Also, by making the issue visible to users the self-extension
>> mechanism of 13211-1 might get started. Haven't we seen that recently
>> when discussing evaluation issues?
>
>That discussion was certainly useful. I hope some implemetors will
>relax and add floor(I->I). That would certainly have been my
>conclusion if I would have encountered this problem. I don't see
>much value in adding a flag integer_rounding_functions_float_only.
And what about ieee_floats or another flag to that end?
Currently SWI does not have them.
>>> In my experience, there are
>>>far more severe issues than the minor ISO incompatibilities when
>>>porting code.
>>
>> You never mentioned such issues. And I fail to see them. That
>> argument is the "standard" killer argument - the reason why we have
>> no progress at all. Getting strict syntax would be progress.
>
>I most certainly have mentioned such issues in various discussions on
>this subject.
Not within WG17.
>No progress?
Progress yes. And I see lot's of convergences towards 13211-1 in
between! But this is a different kind of progress. It is
driven by one code base you want to port. That is not a very
sustainable approach.
The point of the extension mechanism within 13211-1 is to make
the continual development of the language sustainable. Of course
that necessitates reading 5 Compliance - as I said a burden
on an ecyclopedic scale: two pages - and possibly discussing it.
>They are very valuable to us implementers if we get into a discussion
>like Prolog X does it like this, you do it like that.
Discussions of that kind happened in the last 15 years. Look
at the table for built-in predicates: There was not much
feedback from implementers either. See the systems where
there was interest. I.e., I did not receive response from
other systems.
http://www.complang.tuwien.ac.at/ulrich/iso-prolog/built-in_predicates
Jan Wielemaker
> Jan Wielemaker <ja...@hppc323.few.vu.nl> writes:
>>On 2010-03-22, Ulrich Neumerkel <ulr...@mips.complang.tuwien.ac.at> wrote:
> Extra predicates must be disabled in strict mode. There is no
> strict sense needed to come to that conclusion. Just read
> 5.1 e.
I certainly see the reason for this, but the practical value is
limited. SWI-Prolog relaxes this problem by allowing silent
redefinition of predicates that are not ISO. That works pretty
much ok as long as code is in modules (and thus global overruling
of built-ins is avoided).
>>That discussion was certainly useful. I hope some implemetors will
>>relax and add floor(I->I). That would certainly have been my
>>conclusion if I would have encountered this problem. I don't see
>>much value in adding a flag integer_rounding_functions_float_only.
>
> And what about ieee_floats or another flag to that end?
> Currently SWI does not have them.
What would be the meaning of that flag?
>>No progress?
>
> Progress yes. And I see lot's of convergences towards 13211-1 in
> between! But this is a different kind of progress. It is
> driven by one code base you want to port. That is not a very
> sustainable approach.
Well, I see this a bit different. For a long time (and I think Paulo
can confirm this), writing a portable Prolog program was a super-human
effort. As it stands, it appears that the work of Paulo, Tom, Markus
and others have created enough common ground to make such enterprises
feasible. At least between a group of Prolog implementations. The
more code-bases are shared, the more common ground we get and the
easier it gets to share more *and* extend the standard.
> The point of the extension mechanism within 13211-1 is to make
> the continual development of the language sustainable. Of course
> that necessitates reading 5 Compliance - as I said a burden
> on an ecyclopedic scale: two pages - and possibly discussing it.
>
>>They are very valuable to us implementers if we get into a discussion
>>like Prolog X does it like this, you do it like that.
>
> Discussions of that kind happened in the last 15 years. Look
> at the table for built-in predicates: There was not much
> feedback from implementers either. See the systems where
> there was interest. I.e., I did not receive response from
> other systems.
>
> http://www.complang.tuwien.ac.at/ulrich/iso-prolog/built-in_predicates
We are all very busy people. Tables like this are very valuable for
Prolog implementations that care about portability. Issues that come
up (e.g., raised by users) can be resolved quickly and with some
confidence that we are working towards conversion. As stated above,
conversion invites aiming at portability, which invites more
conversion, etc.
I'm not all that negative :-) The ISO standard has done a good job.
I'm happy if it is extended further, but maybe we reach a point where
conversion instead of diversion starts to happen naturally.
Cheers --- Jan
Ulrich Neumerkel
>On 2010-03-22, Ulrich Neumerkel <ulr...@mips.complang.tuwien.ac.at> wrote:
>> Jan Wielemaker <ja...@hppc323.few.vu.nl> writes:
>>>On 2010-03-22, Ulrich Neumerkel <ulr...@mips.complang.tuwien.ac.at> wrote:
>
>> Extra predicates must be disabled in strict mode. There is no
>> strict sense needed to come to that conclusion. Just read
>> 5.1 e.
>
>I certainly see the reason for this, but the practical value is
>limited. SWI-Prolog relaxes this problem by allowing silent
>redefinition of predicates that are not ISO. That works pretty
>much ok as long as code is in modules (and thus global overruling
>of built-ins is avoided).
That is not the point of 5.1 e. Without it the mechanisms of 13211-1
will not start working. You can continue without it, but just look
back to see how fast things work without it.
>> And what about ieee_floats or another flag to that end?
>> Currently SWI does not have them.
>
>What would be the meaning of that flag?
That X is 1/0. and the like behave according to LIA and IEEE which are
standards with certain freedom of interpretation as well, BTW. I
thought that this was discussed here in comp.lang.prolog some time
ago too. It would be nice if systems would agree on one *exact* way
how to do this. Joachim Schimpf produced a first document
in that direction. It is:
http://eclipse-clp.org/Specs/core_update_float.html
There has not been any discussion on this. My interest in this
is primarily what exact impact this would have on 5 Compliance.
>>>No progress?
>>
>> Progress yes. And I see lot's of convergences towards 13211-1 in
>> between! But this is a different kind of progress. It is
>> driven by one code base you want to port. That is not a very
>> sustainable approach.
>
>Well, I see this a bit different. For a long time (and I think Paulo
>can confirm this), writing a portable Prolog program was a super-human
>effort. As it stands, it appears that the work of Paulo, Tom, Markus
>and others have created enough common ground to make such enterprises
>feasible. At least between a group of Prolog implementations. The
>more code-bases are shared, the more common ground we get and the
>easier it gets to share more *and* extend the standard.
Any convergence is fine. But I do not see how you cope with standard
issues at all. Is there some progress I miss?
>> http://www.complang.tuwien.ac.at/ulrich/iso-prolog/built-in_predicates
>
>We are all very busy people.
Clearly not busy enough to appreciate that the mechanism of
5 Compliance would reduce a lot of entirely unnecessary work.
Paulo Moura
> On 2010-03-22, Ulrich Neumerkel <ulr...@mips.complang.tuwien.ac.at> wrote:
> > Progress yes. And I see lot's of convergences towards 13211-1 in
> > between! But this is a different kind of progress. It is
> > driven by one code base you want to port. That is not a very
> > sustainable approach.
>
> Well, I see this a bit different. For a long time (and I think Paulo
> can confirm this), writing a portable Prolog program was a super-human
> effort. As it stands, it appears that the work of Paulo, Tom, Markus
> and others have created enough common ground to make such enterprises
> feasible. At least between a group of Prolog implementations. The
> more code-bases are shared, the more common ground we get and the
> easier it gets to share more *and* extend the standard.
I wouldn't say a super-human effort but spending more development time
dealing with portability issues rather than developing the application
itself was not fun. Usually, one ended up writing a lot of glue code
and hacking around missing built-in predicates. The lack of
standardization also worked as a straight-jacket, limiting the
features of portable applications. Some of the missing predicates were
pretty common and present with the same or close semantics in some but
not all systems. Eventually this prompted me to start working on what
would become the ISO Prolog Core Revision draft proposal (http://
logtalk.org/plstd/core.pdf), first present at the WG17 meeting at ICLP
2006, in Seattle. Despite being a draft, this proposal was quite
successful and have been used as a guide by several systems, whose
developers took very little convincing to implement some of the most
common missing predicates and arithmetic functions. This actual
convergence helped me e.g. to reduce the amount of glue code in
Logtalk and, I assume, in the work of others. Software such as Tom's
CHR and Markus's CLP(FD), both found today in several systems, further
contributed to make systems converge. Portable libraries such as the
Parma Polyhedra Library also helped here. I will not try to mention
all here as I will inevitably miss some. Taken together, all the code
that stubborn developers insisted in making portable helped to the
convergence we witness today :-)
> > The point of the extension mechanism within 13211-1 is to make
> > the continual development of the language sustainable. Of course
> > that necessitates reading 5 Compliance - as I said a burden
> > on an ecyclopedic scale: two pages - and possibly discussing it.
>
> >>They are very valuable to us implementers if we get into a discussion
> >>like Prolog X does it like this, you do it like that.
>
> > Discussions of that kind happened in the last 15 years. Look
> > at the table for built-in predicates: There was not much
> > feedback from implementers either.
In general, and for the past 12 years, I had a very good experience in
going directly to the Prolog implementers and talk with them in
implementing missing bits. This was (and still is) a bit of a stealth
work but helps moving things forward.
> I'm not all that negative :-) The ISO standard has done a good job.
> I'm happy if it is extended further, but maybe we reach a point where
> conversion instead of diversion starts to happen naturally.
From my point-of-view, that's already happening :-)
Cheers,
Paulo
Jan Wielemaker
> Jan Wielemaker <ja...@hppc323.few.vu.nl> writes:
>>On 2010-03-22, Ulrich Neumerkel <ulr...@mips.complang.tuwien.ac.at> wrote:
>>> Jan Wielemaker <ja...@hppc323.few.vu.nl> writes:
>>>>On 2010-03-22, Ulrich Neumerkel <ulr...@mips.complang.tuwien.ac.at> wrote:
>>
>>> Extra predicates must be disabled in strict mode. There is no
>>> strict sense needed to come to that conclusion. Just read
>>> 5.1 e.
>>
>>I certainly see the reason for this, but the practical value is
>>limited. SWI-Prolog relaxes this problem by allowing silent
>>redefinition of predicates that are not ISO. That works pretty
>>much ok as long as code is in modules (and thus global overruling
>>of built-ins is avoided).
>
> That is not the point of 5.1 e. Without it the mechanisms of 13211-1
> will not start working. You can continue without it, but just look
> back to see how fast things work without it.
I just come to the conclusion that in the large porting project I
already menitioned before, none of this proved to be an issue. A
strict mode would not have helped at all because it simply could
have loaded nothing of the application (e.g. :- module(...)).
> Clearly not busy enough to appreciate that the mechanism of
> 5 Compliance would reduce a lot of entirely unnecessary work.
I doubt it. See Paulo's reaction. I think his feedback from
practical experience is very relevant.
Cheers --- Jan
Paulo Moura
> On 2010-03-22, Ulrich Neumerkel <ulr...@mips.complang.tuwien.ac.at> wrote:
>
> >>On 2010-03-22, Ulrich Neumerkel <ulr...@mips.complang.tuwien.ac.at> wrote:
> >>>>On 2010-03-22, Ulrich Neumerkel <ulr...@mips.complang.tuwien.ac.at> wrote:
>
> >>> Extra predicates must be disabled in strict mode. There is no
> >>> strict sense needed to come to that conclusion. Just read
> >>> 5.1 e.
>
> >>I certainly see the reason for this, but the practical value is
> >>limited. SWI-Prolog relaxes this problem by allowing silent
> >>redefinition of predicates that are not ISO. That works pretty
> >>much ok as long as code is in modules (and thus global overruling
> >>of built-ins is avoided).
>
> > That is not the point of 5.1 e. Without it the mechanisms of 13211-1
> > will not start working. You can continue without it, but just look
> > back to see how fast things work without it.
>
> I just come to the conclusion that in the large porting project I
> already menitioned before, none of this proved to be an issue. A
> strict mode would not have helped at all because it simply could
> have loaded nothing of the application (e.g. :- module(...)).
That's also my experience. The ISO Prolog standard, in its current
form, is too minimal for most actual applications. Using a
"strict_iso" flag as implemented by GNU Prolog or, I think, the "iso"
flag as implemented in IF/Prolog, would only tell us what we already
know: the application would not run or even load in this restricted
mode.
This strict flag could be useful if, instead of rejecting
implementation specific features (5.1e), simply printed a warning for
all non-ISO built-in predicate/directive/function used on a
application. This is basically what the Logtalk "portability" flag
does. When an object (or a category) is compiled, calls to built-in
predicates that are not in ISO will result in a compilation warning
when the "portability" flag is set to warning. A similar flag can
easily be implemented for Prolog module systems. I use this flag
routinely and I find it quite useful when porting code. Of course,
this flag cannot detect all portability issues as two Prolog compilers
can provide e.g. the same ISO Prolog built-in predicate but without
the same exact semantics. Ideally, this flag would be complemented by
a comprehensive set of unit tests for ISO Prolog compliance.
> > Clearly not busy enough to appreciate that the mechanism of
> > 5 Compliance would reduce a lot of entirely unnecessary work.
>
> I doubt it. See Paulo's reaction. I think his feedback from
> practical experience is very relevant.
A practical and painful experience. But thanks to you and other Prolog
implementers, writing portable applications is becoming more and more
feasible everyday :-)
Cheers,
Paulo
Ulrich Neumerkel
>On Mar 28, 10:40=A0am, Jan Wielemaker <j...@hppc323.few.vu.nl> wrote:
>> On 2010-03-22, Ulrich Neumerkel <ulr...@mips.complang.tuwien.ac.at> wrote=
>:
>>
>> > Jan Wielemaker <j...@hppc323.few.vu.nl> writes:
>> >>On 2010-03-22, Ulrich Neumerkel <ulr...@mips.complang.tuwien.ac.at> wro=>> >>>>On 2010-03-22, Ulrich Neumerkel <ulr...@mips.complang.tuwien.ac.at> w=
>rote:
>>
>> >>> Extra predicates must be disabled in strict mode. =A0There is no
>> >>> strict sense needed to come to that conclusion. =A0Just read
>> >>> 5.1 e.
>>
>> >>I certainly see the reason for this, but the practical value is
>> >>redefinition of predicates that are not ISO. =A0That works pretty
>> >>much ok as long as code is in modules (and thus global overruling
>> >>of built-ins is avoided).
>>
>> > will not start working. =A0You can continue without it, but just look
>> > back to see how fast things work without it.
>>
>> I just come to the conclusion that in the large porting project I
>> strict mode would not have helped at all because it simply could
>> have loaded nothing of the application (e.g. :- module(...)).
>
>That's also my experience. The ISO Prolog standard, in its current
>form, is too minimal for most actual applications. Using a
>"strict_iso" flag as implemented by GNU Prolog or, I think, the "iso"
>flag as implemented in IF/Prolog, would only tell us what we already
>know: the application would not run or even load in this restricted
>mode.
A strict iso flag is not demanded by ISO. It is a possible
way to fulfill 5.1 e, but there are better ways for
good reason - part of which you are elaborating here!
What ISO demands in 5.1 e is that any extension must be provided
in such a manner that it can be turned off. Somehow. That
ensures that a simple user can see what he depends on. That
ensures that implementors don't produce extensions nonchalantly
when another way to solve the problem would be possible.
In fact:
Some extensions can be replaced by standard predicates.
Some extensions can be put into libraries instead.
And some of extensions should go into the standard.
However, the current situation is quite different:
There are so many extensions that it is impossible to
distinguish between those that are actually needed and
those that are not.
A mode to signal warnings, as you suggest, or maybe even
errors, would definitely be a step in that direction.
>> > Clearly not busy enough to appreciate that the mechanism of
>> > 5 Compliance would reduce a lot of entirely unnecessary work.
>>
>> I doubt it. See Paulo's reaction. think his feedback from
>> practical experience is very relevant.
Of course practical experience is of relevance. But it will
at best lead to superficial conversion between some systems
only.
>A practical and painful experience. But thanks to you and other Prolog
>implementers, writing portable applications is becoming more and more
>feasible everyday :-)
Just take a step back: How many people currently produce
feedback of relevance for portability and standardization?
Didn't you enumerate them exhaustively already?
5.1 e can change that situation. If everything depends on
only a few, things cannot change much.
Paulo Moura
Neumerkel) wrote:
> Paulo Moura <pjlmo...@gmail.com> writes:
> ...
> >That's also my experience. The ISO Prolog standard, in its current
> >form, is too minimal for most actual applications. Using a
> >"strict_iso" flag as implemented by GNU Prolog or, I think, the "iso"
> >flag as implemented in IF/Prolog, would only tell us what we already
> >know: the application would not run or even load in this restricted
> >mode.
>
> A strict iso flag is not demanded by ISO. It is a possible
> way to fulfill 5.1 e, but there are better ways for
> good reason - part of which you are elaborating here!
>
> What ISO demands in 5.1 e is that any extension must be provided
> in such a manner that it can be turned off. Somehow. That
> ensures that a simple user can see what he depends on. That
> ensures that implementors don't produce extensions nonchalantly
> when another way to solve the problem would be possible.
For some extensions, it would be a simple matter of not loading them,
But I wonder what the possible performance penalty would be to be able
to turn off built-in predicates.
As far as ensuring, as you wrote above, that the user can see what we
depends on, that's a job for a cross-referencer. One thing that helps
here is providing comprehensive reflection support, including, as
already found on some compilers, predicate properties that tells the
user (or a tool) if e.g. a built-in predicate is specified by ISO or
provided by some library/extension.
> In fact:
>
> Some extensions can be replaced by standard predicates.
> Some extensions can be put into libraries instead.
> And some of extensions should go into the standard.
True. But this is a dynamic process. E.g. a library predicate becomes
more and more used and demands for better performance lead developers
to implement it as a built-in predicate. Or built-in predicates are
deprecated and moved to a compatibility library. Any solution must
deal gracefully with this kind of changes that are inevitable as a
programming language evolves.
> However, the current situation is quite different:
>
> There are so many extensions that it is impossible to
> distinguish between those that are actually needed and
> those that are not.
My answer here is: natural selection. Those extensions that have
applications/users will evolve and become more and more mature, better
documented, better tested. Some of them can be redundant from a strict
point-of-view but programmers often (justifiably) prefer convenience
to minimalism.
Cheers,
Paulo
Ulrich Neumerkel
>On Mar 30, 3:05=A0pm, ulr...@mips.complang.tuwien.ac.at (Ulrich
>Neumerkel) wrote:
>> What ISO demands in 5.1 e is that any extension must be provided
>> ensures that a simple user can see what he depends on. =A0That
>> ensures that implementors don't produce extensions nonchalantly
>> when another way to solve the problem would be possible.
>
>For some extensions, it would be a simple matter of not loading them,
>But I wonder what the possible performance penalty would be to be able
>to turn off built-in predicates.
No performance penality. Preparation for execution has to take
such a mode into account anyway. You probably think of switching
the flag between preparation for execution and execution itself.
I don't see why those have to behave consistently. Maybe that
is possible too.
>As far as ensuring, as you wrote above, that the user can see what we
>depends on, that's a job for a cross-referencer. One thing that helps
>here is providing comprehensive reflection support, including, as
>already found on some compilers, predicate properties that tells the
>user (or a tool) if e.g. a built-in predicate is specified by ISO or
>provided by some library/extension.
A cross-referencer can detect some of the problems. Not all of them.
It cannot detect dependencies on IEEE arithmetics. You can never
be sure to load a program at all since you might have collisions
with built-in predicates.
Brief: 5.1 e is the minimal way to demand a mechanism for all of
this.
>> There are so many extensions that it is impossible to
>> distinguish between those that are actually needed and
>> those that are not.
>
>My answer here is: natural selection. Those extensions that have
>applications/users will evolve and become more and more mature, better
>documented, better tested. Some of them can be redundant from a strict
>point-of-view but programmers often (justifiably) prefer convenience
>to minimalism.
Natural selection is a mechanism for a time scale well above our
scale. And I do not like the idea of extinction in that context.
Paulo Moura
Neumerkel) wrote:
> Paulo Moura <pjlmo...@gmail.com> writes:
> >On Mar 30, 3:05=A0pm, ulr...@mips.complang.tuwien.ac.at (Ulrich
> >Neumerkel) wrote:
> >> What ISO demands in 5.1 e is that any extension must be provided
> >> in such a manner that it can be turned off. =A0Somehow. =A0That
> >> ensures that a simple user can see what he depends on. =A0That
> >> ensures that implementors don't produce extensions nonchalantly
> >> when another way to solve the problem would be possible.
>
> >For some extensions, it would be a simple matter of not loading them,
> >But I wonder what the possible performance penalty would be to be able
> >to turn off built-in predicates.
>
> No performance penality. Preparation for execution has to take
> such a mode into account anyway. You probably think of switching
> the flag between preparation for execution and execution itself.
No. I'm thinking of all the meta-programming cases where a goal is
generated at runtime. As you wrote above:
"What ISO demands in 5.1 e is that any extension must be provided in
such a manner that it can be turned off."
Thus, all built-in meta-predicates must be able to check at runtime if
a meta-argument is going to call something that is turned off. How do
you do that without any performance penalty?
Cheers,
Paulo
Ulrich Neumerkel
>On Mar 30, 7:24=A0pm, ulr...@mips.complang.tuwien.ac.at (Ulrich>> >On Mar 30, 3:05=3DA0pm, ulr...@mips.complang.tuwien.ac.at (Ulrich
>> >Neumerkel) wrote:
>> >> What ISO demands in 5.1 e is that any extension must be provided
>> >> ensures that a simple user can see what he depends on. =3DA0That
>> >> ensures that implementors don't produce extensions nonchalantly
>> >> when another way to solve the problem would be possible.
>>
>> >For some extensions, it would be a simple matter of not loading them,
>> >But I wonder what the possible performance penalty would be to be able
>> >to turn off built-in predicates.
>>
>> such a mode into account anyway. =A0You probably think of switching
>> the flag between preparation for execution and execution itself.
>
>No. I'm thinking of all the meta-programming cases where a goal is
>generated at runtime. As you wrote above:
>
>"What ISO demands in 5.1 e is that any extension must be provided in
>such a manner that it can be turned off."
>
>Thus, all built-in meta-predicates must be able to check at runtime if
>a meta-argument is going to call something that is turned off. How do
>you do that without any performance penalty?
True, there will be a very slight overhead in that situation.
But that very situation cannot be covered by the cross-referencer
you were referring to. So 5.1 e will produce the information you
need about that case, whereas the tool you suggest cannot produce
that information.
Just rethink the current situation: Without 5.1 e you cannot even
be sure that a simple fact can be compiled! You effectively
need a "blacklist" of predicate names used in other systems.
Paulo Moura
5.1e will produce the information I need how? 5.1e is just a *demand*
for a mechanism, not a mechanism *design* or a mechanism
*implementation*. On the other hand, cross-referecers and unit test
frameworks are available now. Moreover, what would prevent a cross-
referencer to use the same infra-structure necessary for a 5.1e
implementation and thus providing the same information?
> Just rethink the current situation: Without 5.1 e you cannot even
> be sure that a simple fact can be compiled!
There is no implementation, AFAIK, of a 5.1e mechanism to either prove
or disprove your claim.
> You effectively
> need a "blacklist" of predicate names used in other systems.
Or a portable encapsulation mechanism that minimizes predicate-name
collisions using a proper predicate namespace implementation. Oh...
wait... :-)
Cheers,
Paulo
Ulrich Neumerkel
>On Mar 31, 4:44=A0pm, ulr...@mips.complang.tuwien.ac.at (Ulrich
>Neumerkel) wrote:
>> True, there will be a very slight overhead in that situation.
>> But that very situation cannot be covered by the cross-referencer
>> you were referring to. So 5.1 e will produce the information you
>> need about that case, whereas the tool you suggest cannot produce
>> that information.
>
>5.1e will produce the information I need how?
By comparing execution in strict and non-strict mode.
> 5.1e is just a *demand*
>for a mechanism, not a mechanism *design* or a mechanism
>*implementation*.
By fulfilling 5.1 e we have some mechanism to that end. That's
the entire point of 5.1 e.
> On the other hand, cross-referecers and unit test
>frameworks are available now. Moreover, what would prevent a cross-
>referencer to use the same infra-structure necessary for a 5.1e
>implementation and thus providing the same information?
You can always produce a further layer atop. By this you
reduplicate the effort. And your cross-referencer cannot ensure
that a dynamic goal is executed correctly.
>> Just rethink the current situation: Without 5.1 e you cannot even
>> be sure that a simple fact can be compiled!
>
>There is no implementation, AFAIK, of a 5.1e mechanism to either prove
>or disprove your claim.
IF has it. Not sure about the precise implementation in GNU.
And: That wasn't such a complex claim to require any implementation
for proving or disproving. Reading would suffice.
>> You effectively
>> need a "blacklist" of predicate names used in other systems.
>
>Or a portable encapsulation mechanism that minimizes predicate-name
>collisions using a proper predicate namespace implementation. Oh...
>wait... :-)
This is not about minimizing collisions. It is about avoiding
them.
Once again: Adding another layer does not reduce complexity.
Quite the opposite. Apart from that, you cannot identify
the other kind of problems. Like floats or syntax extensions.
Paulo Moura
Neumerkel) wrote:
> Paulo Moura <pjlmo...@gmail.com> writes:
> >On Mar 31, 4:44=A0pm, ulr...@mips.complang.tuwien.ac.at (Ulrich
> >Neumerkel) wrote:
> >> True, there will be a very slight overhead in that situation.
> >> But that very situation cannot be covered by the cross-referencer
> >> you were referring to. So 5.1 e will produce the information you
> >> need about that case, whereas the tool you suggest cannot produce
> >> that information.
>
> >5.1e will produce the information I need how?
>
> By comparing execution in strict and non-strict mode.
>
> > 5.1e is just a *demand*
> >for a mechanism, not a mechanism *design* or a mechanism
> >*implementation*.
>
> By fulfilling 5.1 e we have some mechanism to that end. That's
> the entire point of 5.1 e.
Comparing execution how, given that most applications will not execute
in strict mode? Fulfilling how? Without further details on a 5.1e
implementation there is little meat here to warrant further
discussion. I cannot compare vaporware with actual, existing tools.
> > On the other hand, cross-referecers and unit test
> >frameworks are available now. Moreover, what would prevent a cross-
> >referencer to use the same infra-structure necessary for a 5.1e
> >implementation and thus providing the same information?
>
> You can always produce a further layer atop. By this you
> reduplicate the effort. And your cross-referencer cannot ensure
> that a dynamic goal is executed correctly.
>
> >> Just rethink the current situation: Without 5.1 e you cannot even
> >> be sure that a simple fact can be compiled!
>
> >There is no implementation, AFAIK, of a 5.1e mechanism to either prove
> >or disprove your claim.
>
> IF has it.
IF/Prolog is a discontinued product, the last time I checked its home
page. In the past I tried twice to get a trial key for the IF/Prolog
demo. Never got a reply to my mails.
> Not sure about the precise implementation in GNU.
The "strict_iso" flag in GNU Prolog simply changes the behavior of a
few built-in predicates (e.g. current_predicate/1 and
predicate_property/2). From the public GNU Prolog documentation:
The strict_iso flag is introduced to allow a compatibility with other
Prolog systems. When turned off the following relaxations apply:
* a callable term can be given as a predicate indicator.
* built-in predicates are found by current_predicate/1 (section
7.8.1).
Setting the "strict_iso" to "on" *does not* prevent calling of the non-
ISO built-in predicates implemented by GNU Prolog (tested with 1.3.2).
Thus, this flag does not provide with you with an implementation of
5.1e.
> And: That wasn't such a complex claim to require any implementation
> for proving or disproving. Reading would suffice.
How nice. Specially when you are promoting a mechanism and you don't
even know the details of one of the two implementations you cite above
(despite GNU Prolog being the only one that is currently available).
Not that you provide any details on the other one either.
Bye,
Paulo
Ulrich Neumerkel
>... I cannot compare vaporware with actual, existing tools.
>How nice. Specially when you are promoting a mechanism and you don't
>even know the details of ...
Please consider this discussion terminated on my part.