exnirad@brolga.cc.uq.oz.au (Nirad Sharma) (05/27/91)
Is it possible to write Prolog progams and have them integrated into a c program ? I seem to remember that Turbo Prolog on the PC platform allows this. I am looking for a Unix (SYSV) solution which would allow prolog units to be written and either compiled and linked to the c code or be interpreted at run-time. Some extensive logic needs to be built into some algorithms that I am using for a database application. While I have already coded some of this logic in c I would prefer to convert the existing and the future code to prolog for ease of programming and verification. BTW, if anyone can suggest a similar system with, say, Lisp I'd be glad to know. Thanks for any help / pointers. -- Nirad Sharma (exnirad@brolga.cc.uq.oz.au) Phone : (+61 7) 365 7575 Systems Programmer Fax : (+61 7) 870 5080 Continuing Education Unit The University of Queensland. QLD 4072
fore057@csc.canterbury.ac.nz (05/27/91)
In article <1991May26.231138.13000@brolga.cc.uq.oz.au>, exnirad@brolga.cc.uq.oz.au (Nirad Sharma) writes: > Is it possible to write Prolog progams and have them integrated into a c > program ? I seem to remember that Turbo Prolog on the PC platform allows > this. I am looking for a Unix (SYSV) solution which would allow prolog > units to be written and either compiled and linked to the c code or be > interpreted at run-time. Some extensive logic needs to be built into some > algorithms that I am using for a database application. While I have already > coded some of this logic in c I would prefer to convert the existing and > the future code to prolog for ease of programming and verification. Turbo Prolog is now marketed by the original developers, and is called PDC Prolog. There is a UNIX version. I suggest you ask if it will do what you want. The address is: Prolog Development Center ApS. H.J. Holst Vej 5A DK-2605 Broendby Copenhagen, Denmark They used to have a USENET address, but my Email hasn't been reaching them recently.
own@castle.ed.ac.uk (O Morgan) (05/27/91)
>In article <1991May26.231138.13000@brolga.cc.uq.oz.au>, exnirad@brolga.cc.uq.oz.au (Nirad Sharma) writes: >> Is it possible to write Prolog progams and have them integrated into a c >> program ? I seem to remember that Turbo Prolog on the PC platform allows >> this. I am looking for a Unix (SYSV) solution which would allow prolog >> units to be written and either compiled and linked to the c code or be >> interpreted at run-time. Some extensive logic needs to be built into some >> algorithms that I am using for a database application. While I have already >> coded some of this logic in c I would prefer to convert the existing and >> the future code to prolog for ease of programming and verification. On a PC, it is certainly possible to call Arity Prolog predicates from Microsoft C. The prolog does not neccessarily all need to be compiled, some of it can be consulted in at run time. You can also call the Prolog from other MS language implementations such as Fortran if you get them to call C first. Another (PC) option would be to run your C program under Windows3 and get it to operate a Windows based Prolog that supports DDE. Prolog-2 for Windows can do this. Olly Morgan -- ---------------------------------------------------------------------------- Olly Morgan @ Scottish Agricultural College, Edinburgh EH9 2HH, Scotland Tel: (+44 31) 662 4395 E.Mail: O.Morgan@ed.ac.uk ----------------------------------------------------------------------------
ted@nmsu.edu (Ted Dunning) (05/27/91)
In article <1991May26.231138.13000@brolga.cc.uq.oz.au> exnirad@brolga.cc.uq.oz.au (Nirad Sharma) writes:
Is it possible to write Prolog progams and have them integrated into a c
program ?
yes, but ... see below.
BTW, if anyone can suggest a similar system with, say, Lisp I'd be glad to
know.
also... same comments
it is generally _MUCH_ easier (as in the supplier supports it) to
embed c code into a running prolog program. there are number of
reasons for this, chief of which is that the memory models of most
prolog interpreters/runtimes is pretty involved and most programmers
simply can't be trusted to set it all up correctly.
on significant exception to this generalization is quintus prolog
which allows the user bidirectional embedding, c in a prolog program,
or prolog in a c program. the first is still much easier to make
work.
most commercial lisp implementations allow the former style of
embedding of c code. if you have source, then you might be reasonably
able to embed the other way. many publically available scheme (elk,
and scm a prominent examples) interpreters allow full
intercallability.
you should consider the fact that embedding will almost always
seriously compromise debugging of the embedded code. this is
especially true of embedding c in a more advanced language.
there are two reasonable outs for this, one is to start the higher
level language from inside a c debugger (this assumes that you have
unstripped executables or .o files) and then after loading your c-code
into prolog (lisp) you break back to the debugger and set up
breakpoints and such.
the other reasonable solution is to implement some form of remote
procedure call which would allow you to debug your prolog program and
your c program with their native debuggers. an automatic generator of
stubs and argument marshalling code is very helpful with this
approach.
--
Offer void except where prohibited by law.campbell@dataco.UUCP (Duncan Campbell) (05/28/91)
PDC Prolog, the successor to Turbo Prolog, runs on SCO System V 3.2 (and several other platforms) and allows for embedded prolog functions in C. Duncan Campbell ***--------------------------------------------------------------*** * DISCLAIMER: * * ==========: * * The opinions expressed are solely of the author and do not * * necessarily reflect the opinions of Canadian Marconi Company. * ***--------------------------------------------------------------***
ted@nmsu.edu (Ted Dunning) (05/30/91)
In article <644@fudd.dataco.UUCP> campbell@dataco.UUCP (Duncan Campbell) writes:
PDC Prolog, the successor to Turbo Prolog, runs on SCO System V 3.2
(and several other platforms) and allows for embedded prolog functions
in C.
when referencing turbo `prolog' (by any name), quotes should be put
around the word prolog to indicate that you know that it isn't really
prolog.
turbo `prolog' does allow for embedding, it just doesn't allow one to
embed calls to prolog in c.
--
Offer void except where prohibited by law.dave@quintus.UUCP (David Bowen) (05/30/91)
(I hope Andre Marien won't mind if I comment.) In article <TED.91May27100027@ithaka.nmsu.edu> ted@nmsu.edu (Ted Dunning) writes: >you should consider the fact that embedding will almost always >seriously compromise debugging of the embedded code. this is >especially true of embedding c in a more advanced language. This is not an intrinsic limitation of Prolog or Lisp. Since release 2.5 Quintus Prolog has provided the ability to link your C code (and your Prolog code) with the Prolog system to get a standard executable file. You can then run standard debuggers like dbx to debug your C code, while simultaneously running the Prolog debugger. >there are two reasonable outs for this, one is to start the higher >level language from inside a c debugger (this assumes that you have >unstripped executables or .o files) and then after loading your c-code >into prolog (lisp) you break back to the debugger and set up >breakpoints and such. The problem with trying to debug C code that you have loaded into a running Prolog/Lisp system is that somehow you have to get the C debugger to understand where all the symbols are. In general C debuggers don't have the flexibility to do this.
garym@cognos.uucp@uunet.uu.net (Gary Murphy) (05/30/91)
>>>>> On 29 May 91 19:19:22 GMT, ted@nmsu.edu (Ted Dunning) said:
Ted> when referencing turbo `prolog' (by any name), quotes should be put
Ted> around the word prolog to indicate that you know that it isn't really
Ted> prolog.
Oh, let's not start THIS again. One could argue that NONE of the current
implementations are 'prolog', but the truth is that PDC is more a prolog
than anything else and is as much a prolog as TurboPascal is a pascal.
Small C is missing all kinds of semantic and syntactic junk. Is it not C?
XLisp is likewise short of Common Lisp's expressive power (what Lisp isn't)
yet no one, to my knowledge at least, has ever requested a quining of the
name. Watbol is not Snobol, Watfiv was not Fortran, nothing was ever PL/1.
Ted> turbo `prolog' does allow for embedding, it just doesn't allow one to
Ted> embed calls to prolog in c.
Since when? I must have been dreaming when I did it, and my clients from
those projects must still be dreaming as none have called to complain. PDC
provides excellent support for C, assember or Pascal. The only restriction
on calling predicates from C is the required initialization of the Prolog
stacks during your program's early 'main' code.
PDC does have its problems, not the least of which are the inflated price
(especially for upgrades) and the forced use of the 80x87 emulator, but
we shouldn't blast it with false accusations.
Ted> --
Ted> Offer void except where prohibited by law.
--
Gary Murphy - Cognos Incorporated | "You think you're human.
P.O.Box 9707 Ottawa K1G 3N3 | But what if you've made a mistake,
(613) 738-1338 x5537 | As humans sometimes do,
garym%cognos.uucp@ccs.carleton.ca | And you is an Angel, instead?"
uucp: cognos!garym | -- Sun Racampbell@dataco.UUCP (Duncan Campbell) (05/31/91)
Ted Dunning writes:
"
when referencing turbo `prolog' (by any name), quotes should be put
around the word prolog to indicate that you know that it isn't really
prolog.
turbo `prolog' does allow for embedding, it just doesn't allow one to
embed calls to prolog in c.
-
"
Well, Ted, out here in the real world _REAL_ Prolog isn't much use to
anyone. Indeed, if I were required to use a "pure" language, I simply
would not bother with prolog at all: Scheme _IS_ a far superior language.
By the way, is there some sort of "Academie Francais" of CS lingo out
there? Mebbe someone in a university should set one up so as we can
all ignore it. The fact remains that PDCProlog provides much of the
functionality of "pure" Prolog and possesess the features like
timers, static typing and execution speed (*10 faster than "pure"
prolog) needed for real-time applications.
Duncan
***--------------------------------------------------------------***
* DISCLAIMER: *
* ==========: *
* The opinions expressed are solely of the author and do not *
* necessarily reflect the opinions of Canadian Marconi Company. *
***--------------------------------------------------------------***mcovingt@athena.cs.uga.edu (Michael A. Covington) (05/31/91)
In article <653@fudd.dataco.UUCP> campbell@calvin.UUCP (Duncan Campbell, VOR) writes: > >Well, Ted, out here in the real world _REAL_ Prolog isn't much use to >anyone. Indeed, if I were required to use a "pure" language, I simply >would not bother with prolog at all: Scheme _IS_ a far superior language. And assembler is "better" than C. Scheme is a fine language, but it's a lower-level language than Prolog. >By the way, is there some sort of "Academie Francais" of CS lingo out >there? ISO and ANSI working groups who are developing a Prolog standard. >The fact remains that PDCProlog provides much of the >functionality of "pure" Prolog and possesess the features like >timers, static typing and execution speed (*10 faster than "pure" >prolog) needed for real-time applications. Which "pure" Prolog are you comparing it to? Interpreted or compiled? ALS Prolog is awfully fast! -- ------------------------------------------------------- Michael A. Covington | Artificial Intelligence Programs The University of Georgia | Athens, GA 30602 U.S.A. -------------------------------------------------------
ted@nmsu.edu (Ted Dunning) (06/01/91)
In article <GARYM.91May30115448@cognos.uucp@uunet.uu.net> garym@cognos.uucp@uunet.uu.net (Gary Murphy) writes:
Oh, let's not start THIS again. One could argue that NONE of the
current implementations are 'prolog', but the truth is that PDC is
more a prolog than anything else and is as much a prolog as
TurboPascal is a pascal.
hmm.... why is it you can't write predicates that accept goals as
arguments?
Ted> turbo `prolog' does allow for embedding, it just doesn't allow
Ted> one to embed calls to prolog in c.
Since when? I must have been dreaming when I did it, and my
clients from those projects must still be dreaming as none have
called to complain.
you embedded calls to turbo prolog, not to prolog.
The only restriction on calling predicates from C is
the required initialization of the Prolog stacks during your
program's early 'main' code.
you omit one other restriction. the predicates you call are limited
to an extreme subset of prolog.
but we shouldn't blast it with false accusations.
which accusations were false?ted@nmsu.edu (Ted Dunning) (06/01/91)
In article <653@fudd.dataco.UUCP> campbell@dataco.UUCP (Duncan Campbell) writes:
Well, Ted, out here in the real world _REAL_ Prolog isn't much use
to anyone.
indeed. i would have gathered otherwise from the literature that
vendors send me about all the real applications that their customers
have written. i would have gathered otherwise from the real
applications that i currently support.
Indeed, if I were required to use a "pure" language, I simply
would not bother with prolog at all: Scheme _IS_ a far superior
language.
of course, scheme isn't a pure language. at least not in the
customary sense of not allowing assignments.
The fact remains that PDCProlog provides much of the functionality
of "pure" Prolog and possesess the features like timers, static
typing and execution speed (*10 faster than "pure" prolog) needed
for real-time applications.
timers? no problem to add to any of the prologs i use (quintus,
sicstus). in fact, i did it just last month.
static typing? do you required required static typing that won't
allow you to declare all the legal values in the language?
well, then you really do want to have turbo instead of the
real thing. if, on the other hand, you want inferred typing,
or compile time type checking then you should check out peter
van roy's latest compiler or the mycroft and o'keefe type
checker.
execution speed? where do you get these numbers? last i checked
(which was some time ago) als prolog ran on pc's and macs and
produced code which ran just about even with turbo prolog.
peter van roy's compiler produces code which runs even with
compiled and optimized c code.
i would have to admit that there is _some_ prolog that runs
at least 10* slower than turbo prolog. in fact, i could
write you one.
ok... since turbo prolog is prolog, let's see somebody write the
following predicates:
1) a standard findall.
2) a variation on the standard dcg expansion which allows me to write in
a functional style and which translates all calls to :=/2 so that the
left hand side is unified with the functional result of the right hand
side. this should integrate into the normal compilation process so
that you don't have to worry about preprocessing your files.
3) a weakening of the above where instead of adding to the standard
clause expansion, you just write a wrapper around predicate that
compiles files. it should cause the files to be preprocessed, then
compiled and loaded.
4) a rewrite of the following predicate:
forall(G, P) :- \+ (G, \+ P).
that does not include an entire interpreter for prolog.
5) a simple program that takes as an argument a goal written in a
syntactic variation of prolog, and then executes it.
================================================================
as a preview of the problems you are likely to have with turbo prolog,
1) woops... you can't declare a type for a general term. nor can you
call a variable.
2) oh, golly, term expansion is built in and can't be changed.
3) darn, i have to write a new version of read which will read
standard terms and give me decorated terms. then the translator
isn't too hard. except that it can't dynamically check to determine
which predicates are defined.
4) darn, no passing goals as arguments
5) woops... can't declare the type for the argument, nor can i call
the result even if i did manage to translate it. oh well, i can
always write a prolog interpreter to make this look like it works.mcovingt@athena.cs.uga.edu (Michael A. Covington) (06/01/91)
In article <GARYM.91May30115448@cognos.uucp@uunet.uu.net> garym@cognos.uucp@uunet.uu.net (Gary Murphy) writes: > >Oh, let's not start THIS again. One could argue that NONE of the current >implementations are 'prolog', but the truth is that PDC is more a prolog >than anything else and is as much a prolog as TurboPascal is a pascal. > Falsch. Turbo Pascal _is_ Pascal; virtually all ISO Pascal programs run unchanged. Turbo Prolog is _not_ Prolog; there is NO, I repeat _no_ Edinburgh Prolog program that will run unchanged in Turbo Prolog. The real problem with Turbo Prolog is not what it leaves out, but with what it adds. All kinds of obligatory type declarations, and restrictions on the use of data types, are added. This is why no Edinburgh Prolog program will run unchanged, and most of them cannot even be converted without a total redesign of the data structures. I'm not saying Turbo Prolog isn't a good language. But it isn't Prolog. It's another Prolog-like language, just as Pascal is another Algol-like language. -- ------------------------------------------------------- Michael A. Covington | Artificial Intelligence Programs The University of Georgia | Athens, GA 30602 U.S.A. -------------------------------------------------------
campbell@dataco.UUCP (Duncan Campbell) (06/05/91)
Ted Dunning writes:
"
[all sorts of bad stuff about PDC Prolog]
a bunch of things he wants to do in prolog, but can't in PDC Prolog, thus:
1) a standard findall.
...
2) a variation on the standard dcg expansion which allows me to write in
...
3) a weakening of the above where instead of adding to the standard
...
4) a rewrite of the following predicate:
...
forall(G, P) :- \+ (G, \+ P).
...
that does not include an entire interpreter for prolog.
...
5) a simple program that takes as an argument a goal written in a
...
1) woops... you can't declare a type for a general term. nor can you
call a variable.
...
2) oh, golly, term expansion is built in and can't be changed.
...
3) darn, i have to write a new version of read which will read
...
4) darn, no passing goals as arguments
...
5) woops... can't declare the type for the argument, nor can i call
...
"
And I have to reply that I really don't care what Ted cannot do
in PDC Prolog. Besides, as long as a language is Turing equivalent,
you _CAN_ do anything in one that you can in another: same ends,
different means. Loosen up, eh?
Duncan
***--------------------------------------------------------------***
* DISCLAIMER: *
* ==========: *
* The opinions expressed are solely of the author and do not *
* necessarily reflect the opinions of Canadian Marconi Company. *
***--------------------------------------------------------------***ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (06/10/91)
In article <653@fudd.dataco.UUCP>, campbell@dataco.UUCP (Duncan Campbell) writes: > Well, Ted, out here in the real world _REAL_ Prolog isn't much use to > anyone. Indeed, if I were required to use a "pure" language, I simply > would not bother with prolog at all: Scheme _IS_ a far superior language. I'm currently using Scheme a lot. I have three observations to make about Scheme. (1) I like it. (2) One day it will catch up with where Pop-2 was years ago, but don't hold your breath. (Scheme has precisely two things that Pop-2 didn't: lexical scoping and full continuations. These days Pop has lexical scoping.) (3) Unless the Prolog standard has a radically different result from the Scheme standard, the whole standardisation effort will have been a waste of time. I have access to 5 Scheme implementations (later this year to be 6), and there is no non-trivial program that I can move from one to another without either rewriting or an extensive library of compatibility code (currently standing at >2000 lines and growing fast). > The fact remains that PDCProlog provides much of the > functionality of "pure" Prolog and possesess the features like > timers, static typing and execution speed (*10 faster than "pure" > prolog) needed for real-time applications. Static typing has been available as an option for Edinburgh-compatible since 1983 or 1984. If people didn't pick it up, that's not my fault. (NU Prolog comes with _four_ type checkers...) And it seems rather odd for someone claiming static type checking as an important advantage to advocate Scheme. I do not have access to a PDC Prolog, but Borland's last offering of it did not provide any execution time advantage. Perhaps you have some interpreter in mind. If you want a logic-based language, and don't mind total incompatibility with Prolog, then you might like to try Trilogy, which is about as fast as Turbo Prolog was, and has a GREATLY superior type system, and isn't really any less compatible with Prolog than Turbo Prolog was. -- Should you ever intend to dull the wits of a young man and to incapacitate his brains for any kind of thought whatever, then you cannot do better than give him Hegel to read. -- Schopenhauer.
aarons@syma.sussex.ac.uk (Aaron Sloman) (06/11/91)
ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes: > In article <653@fudd.dataco.UUCP>, campbell@dataco.UUCP (Duncan Campbell) writes: > > Well, Ted, out here in the real world _REAL_ Prolog isn't much use to > > anyone. Indeed, if I were required to use a "pure" language, I simply > > would not bother with prolog at all: Scheme _IS_ a far superior language. > > I'm currently using Scheme a lot. I have three observations to make > about Scheme. > (1) I like it. > (2) One day it will catch up with where Pop-2 was years ago, but > don't hold your breath. (Scheme has precisely two things that > Pop-2 didn't: lexical scoping and full continuations. These > days Pop has lexical scoping.) > .... Just for the record: Poplog Pop-11 also has processes, which give much of the power of continuations. In particular the procedure consproc_to can be used to save the state of computation up to some point in the current control stack. The saved state is stored in a data-structure that can be re-activated at any time thereafter. More precisely, here's the definition in the Poplog REF files. consproc_to(ITEM_1, ..., ITEM_N, N, TARGET_P) -> PROC consproc_to(ITEM_1, ..., ITEM_N, N, TARGET_P, VOLATILE) -> PROC Makes the current calling sequence upto and including the the most recent call of the procedure TARGET_P into a process, returning the process record PROC for the new (running) process. This procedure effectively 'inserts' a call of -runproc- immediately above the call of TARGET_P, does a -suspend-, and then immediately runs the process again with PROC passed as argument. The implicit -suspend- automatically subsumes any processes running below the call of TARGET_P; these will be reactivated when PROC is run again. The user stack of PROC is then set to contain N items passed from the current stack (i.e. the stack as it is AFTER suspending intervening processes). To allow computation (in that environment) of the number of items to be passed, the argument N may also be a procedure which returns the number, i.e. N() is evaluated after suspending intervening processes. VOLATILE is an optional boolean argument specifying whether the process is volatile or not (see below). If not specified the default is true, i.e. volatile. Note that a process can be 'volatile' or 'non-volatile'. With a volatile process, the saved state held in the process record is lost when the process is run, so that the record is effectively empty until such time as the process suspends again. With a non-volatile process, the saved state (as it was at the time of running) is retained until the process is next suspended. ------------------------------------------------------------------- consproc_to, like much of Poplog, was designed and implemented by John Gibson. Aaron Sloman, School of Cognitive and Computing Sciences, Univ of Sussex, Brighton, BN1 9QH, England EMAIL aarons@cogs.sussex.ac.uk [Birmingham University from August 1991]