F0O@psuvm.psu.edu (10/13/90)
I've been reading over the section in the book on how you can have
modules in PDC prolog. You have to make what they call a 'project file'
or what I call a make file. This is ok. What I don't like is:
For each module, you have to put the name of the project at the top of
the file.
The next part is taken right out of the book, pg 76:
ALL THE MODULES IN A PROJECT NEED TO HAVE EXACTLY THE SAME GLOBAL
DATABASE AND GLOBAL DOMAINS DECLARATIONS.
and pg 77:
Global predicate declarations differ from local predicate declarations
because they must contain a description of the flow pattern(s) by which
each given predicate can be called.
Good heavens! This seems like a lot of work to me. In Turbo Pascal,
to use other modules, all you need is a:
USES module1 module2 module3 ...
Also, if I read the book right, why would you want to make a DATABASE
accessible to a module that might never use it? This does not seem like
good programming technique.
I do have to say, I have not tried any of this myself; just reading
the book sounds bad enough to scare me away. The Turbo pascal way of doing
modules sounds more elegant to me.
Do other people feel the same way, or am I just not understanding
something(quite possible :-) ).
[Tim]jgarland@kean.ucs.mun.ca (10/14/90)
In article <90285.232430F0O@psuvm.psu.edu>, F0O@psuvm.psu.edu writes: > I've been reading over the section in the book on how you can have > modules in PDC prolog. You have to make what they call a 'project file' > or what I call a make file. This is ok. What I don't like is: > > For each module, you have to put the name of the project at the top of > the file. > > The next part is taken right out of the book, pg 76: > > ALL THE MODULES IN A PROJECT NEED TO HAVE EXACTLY THE SAME GLOBAL > DATABASE AND GLOBAL DOMAINS DECLARATIONS. > > and pg 77: > > Global predicate declarations differ from local predicate declarations > because they must contain a description of the flow pattern(s) by which > each given predicate can be called. > > > > Good heavens! This seems like a lot of work to me. In Turbo Pascal, > to use other modules, all you need is a: > > USES module1 module2 module3 ... > > > Also, if I read the book right, why would you want to make a DATABASE > accessible to a module that might never use it? This does not seem like > good programming technique. > I do have to say, I have not tried any of this myself; just reading > the book sounds bad enough to scare me away. The Turbo pascal way of doing > modules sounds more elegant to me. > Do other people feel the same way, or am I just not understanding > something(quite possible :-) ). > > Personally, I just think of global declarations as .h files (in the C sense) and put them in include files. But as that takes you back towards C... John Garland jgarland@mun Bitnet jgarland@kean.ucs.mun.ca Internet
F0O@psuvm.psu.edu (10/14/90)
In article <145400@kean.ucs.mun.ca>, jgarland@kean.ucs.mun.ca says: >Personally, I just think of global declarations as .h files (in the C >sense) and put them in include files. But as that takes you back >towards C... Right, that's exactly what went through my mind too. Guess what PDC prolog is probably written in ... :-) Since I posted the original article, I have bit the bullet and tried the example they gave on pgs. 78-79 of the reference manual. It's not as bad as it sounds; although the solution is not to use any global domain or databases. Unfortunately, you can't get around the include file for the global predicates... I would imagine that not using any global domains, if you would have redundant declarations in different files, this would increase the size of the symbol table? I just hope PDC does improve the project facility, among other things in their next release. [Tim]
garym@cognos.uucp@uunet.uu.net (Gary Murphy) (10/15/90)
It gets worse: the project declaration is used to identify the .SYM file used by all the modules. If one file changes, the SYM may be changed, and this will require recompilation of all modules. By poking around with a hex editor, I did find that the .SYM didn't always change, but unfortunately, there is no way to ensure that it didn't. This almost totally cancels any benefit of using a command-line compiler within a MAKEFILE script. This project business has been with this prolog since the beginning. One one hand, it is commendable, as it does allow their WAM'ish compiler to easily attach to C language .LIB's and .OBJ's (unlike Arity et al where the interface is much more awkward), and it was one of the first prologs to address the 'flatness' of prolog predicate scope. On the other hand, it totally destroys any chance of code-reuse through building .LIB's of predicates (unless all are declared to be 'language c'). Like everyone else, I don't like the 'project' declaration, but I really can't see any way they could have avoided it. -- o | Gary Murphy |------------------------------------------------------------------------ o | uunet!mitel!cunews!cognos!garym garym@cognos.uucp@uunet.uu.net | Cognos Inc. P.O. Box 9707 Ottawa K1G 3N3 (613) 738-1338 x5537 o | "There are many things which do not concern the process" - Joan of Arc
ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (10/15/90)
In article <GARYM.90Oct14143102@cognos.uucp@uunet.uu.net>, garym@cognos.uucp@uunet.uu.net (Gary Murphy) writes: > This project business has been with this prolog since the beginning. > One one hand, it is commendable, as it does allow their WAM'ish > compiler to easily attach to C language .LIB's and .OBJ's (unlike > Arity et al where the interface is much more awkward), and it was one > of the first prologs to address the 'flatness' of prolog predicate > scope. (a) It is news to me that PDC Prolog is "WAMish". (It's the little things, like the tip in the manual that a trail size of 0 is fine for most programs...) (b) Project files have nothing to do with attaching to C stuff; other Prologs manage splendidly without. (PopLog, QP, ZYX, ALS, ...) What matters is the types and the "- language X" specification. (c) It is news to me that PDC Prolog was "one of the first Prologs to address the 'flatness' of Prolog predicate scope". M-Prolog was around for a long time before PDC Prolog; that's a serious commercial Prolog system. I've never been sure whether "M" stood for "Modular" or "Magyar" or what, either would be appropriate. PopLog inherited sections from Pop. LM Prolog inherited packages from Lisp. Prolog-X had modules. All of these were release quite a bit before PDC Prolog. > Like everyone else, I don't like the 'project' declaration, > but I really can't see any way they could have avoided it. Hmm. Many modern commercial Prolog systems provide some kind of modules, simple interfacing to C and other languages, and separate compilation to "binary" files, all without any need for "project" files. Lisp provides packages and separate compilation to "fasl" files without any need for "project" files. -- Fear most of all to be in error. -- Kierkegaard, quoting Socrates.
F0O@psuvm.psu.edu (10/15/90)
In article <GARYM.90Oct14143102@cognos.uucp@uunet.uu.net>, garym@cognos.uucp@uunet.uu.net (Gary Murphy) says: >It gets worse: the project declaration is used to identify the .SYM >file used by all the modules. If one file changes, the SYM may be >changed, and this will require recompilation of all modules. By >poking around with a hex editor, I did find that the .SYM didn't >always change, but unfortunately, there is no way to ensure that it >didn't. This almost totally cancels any benefit of using a command-line >compiler within a MAKEFILE script. Does anyone know what is actually happening to the .SYM file as each module you compile does something to it? I keep wondering this every time I see a reference to the .SYM file in the message window. >One one hand, it is commendable, as it does allow their WAM'ish >compiler to easily attach to C language .LIB's and .OBJ's (unlike >Arity et al where the interface is much more awkward), and it was one >of the first prologs to address the 'flatness' of prolog predicate >scope. On the other hand, it totally destroys any chance of code-reuse >through building .LIB's of predicates (unless all are declared to be >'language c'). Like everyone else, I don't like the 'project' declaration, >but I really can't see any way they could have avoided it. What do you mean by 'WAM'sih'? What does 'flatness of prolog predicate scope mean? The way I think they could get around the project keyword is to simply take the first filename in the makefile, assume that is the primary program and give the project that name. Yes/No/maybe? [Tim]
garym@cognos.uucp@uunet.uu.net (Gary Murphy) (10/15/90)
Terribly sorry: my last posting has been properly corrected (thanks to Richard) What I should have stressed is my innate PC bias: PDC (ad the tProlog before it) was the first in the MsDOS world to provide a usable WAMmy prolog with modules -- today, I think they _all_ have these features, but at the time of tProlog 1.0, this was the only one. As for the WAM-ishness: one need only dissassemble the code in the library to see all the old familiar forms -- PDC has a philosophy of keeping the metaprogramming out of the compiler (suggesting you model it), but the basic language underneath is still more WAM than anything else. The trail size switch is only a clue to the user options, and I have found that many general utility programs and applications coded in Prolog strictly to reduce development time can get by without the trail. The .SYM file is in fact not really for the C linkage as much as it allows the prolog code to be compiled with stack frames very different from the standard MsDOS conventions. If all predicates are declared as "function C" and no strings are passed between modules, the .SYM may not be required (I've only tried this on trivial programs). If Mr. O'Keefe (or anyone else) does know of a Prolog for the PC world which has re-usable modules (binary), can directly use 3rd party C libraries without extra glue and sells for an affordable price, please, please let us know; I'm no apologist for Borland/PDC, I just don't have the funds to keep a SPARC at home! In the mean time, I'll just bite the bullet and live with what I've got. -- o | Gary Murphy |------------------------------------------------------------------------ o | uunet!mitel!cunews!cognos!garym garym@cognos.uucp@uunet.uu.net | Cognos Inc. P.O. Box 9707 Ottawa K1G 3N3 (613) 738-1338 x5537 o | "There are many things which do not concern the process" - Joan of Arc
fore057@canterbury.ac.nz (10/20/90)
In article <GARYM.90Oct14143102@cognos.uucp@uunet.uu.net>, garym@cognos.uucp@uunet.uu.net (Gary Murphy) writes: > It gets worse: the project declaration is used to identify the .SYM > file used by all the modules. If one file changes, the SYM may be > changed, and this will require recompilation of all modules. By > poking around with a hex editor, I did find that the .SYM didn't > always change, but unfortunately, there is no way to ensure that it > didn't. This almost totally cancels any benefit of using a command-line > compiler within a MAKEFILE script. I have written a couple of large applications in Turbo/PDC prolog, and I've never had to recompile every module when only one was changed. Nor does the need for a project file bother me, in fact it can be rather convenient. I really appreciate the features of PDC Prolog, but while we're posting gripes, I'd like to have an overlay linker as part of the system. In the mean time, some information about overlay linking would be nice. Has anyone experience with overlay linking PDC Prolog modules? Can it be done with the MS-DOS standard linker? I have a suspicion that the DOS linker will only overlay link if the compiler has an overlay manager, is this so? I'd like to purchase the PDC Prolog professional user's guide, but I'm a poor student (sob), and I'm afraid that A$350 is just too far to stretch at the moment. Regards, Euan "When astronomers tell me that a star is so far off that its light takes a thousand years to reach us, the magnitude of the lie seems to me inartistic" - George Bernard Shaw
F0O@psuvm.psu.edu (10/20/90)
In article <1990Oct20.185338.9464@canterbury.ac.nz>, fore057@canterbury.ac.nz says: >I'd like to purchase the PDC Prolog professional user's guide, but I'm >a poor student (sob), and I'm afraid that A$350 is just too far to >stretch at the moment. Do I hear this right? $350 dollars for *a book*? Ye gadds, PDC must be crazy if they think many people are going to pay that kind of price for a book, or even 2 or 3. If this is right, then I'd say PDC has an attitude problem. [Tim]
fore057@canterbury.ac.nz (10/21/90)
In article <90293.102757F0O@psuvm.psu.edu>, F0O@psuvm.psu.edu writes: >>I'd like to purchase the PDC Prolog professional user's guide, but I'm >>a poor student (sob), and I'm afraid that A$350 is just too far to >>stretch at the moment. > > Do I hear this right? $350 dollars for *a book*? Ye gadds, PDC must > be crazy if they think many people are going to pay that kind of price for > a book, or even 2 or 3. > If this is right, then I'd say PDC has an attitude problem. To be fair to the PDC, the professional users guide comes with over 7000 lines of source code, on three disks. Still, it would be nice to get the promised information on overlay linking without having to shell out an extra $350, especially as it would appear that purchase of a linker like PLink86 or RTLink would also be required. I guess we have to remember that PDC Prolog users are few (my serial number is just under 3,500 for version 3.2, and I upgraded recently). The PDC developers have to eat somehow. If I had the money to spend, I wouldn't quibble. Regards, Euan "Men might as well project a voyage to the moon as attempt to employ steam across the stormy North Atlantic" - Address to the British Association, 1838
ada612@csc.anu.oz.au (10/29/90)
Re: Message-ID: <1990Oct21.155423.9467@canterbury.ac.nz>
From: fore057@canterbury.ac.nz
>To be fair to the PDC, the professional users guide comes with over 7000
>lines of source code, on three disks. Still, it would be nice to get the
>promised information on overlay linking without having to shell out an
>extra $350, especially as it would appear that purchase of a linker like
>PLink86 or RTLink would also be required.
>
>I guess we have to remember that PDC Prolog users are few (my serial number
>is just under 3,500 for version 3.2, and I upgraded recently). The PDC
>developers have to eat somehow. If I had the money to spend, I wouldn't
>quibble.
What is galling is not the $A350 price for the PCUG, but the fact that
it costs an extra $US110 or so over the American price of of $199. If
PDC users are few, why on earth did they decide to attempt to sell the
product in Australia thru a bunch of people who charge more than half
the price of the product to do some mailing and currency conversions?
With distributors like that you don't need competitors.
As for overlays, I've found empirically that one can sometimes get away with
using public domain overlay linkers such as Michael Devore's OVL 3.12,
if the predicates that are called across overlay boundaries are declared
as c predicates, and the program is linked as a mixed prolog & c program.
(you will probably also need to customize the stkln parameter at the
begininning of tcmain, to get a reasonable size of stack).
But it isn't reliable, for reasons that are unclear to me: minor
rearrangements of the source code seem to affect whether overlays
work or not. Perhaps the PCUG would reveal what is actually going on.
Also, someone who actually knew the gory details of how overlays work
on PCs might be able to improve on the results of my rather blind and
ignorant hacking.
Avery Andrews (ada612@csc.anu.oz.au)fore057@canterbury.ac.nz (10/30/90)
In article <1990Oct29.133821.3194@csc.anu.oz.au>, ada612@csc.anu.oz.au writes: > > What is galling is not the $A350 price for the PCUG, but the fact that > it costs an extra $US110 or so over the American price of of $199. If > PDC users are few, why on earth did they decide to attempt to sell the > product in Australia thru a bunch of people who charge more than half > the price of the product to do some mailing and currency conversions? > With distributors like that you don't need competitors. Hmm. I'll have to write to them about that, thanks. Thanks also for the tips on overlaying. Regards, Euan