Ragerding my questions about memory leaks: one problem is solved - this was memory fragmentation, but caused not by Prolog, but by legacy module written in C and having very poor memory management. Prolog was crashing because it was not able to get memory.
Pre-alocating memory to Prolog shifted crashes to other places and this way we discovered the real source of problems.
However, coming back to basics... Bart posted the following program:
a(N,_) :- N > 0, M is N - 1, a(M,foo(1,2,3,4,5)). a(N,_) :- N =< 0.
When executed on SICStus with sufficiently large N it takes 200 MB. Questoon: is it possible to raclaim this memory and how? Or this is memory leak?
I am not asking how to modify this program in such a way that it will NOT consume thsi much memory. Question is how to get this memory back.
> Ragerding my questions about memory leaks: one problem is solved - > this was memory fragmentation, but caused not by Prolog, but by legacy > module written in C and having very poor memory management. Prolog was > crashing because it was not able to get memory.
> Pre-alocating memory to Prolog shifted crashes to other places and > this way we discovered the real source of problems.
> However, coming back to basics... Bart posted the following program:
> a(N,_) :- N > 0, M is N - 1, a(M,foo(1,2,3,4,5)). > a(N,_) :- N =< 0.
> When executed on SICStus with sufficiently large N it takes 200 MB. > Questoon: is it possible to raclaim this memory and how? Or this is > memory leak?
> I am not asking how to modify this program in such a way that it will > NOT consume thsi much memory. Question is how to get this memory back.
You really don't know? All this memory is in choicepoints, so:
(1) Fix it using a `green' (O'Keefe terminology) cut. This is what you must do. (2) Fix it using a cut after the computation completes. This is a commonly seen solution, but it is bad style. Bugs must be fixes where they are, not somewhere else. Note that memory won't drop right away, but the next garbage collection will get rid of most. (3) Use the poor mens GC:
findall(G, G, List), member(G, List).
I must stress that such code needs to be fixed where the bug is. You can use SWI-Prolog's PlUnit to find determinism errors through your test suite. It also runs on SICStus (>=3.8, not tested on 4.x).
>On 2008-02-05, A.L <alewa...@fala2005.com> wrote: >> Ragerding my questions about memory leaks: one problem is solved - >> this was memory fragmentation, but caused not by Prolog, but by legacy >> module written in C and having very poor memory management. Prolog was >> crashing because it was not able to get memory.
>> Pre-alocating memory to Prolog shifted crashes to other places and >> this way we discovered the real source of problems.
>> However, coming back to basics... Bart posted the following program:
>> a(N,_) :- N > 0, M is N - 1, a(M,foo(1,2,3,4,5)). >> a(N,_) :- N =< 0.
>> When executed on SICStus with sufficiently large N it takes 200 MB. >> Questoon: is it possible to raclaim this memory and how? Or this is >> memory leak?
>> I am not asking how to modify this program in such a way that it will >> NOT consume thsi much memory. Question is how to get this memory back.
>You really don't know? All this memory is in choicepoints, so:
> (1) Fix it using a `green' (O'Keefe terminology) cut. This > is what you must do. > (2) Fix it using a cut after the computation completes. This > is a commonly seen solution, but it is bad style. Bugs must > be fixes where they are, not somewhere else. Note that memory > won't drop right away, but the next garbage collection will get > rid of most. > (3) Use the poor mens GC:
> findall(G, G, List), member(G, List).
>I must stress that such code needs to be fixed where the bug is. You >can use SWI-Prolog's PlUnit to find determinism errors through your >test suite. It also runs on SICStus (>=3.8, not tested on 4.x).
Yes, I DO know how to modify the program. But this was not my question.
I explicitly asked, quote myself: " I am not asking how to modify this program in such a way that it will NOT consume this much memory. Question is how to get this memory back."
Means, the question was: Will this memory be ever garbage collected? When choicepoint memory is considered "free" ("not referenced" in Java jargon)?
> On 05 Feb 2008 14:36:23 GMT, Jan Wielemaker <j...@nospam.ct.xs4all.nl> > wrote:
>>On 2008-02-05, A.L <alewa...@fala2005.com> wrote: >>> Ragerding my questions about memory leaks: one problem is solved - >>> this was memory fragmentation, but caused not by Prolog, but by legacy >>> module written in C and having very poor memory management. Prolog was >>> crashing because it was not able to get memory.
>>> Pre-alocating memory to Prolog shifted crashes to other places and >>> this way we discovered the real source of problems.
>>> However, coming back to basics... Bart posted the following program:
>>> a(N,_) :- N > 0, M is N - 1, a(M,foo(1,2,3,4,5)). >>> a(N,_) :- N =< 0.
>>> When executed on SICStus with sufficiently large N it takes 200 MB. >>> Questoon: is it possible to raclaim this memory and how? Or this is >>> memory leak?
>>> I am not asking how to modify this program in such a way that it will >>> NOT consume thsi much memory. Question is how to get this memory back.
>>You really don't know? All this memory is in choicepoints, so:
>> (1) Fix it using a `green' (O'Keefe terminology) cut. This >> is what you must do. >> (2) Fix it using a cut after the computation completes. This >> is a commonly seen solution, but it is bad style. Bugs must >> be fixes where they are, not somewhere else. Note that memory >> won't drop right away, but the next garbage collection will get >> rid of most. >> (3) Use the poor mens GC:
>> findall(G, G, List), member(G, List).
>>I must stress that such code needs to be fixed where the bug is. You >>can use SWI-Prolog's PlUnit to find determinism errors through your >>test suite. It also runs on SICStus (>=3.8, not tested on 4.x).
> Yes, I DO know how to modify the program. But this was not my > question.
> I explicitly asked, quote myself: " I am not asking how to modify this > program in such a way that it will NOT consume this much memory. > Question is how to get this memory back."
I read that :-) Thats why I gave the (2) and (3) options. They are bad style emergency measures, but they do the job.
> Means, the question was: Will this memory be ever garbage collected? > When choicepoint memory is considered "free" ("not referenced" in Java > jargon)?
Open choicepoints *are* referenced and cannot be gc'ed (well, you could write an intelligent garbage collector that will find the above problem, it it won't find others. Implementors taking the trouble to sort that out do so by enhancing clause indexing and then this problem runs fine immediately.
To get back at your loop, you have
loop(State) :- step(State, State2), loop(State2).
That is free of leaks iff step is deterministic. You can also write it as
On 05 Feb 2008 15:42:41 GMT, Jan Wielemaker <j...@nospam.ct.xs4all.nl> wrote:
>Open choicepoints *are* referenced and cannot be gc'ed (well, you could >write an intelligent garbage collector that will find the above problem, >it it won't find others. Implementors taking the trouble to sort that >out do so by enhancing clause indexing and then this problem runs fine >immediately.
On Tue, 05 Feb 2008 08:25:28 -0600, A.L wrote: > However, coming back to basics... Bart posted the following program:
> a(N,_) :- N > 0, M is N - 1, a(M,foo(1,2,3,4,5)). > a(N,_) :- N =< 0.
> When executed on SICStus with sufficiently large N it takes 200 MB. > Questoon: is it possible to raclaim this memory and how? Or this is > memory leak?
Jan has answered very appropriately, so I will attack these two questions from a different angle.
First of all, the two questions suggest that
if it is possible to reclaim this memory, it is not a memory leak
which by all reasonable definitions of "memory leak", this would be a wrong belief. Memory leaks are the result of a bug, because memory that is not needed, is kept alive. Of course, the question remains: whose bug is it. If it is a bug by the Prolog programmer, there is no other solution than to change the program, so
> I am not asking how to modify this program in such a way that it will > NOT consume thsi much memory. Question is how to get this memory back.
is unreasonable, since also "how to get this memory back" involves changing the program: there was a bug in the program, remember !
Of course the bug could be in the Prolog system, and then removing the bug from the Prolog system would be the ideal solution.
In the above program, it is almost trivial to adapt the compiler to avoid the memory leak, actually, you can do it yourself with term expansion. So, you might conclude: it was a bug in the Prolog system.
But have a look at a small variant of the above a/1 predicate:
b(N,_) :- cat(N), M is N - 1, b(M,foo(1,2,3,4,5)). b(N,_) :- dog(N).
where cat/1 and dog/1 are Prolog predicates, doing a lot of computation, and you (the programmer of b/2, cat/1 and dog/1) know that for all values of N, cat(N) and dog(N) are mutually exclusive (and always terminate and do not have side effects), but the compiler has no clue ... is it now YOUR bug that you didn't put a cut after cat(N), or is it a bug of the Prolog system that it couldn't detect all the properties that make it correct to have the cut inserted by the compiler ?
Take into account that the necessary conditions (for inserting the cut) are in general undecidable. From which it follows that any compiler is bound to detect only sufficient conditions. For instance, a compiler that does one level of inlining and by chance there are the definitions cat(N) :- N > 0. dog(N) :- N =< 0. will detect that a cut can be inserted. But in general, it won't.
Still, YOU can assist the compiler, and in two ways. The first one is obvious: you put the cut in your code, right after the cat(N) goal, or at the very least right after the top call to b/2.
The second one is more productive: with term expansion, you write general rules to transform the above b/2 clauses (and other predicate definitions) to a form with the cut whenever admissible. (for some systems, it might even be better to make it into an if-then-else)
The latter is exactly what hProlog does: the compiler has a small module source_optimize that does this kind of source2source transformations before the source code goes to the bytecode generator. The compiler doesn't even need to know about it. I can add stuff to it any day - I regularly do, because it is little effort for huge gains, but I am aware that it will never be complete.
AFAIK, such a module could easily be hooked into the SWI, SICStus, Yap ... compiler by their implementors. But since all these systems have term expansion (an evil heritage from DEC-10 Prolog :-) you can do it yourself.
BTW, DIY was kind of an Edinburgh clan adagio and it has proven to be quite contra productive (the other extreme is Java, where everything has been done for you), but term expansion is still the only thing you are left with.
B-Prolog is the one I know who gets close to this. Apologies to anyone I don't mention.
Our excuses:
- People add the cuts anyway, so why should we bother :) - In general, detecting whether tests are disjoint is a complex problem, even for built-ins. Better not to make any promises, than failing to recognize cases the user knows are deterministic, right? - Deep guards (user-code) are difficult, as Bart explained.
Still, we have known how to do better for quite a while, and we sure should be able to. So I think you're asking the right question.
>> However, coming back to basics... Bart posted the following program:
>> a(N,_) :- N > 0, M is N - 1, a(M,foo(1,2,3,4,5)). >> a(N,_) :- N =< 0.
>> When executed on SICStus with sufficiently large N it takes 200 MB. >> Questoon: is it possible to raclaim this memory and how? Or this is >> memory leak?
>Jan has answered very appropriately, so I will attack these two >questions from a different angle.
>First of all, the two questions suggest that
> if it is possible to reclaim this memory, it is not a memory leak
>which by all reasonable definitions of "memory leak", this would be a >wrong belief. Memory leaks are the result of a bug, because memory >that is not needed, is kept alive. Of course, the question remains: >whose bug is it. If it is a bug by the Prolog programmer, there is no >other solution than to change the program, so
For me, this is obviously a "bug" of Prolog system. Prolog doesn't know how to handle simple situation (well, some Prologs know)...
> On Tue, 05 Feb 2008 22:01:28 +0100, bart demoen <b...@cs.kuleuven.be> > wrote:
>>On Tue, 05 Feb 2008 08:25:28 -0600, A.L wrote:
>>> However, coming back to basics... Bart posted the following program:
>>> a(N,_) :- N > 0, M is N - 1, a(M,foo(1,2,3,4,5)). >>> a(N,_) :- N =< 0.
<snip>
>>which by all reasonable definitions of "memory leak", this would be a >>wrong belief. Memory leaks are the result of a bug, because memory >>that is not needed, is kept alive. Of course, the question remains: >>whose bug is it. If it is a bug by the Prolog programmer, there is no >>other solution than to change the program, so
> For me, this is obviously a "bug" of Prolog system. Prolog doesn't > know how to handle simple situation (well, some Prologs know)...
Its most definitely not a bug. Neither the ISO standard, nor the documentation of your Prolog system says this situation must be recognised.
I'm not at all sure it is desirable for Prolog implementations to deal with this automatically. At the moment the bottom-line of clause indexing is widely described and recognised. The more intelligent you make this, the less clear it will become what is and what is not recognised. We know we can't get this perfect.
One possible option is to allow for declarations, so you can state something like this.
>On 2008-02-06, A.L <alewa...@fala2005.com> wrote: >> On Tue, 05 Feb 2008 22:01:28 +0100, bart demoen <b...@cs.kuleuven.be> >> wrote:
>>>On Tue, 05 Feb 2008 08:25:28 -0600, A.L wrote:
>>>> However, coming back to basics... Bart posted the following program:
>>>> a(N,_) :- N > 0, M is N - 1, a(M,foo(1,2,3,4,5)). >>>> a(N,_) :- N =< 0.
><snip>
>>>which by all reasonable definitions of "memory leak", this would be a >>>wrong belief. Memory leaks are the result of a bug, because memory >>>that is not needed, is kept alive. Of course, the question remains: >>>whose bug is it. If it is a bug by the Prolog programmer, there is no >>>other solution than to change the program, so
>> For me, this is obviously a "bug" of Prolog system. Prolog doesn't >> know how to handle simple situation (well, some Prologs know)...
>Its most definitely not a bug. Neither the ISO standard, nor the >documentation of your Prolog system says this situation must be >recognised.
It IS a bug.
My Prolog documentation doesn't say that this is a problem. Actually, program with this "bug" behaves as expected. Problems are exlusively with the compiler inability to recognize the problem, and the GC inability to collect choicepoints. My manual says nothing about strategy of GC, what can be collected and what cannot be, and what are consequences of "bad" programming of otherwise correct program.
One again, for me it IS a bug, and it belongs to the category of "showstoppers". This is fine if we are writing student programs or "two-liners" but is not fine if I have 25K lines of Prolog and I have manualy detect situations as above. And probably many similar situations that we haven't discussed here.
> On 06 Feb 2008 14:46:13 GMT, Jan Wielemaker <j...@nospam.ct.xs4all.nl> > wrote:
>>On 2008-02-06, A.L <alewa...@fala2005.com> wrote: >>> On Tue, 05 Feb 2008 22:01:28 +0100, bart demoen <b...@cs.kuleuven.be> >>> wrote:
>>>>On Tue, 05 Feb 2008 08:25:28 -0600, A.L wrote:
>>>>> However, coming back to basics... Bart posted the following program:
>>>>> a(N,_) :- N > 0, M is N - 1, a(M,foo(1,2,3,4,5)). >>>>> a(N,_) :- N =< 0.
>><snip>
>>>>which by all reasonable definitions of "memory leak", this would be a >>>>wrong belief. Memory leaks are the result of a bug, because memory >>>>that is not needed, is kept alive. Of course, the question remains: >>>>whose bug is it. If it is a bug by the Prolog programmer, there is no >>>>other solution than to change the program, so
>>> For me, this is obviously a "bug" of Prolog system. Prolog doesn't >>> know how to handle simple situation (well, some Prologs know)...
>>Its most definitely not a bug. Neither the ISO standard, nor the >>documentation of your Prolog system says this situation must be >>recognised.
> It IS a bug.
> My Prolog documentation doesn't say that this is a problem. Actually,
Are you implying your Prolog documentation is supposed to point you at anything that can be a problem? Like the famous magnetron that is not supposed to be used for drying your pet? I think the system documentation should indeed indicate somewhere what the capabilities of clause indexing of the system is as this is system specific (though there is a more or less accepted baseline).
The fact that if clause indexing cannot make the choice deterministic requires you to add a `green' cut is discussed in the literature. Read The Craft of Prolog. Anyone who wants to do serious programming in Prolog should read this (writing your own compiler is an alternative taken by some Prolog programmers :-)
> One again, for me it IS a bug, and it belongs to the category of > "showstoppers". This is fine if we are writing student programs or > "two-liners" but is not fine if I have 25K lines of Prolog and I have > manualy detect situations as above. And probably many similar > situations that we haven't discussed here.
Then you need a better environment. I'd be surprised if Ciao's assertion language cannot find this for you. SWI-Prolog's unit test, toplevel, profiler and graphical debugger help discovering and finding these errors. Before I had those this type of error happened a lot to me, but these days they are extremely rare.
>>>>On Tue, 05 Feb 2008 08:25:28 -0600, A.L wrote:
>>>>>However, coming back to basics... Bart posted the following program:
>>>>>a(N,_) :- N > 0, M is N - 1, a(M,foo(1,2,3,4,5)). >>>>>a(N,_) :- N =< 0.
>><snip>
>>>>which by all reasonable definitions of "memory leak", this would be a >>>>wrong belief. Memory leaks are the result of a bug, because memory >>>>that is not needed, is kept alive. Of course, the question remains: >>>>whose bug is it. If it is a bug by the Prolog programmer, there is no >>>>other solution than to change the program, so
>>>For me, this is obviously a "bug" of Prolog system. Prolog doesn't >>>know how to handle simple situation (well, some Prologs know)...
>>Its most definitely not a bug. Neither the ISO standard, nor the >>documentation of your Prolog system says this situation must be >>recognised.
> It IS a bug.
> My Prolog documentation doesn't say that this is a problem. Actually, > program with this "bug" behaves as expected. Problems are exlusively > with the compiler inability to recognize the problem, and the GC > inability to collect choicepoints. My manual says nothing about > strategy of GC, what can be collected and what cannot be, and what are > consequences of "bad" programming of otherwise correct program.
Using a little common sense, I think that the manual is quite clear about NOT doing choicepoint collection. Books and tutorials are usually full of warnings for left behind useless choicepoints.
Let me shift to C - take the function
int f(int i) { if (i > 0) return(f(i-1)); else return(17);
}
and call f(123234234). The fact that it segmentation faults, is it because of a bug in the C-compiler ? Or in the operating system that hasn't documented that it does not gc the runtime stack ? Or should the programmer have known that this will go wrong (with gcc optimization lower than -O2) ?
> One again, for me it IS a bug, and it belongs to the category of > "showstoppers". This is fine if we are writing student programs or > "two-liners" but is not fine if I have 25K lines of Prolog and I have > manualy detect situations as above. And probably many similar > situations that we haven't discussed here.
Let's try to turn this into something more constructive (unusual for me, but I am getting older) ...
Where would you draw the line ? Can you specify what a system must recognize as deterministic (and put itself the appropriate cuts) in order not to be considered buggy by you ?
BTW, I think SWI teaches you to fish, while implementations that only recognize some determinism, just give you a fish. The best thing is of course to get some (even a lot of) fish for free, and also know how to fish, just in case.
On 06 Feb 2008 15:27:17 GMT, Jan Wielemaker <j...@nospam.ct.xs4all.nl> wrote:
>Are you implying your Prolog documentation is supposed to point you at >anything that can be a problem? Like the famous magnetron that is not >supposed to be used for drying your pet? I think the system >documentation should indeed indicate somewhere what the capabilities >of clause indexing of the system is as this is system specific (though >there is a more or less accepted baseline).
I would expect that Prolog manual and Prolog literature would point to all IMPORTANT and NON-TRIVIAL issues of internal compiler functioning and memory management that I cannot gather other way than to be enlighted by Supreme Spirit of by asking on this group.
Especialy, NOWHERE it is said (with notable exception of Craft of Prolog that ahs this on 5 pages and talks mostly about DEC-10) how GC works, what can be collected or not, and how programming style can impact this.
>The fact that if clause indexing cannot make the choice deterministic >requires you to add a `green' cut is discussed in the literature. >Read The Craft of Prolog. Anyone who wants to do serious programming >in Prolog should read this (writing your own compiler is an >alternative taken by some Prolog programmers :-)
Thanks for advice. I memorized "Craft of Prolog" many years ago, and your idea of "writing your own compiler to learn Prolog" is nothing more than one more proof of huge gap between the industry and the academia. And for me (sorry, I was a professor for 25 years, therefore I feel free to write about this profession whatever I want) this is something what I call "academic arrogance". No doubt that Prolog is not used (except me and maybe few other) for commercial development.
>> One again, for me it IS a bug, and it belongs to the category of >> "showstoppers". This is fine if we are writing student programs or >> "two-liners" but is not fine if I have 25K lines of Prolog and I have >> manualy detect situations as above. And probably many similar >> situations that we haven't discussed here.
>Then you need a better environment. I'd be surprised if Ciao's >assertion language cannot find this for you. SWI-Prolog's unit test, >toplevel, profiler and graphical debugger help discovering and finding >these errors. Before I had those this type of error happened a lot to >me, but these days they are extremely rare.
If SWI a) provides as good CLP(FD) as SICStus has, b) provides paid support as good as SICStus provides, c) provides commercial license, I definitely will consider switching.
On Wed, 06 Feb 2008 08:23:48 -0800, vscosta wrote: > On Feb 6, 1:41 pm, Bart Demoen <b...@cs.kuleuven.ac.be> wrote: >> vsco...@gmail.com wrote: >> >>>a(N,_) :- N > 0, M is N - 1, a(M,foo(1,2,3,4,5)). >> >>>a(N,_) :- N =< 0.
>> > Hi!
>> > I consider this a limitation (bug) in current Prolog compilers. Every >> > Prolog compiler should compile this code into something like this:
On Wed, 06 Feb 2008 10:18:04 -0600, A.L wrote: > On 06 Feb 2008 15:27:17 GMT, Jan Wielemaker <j...@nospam.ct.xs4all.nl> > wrote: >>The fact that if clause indexing cannot make the choice deterministic >>requires you to add a `green' cut is discussed in the literature. >>Read The Craft of Prolog. Anyone who wants to do serious programming >>in Prolog should read this (writing your own compiler is an >>alternative taken by some Prolog programmers :-)
> Thanks for advice. I memorized "Craft of Prolog" many years ago, and > your idea of "writing your own compiler to learn Prolog" is nothing > more than one more proof of huge gap between the industry and the > academia. And for me (sorry, I was a professor for 25 years, therefore > I feel free to write about this profession whatever I want) this is > something what I call "academic arrogance".
Please A.L., apologize to Jan for not having noticed the :-) at the end of his "advice", and for having jumped to hasty conclusions about his arrogance.
The only arrogance (maybe hubris is the better word) Jan has shown in the past decade, was to offer almost singlehandedly the most complete and usefull Prolog system for free to the world, and to continue doing that, despite being accused from time to time to be arrogant.
And let's get back to the basics of this discussion, which is after all, quite relevant: it involves a developer and an knowledgable user - if not an SWI user, at least a Prolog user.
>int f(int i) >{ > if (i > 0) return(f(i-1)); > else return(17); >}
>and call f(123234234). The fact that it segmentation faults, is it because >of a bug in the C-compiler ? Or in the operating system that hasn't documented >that it does not gc the runtime stack ? Or should the programmer have known >that this will go wrong (with gcc optimization lower than -O2) ?
And what when there is NO segmentattion faults, i.s. the above function completes successfully?...
I was not complaining that your 2 liner gives segmentation fault...
>Where would you draw the line ? Can you specify what a system must recognize >as deterministic (and put itself the appropriate cuts) in order not to be >considered buggy by you ?
I don't know. In conventinal languages you have C from one side, where you can write whatever you want and compiler swallows everything, and Ada from other side when it is really hard to oursmart the compiler. I would prefer to have Prolog closer to Ada than to C...
>BTW, I think SWI teaches you to fish, while implementations that only recognize >some determinism, just give you a fish. The best thing is of course to get >some (even a lot of) fish for free, and also know how to fish, just in case.
I appreciate this, my only compian is that I cannot find this in Prolog textbooks. EXPLICITLY stated.
>> On 06 Feb 2008 15:27:17 GMT, Jan Wielemaker <j...@nospam.ct.xs4all.nl> >> wrote: >>>The fact that if clause indexing cannot make the choice deterministic >>>requires you to add a `green' cut is discussed in the literature. >>>Read The Craft of Prolog. Anyone who wants to do serious programming >>>in Prolog should read this (writing your own compiler is an >>>alternative taken by some Prolog programmers :-)
>> Thanks for advice. I memorized "Craft of Prolog" many years ago, and >> your idea of "writing your own compiler to learn Prolog" is nothing >> more than one more proof of huge gap between the industry and the >> academia. And for me (sorry, I was a professor for 25 years, therefore >> I feel free to write about this profession whatever I want) this is >> something what I call "academic arrogance".
>Please A.L., apologize to Jan for not having noticed the :-) at the end of >his "advice", and for having jumped to hasty conclusions about his >arrogance.
I do. I didn't notice.
However, trying to explain my attitude: I am bombarded by telephone calls from field guys that Prolog server is crashing in production environment, what can have rather bad consequences it I don't solve the problem QUICKLY. First case was resolved: Prolog was not guilty. Second case: Prolog is guilty.
There is evidently fire under my ass :)
Anyway, once again - apologize for temper and bad manners...
>And let's get back to the basics of this discussion, which is after all, >quite relevant: it involves a developer and an knowledgable user - if not >an SWI user, at least a Prolog user.
vsco...@gmail.com wrote: > On Feb 5, 9:01 pm, bart demoen <b...@cs.kuleuven.be> wrote: >> On Tue, 05 Feb 2008 08:25:28 -0600, A.L wrote: >>> However, coming back to basics... Bart posted the following program: >>> a(N,_) :- N > 0, M is N - 1, a(M,foo(1,2,3,4,5)). >>> a(N,_) :- N =< 0.
> Hi!
> I consider this a limitation (bug) in current Prolog compilers. Every > Prolog compiler should compile this code into something like this:
>>alternative taken by some Prolog programmers :-)
> something what I call "academic arrogance". No doubt that Prolog is
Thanks for the apologies (other reply). They weren't needed as far as I'm concerned. Though the baseline of my posts is intended constructive I do take the liberty to tease a bit.
>>> One again, for me it IS a bug, and it belongs to the category of >>> "showstoppers". This is fine if we are writing student programs or >>> "two-liners" but is not fine if I have 25K lines of Prolog and I have >>> manualy detect situations as above. And probably many similar >>> situations that we haven't discussed here.
>>Then you need a better environment. I'd be surprised if Ciao's >>assertion language cannot find this for you. SWI-Prolog's unit test, >>toplevel, profiler and graphical debugger help discovering and finding >>these errors. Before I had those this type of error happened a lot to >>me, but these days they are extremely rare.
> If SWI a) provides as good CLP(FD) as SICStus has, b) provides paid > support as good as SICStus provides, c) provides commercial license, > I definitely will consider switching.
clp(fd) is getting pretty good, thanks to all the work by Markus Triska and Ulrich Neumerkel for the testing. I think the aim is to make it really good, but it is not likely to become fast. Of course, sometimes it outsmarts other implementations and than it is really fast, but the baseline is definitely (much) slower. It is funny that you raise these issues while I think it is far easier to master efficient Prolog than to find out what you have to do for an efficient clp(fd) program.
As far as (b) is concerned, you can get paid support. Generally the unpaid support appears to do the job quite well though. The license allows for embedding in proprietary code. It doesn't give any warrantees though.
On the other hand, I think SICStus is a very good commercial Prolog implementation. There are benefits in both systems and unfortunately, except for trivial programs, it is not easy to switch. It can be done, and I know people who moved big programs either way.
> On Wed, 06 Feb 2008 17:18:27 +0100, Bart Demoen > <b...@cs.kuleuven.ac.be> wrote:
>> Let me shift to C - take the function
>> int f(int i) >> { >> if (i > 0) return(f(i-1)); >> else return(17); >> }
>> and call f(123234234). The fact that it segmentation faults, is it because >> of a bug in the C-compiler ? Or in the operating system that hasn't documented >> that it does not gc the runtime stack ? Or should the programmer have known >> that this will go wrong (with gcc optimization lower than -O2) ?
> And what when there is NO segmentattion faults, i.s. the above > function completes successfully?...
> I was not complaining that your 2 liner gives segmentation fault...
>> Where would you draw the line ? Can you specify what a system must recognize >> as deterministic (and put itself the appropriate cuts) in order not to be >> considered buggy by you ?
> I don't know. In conventinal languages you have C from one side, where > you can write whatever you want and compiler swallows everything, and > Ada from other side when it is really hard to oursmart the compiler. I > would prefer to have Prolog closer to Ada than to C...
I don't see how in the Earth an Ada compilerą could avoid a stack overflow like the above snippet. . .
Regards,
-- Cesar Rabak
[1] and yes, I do know Ada and have see stack overflows in it!
