As far as I know, Amzi! Prolog provides a logic server that can be used combined with Delphi, C++, Visual Basic etc.
Recently I have found the pdf manual of SICSTUS Prolog. I have read somethings which may be interpreted in this manner, too. Is this right? Do you know anything about SICSTUS?
Are there other Prolog implementations that can be combined with other tools (VisualBasic or perhaps RealBasic) for a polished user interface.
> As far as I know, Amzi! Prolog provides a logic server that can be > used combined with Delphi, C++, Visual Basic etc.
> Recently I have found the pdf manual of SICSTUS Prolog. I have read > somethings which may be interpreted in this manner, too. Is this > right? Do you know anything about SICSTUS?
> Are there other Prolog implementations that can be combined with other > tools (VisualBasic or perhaps RealBasic) for a polished user interface.
Here are some details for SWI-Prolog:
If you want to use a BASIC for your user interface, you don't need to. SWI-Prolog is able to construct GUIs natively, using the XPCE package.
If, on the other hand, you're asking the more general question of whether you can use external libraries such as wxWidgets, SWI-Prolog has a foreign function interface to C and C++. -- Darren Bane
>> As far as I know, Amzi! Prolog provides a logic server that can be >> used combined with Delphi, C++, Visual Basic etc.
>> Recently I have found the pdf manual of SICSTUS Prolog. I have read >> somethings which may be interpreted in this manner, too. Is this >> right? Do you know anything about SICSTUS?
>> Are there other Prolog implementations that can be combined with other >> tools (VisualBasic or perhaps RealBasic) for a polished user interface.
> Here are some details for SWI-Prolog:
> If you want to use a BASIC for your user interface, you don't need to. > SWI-Prolog is able to construct GUIs natively, using the XPCE package.
> If, on the other hand, you're asking the more general question of > whether you can use external libraries such as wxWidgets, SWI-Prolog > has a foreign function interface to C and C++.
SWI-Prolog has a well developed, tested, maintained and widely used interface to C. The C++ interface is a more high-level, but less complete. Of course you can freely use the C-interface from C++ and also mix them. Then there is the Java interface (JPL) that comes bundled. JPL suffers from some portability issues (notably on Unix and MacOSX), though it works ok for quite a few people after they manage to get it running properly. Then there are many interfaces with various degrees of functionality on the web. You milage may vary ...
In many cases if you want to do GUI and do not want to use XPCE, I'd consider writing your application as a web-server and use a browser (possibly using AJAX widgets). If that doesn't suit you consider writing the application in whatever language you wish and use interprocess communication. There are many choices. You can connect Prolog to a pipe, make it a network server, etc.
On 26 Feb 2007 06:33:36 -0800, "Kobayashi" <kubilayi...@gmail.com> wrote:
>Hi,
>As far as I know, Amzi! Prolog provides a logic server that can be >used combined with Delphi, C++, Visual Basic etc.
>Recently I have found the pdf manual of SICSTUS Prolog. I have read >somethings which may be interpreted in this manner, too. Is this >right? Do you know anything about SICSTUS?
Yes, SICStus has several interfaces, including VisualBasic interface. This interface is collection of about 10 functions and is distributed as DLL. There is VB module encapsulating this interface distributed wit SICStus plus some examples. I have used this interface to call SICStus from C#. However, this interface is single directional, i.e. VB to SICStus.
In addition to the above, SICStus has interface named Prolog Beans that supports Java and C#, interface named Jasper for Java, and of course, interface for C and C++
Hmm... I have searched the comp.lang.prolog and comp.lang.lisp and have found that there have been many attempts to implement a Prolog interpreter in Lisp. Why are people so eager for that? What's the point? To show the power of Lisp? Or is there a particular advantage of such an interpreter? And is there a Lisp interpreter (or compiler! ;^D) implemented in Prolog?
"Kobayashi" <kubilayi...@gmail.com> wrote: > Hmm... I have searched the comp.lang.prolog and comp.lang.lisp and > have found that there have been many attempts to implement a Prolog > interpreter in Lisp.
Attempts, yes. Mostly these toy "Prolog" implementations can't even parse a single proper Prolog term though.
> And is there a Lisp interpreter (or compiler! ;^D) implemented in > Prolog?
The code follows. As you see, it indeed contains a compiler, and it's straight-forward to change its output to a more low-level form, like byte-code or integer-code, for use in a stack-based virtual machine.
/* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Interpretation -------------- Declaratively, execution of a Lisp form establishes a relation between the (function and variable) binding environment before its execution and the environment after its execution. A Lisp program is a sequence of Lisp forms, and its result is the sequence of their results. Initially, the environment is empty. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */
run(Program, Values) :- parse(Program, Forms0), empty_assoc(E), compile_all(Forms0, Forms), eval_all(Forms, E, _, E, _, Values).
fold([], _, V, V). fold([F|Fs], Op, V0, V) :- E =.. [Op,V0,F], V1 is E, fold(Fs, Op, V1, V).
Great, Markus. You never lose a point! Every time a strike! Every time clear, instructive and (consequently?) efficent code. I'm going to try this LISP, i hope i still remember how to reverse a list using it...
> > Hmm... I have searched the comp.lang.prolog and comp.lang.lisp and > > have found that there have been many attempts to implement a Prolog > > interpreter in Lisp.
> Attempts, yes. Mostly these toy "Prolog" implementations can't even > parse a single proper Prolog term though.
> > And is there a Lisp interpreter (or compiler! ;^D) implemented in > > Prolog?
> The code follows. As you see, it indeed contains a compiler, and it's > straight-forward to change its output to a more low-level form, like > byte-code or integer-code, for use in a stack-based virtual machine.
> Interpretation > -------------- > Declaratively, execution of a Lisp form establishes a relation > between the (function and variable) binding environment before its > execution and the environment after its execution. A Lisp program > is a sequence of Lisp forms, and its result is the sequence of > their results. Initially, the environment is empty. > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */
> run(Program, Values) :- > parse(Program, Forms0), > empty_assoc(E), > compile_all(Forms0, Forms), > eval_all(Forms, E, _, E, _, Values).
> fold([], _, V, V). > fold([F|Fs], Op, V0, V) :- E =.. [Op,V0,F], V1 is E, fold(Fs, Op, V1, V).
>Hmm... I have searched the comp.lang.prolog and comp.lang.lisp and >have found that there have been many attempts to implement a Prolog >interpreter in Lisp. Why are people so eager for that? What's the >point? To show the power of Lisp?
Yes. People on comp.lang.lisp claim that other languages are not needed since you can do everything in Lisp, and better than in otre languages. Try to go there and question this claim. See what will happen.
Kobayashi wrote: > Hmm... I have searched the comp.lang.prolog and comp.lang.lisp and > have found that there have been many attempts to implement a Prolog > interpreter in Lisp.
Why this focus on "interpreter"? Most industrial strength Prologs compile Prolog functors either to byte code, or directly to machine code. This is the case for Allegro Prolog -- functors are compiled directly to optimized and generally-non-consing machine code. One of the things a non-toy implementation needs is speed.
> Why are people so eager for that? What's the > point? To show the power of Lisp?
Certainly not. It is hardly necessary to expound in this newsgroup the value of Prolog for certain classes of problems. It might be more contentious to argue that many other classes of problem are awkward to express in Prolog, so I won't.
> Or is there a particular advantage of such an interpreter?
Having both backtracking and procedural paradigms (not to mention CLOS) readily available in the same code increases the options available to the programmer.