ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (03/21/91)
In article <12066@uhccux.uhcc.Hawaii.Edu>, todd@uhunix1.uhcc.Hawaii.Edu (Todd Ogasawara) writes: > programmers all use clumsy primitive tools to do development? The > integration of a good development environment with a functioning and > optimized interpreter or compiler is the key to professional software > development. > Yes, but Turbo Prolog survives as PDC Prolog. I'm not saying that PDC > Prolog is better than Arity. If I did, I would have switched to it long ago > since it does provide a lot of the environmental features I want to see it > Arity. > While I would agree that the "Prolog aspects" of Arity Prolog meet all the > requirements needed to write "Prolog" programs, the package itself falls > far short of what "professional" programmers expect to be provided in a > professional development system. I think there is something of great value to all of us to be extracted from this discussion, and I think it warrants a new thread. I have _not_ used Arity/Prolog, and I _have_ used Turbo Prolog. I found the Turbo environment to be a pain where I sit down, and that's throwing roses at it. Turbo wanted me to do everything _it's_ way in stupid little tiny windows. I would *eagerly* have sacrified colour and all their nasty menus for a really simple interface which just sat there and did what I told it. It is difficult for me to imagine anything more painful to use, and no, I would not regard an upper case model 33 teletype as more painful than Turbo's environment. So there's a very important question. What DO people want in a Prolog development environment? I would like things like - find-definition - incremental cross-referencer (like UTIL:IXREF only graph based) - graphical profiler (gauge) - partial execution tool, with a large kit of templates to work from - data flow checkers (mode analysis &c) - OPTIONAL type checkers (like NU Prolog's four) - declarative debugging tools - some kind of "smart" documentation facility (something like the Eiffel tools, perhaps) - a system which associates test data with program components, without using source trick like 'end_of_file' Some of these things are in LPA MacProlog (in fact, if only LPA MacProlog was closer to Edinburgh Prolog I would like that environment a lot), some of them are in SICStus Prolog, some of them are in NU Prolog, some of them exist as separate tools. Of major importance to me is - a LARGE library of working reusable components (what would Eiffel be without its library?) I think the Quintus Prolog library is about 1/10th of the "right" size for a Prolog library. (I have given up waiting for an answer to the question of what cones are FOR, by the way...) As I recall the Turbo Prolog 2.0 environment, it addressed *none* of these issues. (It had a type checker, but it wasn't optional, and the type system was *pathetic*.) So what ARE the things that professional programmers expect in a professional development system that Arity fails to provide, and who does provide them? What, for goodness' sake, is it that Turbo does right? -- Seen from an MVS perspective, UNIX and MS-DOS are hard to tell apart.
todd@uhunix1.uhcc.Hawaii.Edu (Todd Ogasawara) (03/23/91)
In article <5024@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes: >In article <12066@uhccux.uhcc.Hawaii.Edu>, todd@uhunix1.uhcc.Hawaii.Edu (Todd Ogasawara) writes: >> programmers all use clumsy primitive tools to do development? The >> integration of a good development environment with a functioning and >> optimized interpreter or compiler is the key to professional software >> development. >I think there is something of great value to all of us to be extracted >from this discussion, and I think it warrants a new thread. I have >_not_ used Arity/Prolog, and I _have_ used Turbo Prolog. I found the >Turbo environment to be a pain where I sit down, and that's throwing >roses at it. Turbo wanted me to do everything _it's_ way in stupid >little tiny windows. I would *eagerly* have sacrified colour and all >their nasty menus for a really simple interface which just sat there Despite what I said about Turbo Prolog's environment (re: I said it had features I liked), I agree with Richard although I don't think I disliked it as much as he. For me, the non-Prolog nature of Turbo Prolog was the main reason I gave it a thumbs down. But its been years since I actually played with it, so perhaps my memories of its environment is not accurate either. >So there's a very important question. What DO people want in a Prolog >development environment? I would like things like [...] >So what ARE the things that professional programmers expect in a >professional development system that Arity fails to provide, and >who does provide them? What, for goodness' sake, is it that >Turbo does right? My foggy recollection of the two things I liked about Turbo Prolog's environment (I think I last looked it around 1988 or so) were (1) what looked liked a good start on a source debugger and (2) the fact that code in the edit-test-debug-edit cycle always worked in final compiled for if it got through the development cycle (since, if I recall correctly, Turbo Prolog did not really have an interpreter). Some of the things I want in a development environment are (and I'm sure I'm forgetting a few things here) in no particular order. o An easy to use but powerful debugger/tracer. Something akin to what Turbo Debugger is to Borland C++ o An integrated editor that is powerful, flexible, and extensible. I am speaking here of something like the Sage Professional Editor or even GNU EMACS. I would want to be able to go from the editor to either the interpreter or compiler very easily for testing and then get back to my editor again very easily. o The editor should also have a good help system that is context sensitive. This is especially important for documentation on vendor-unique extensions (windowing, menuing, etc.). A hypertext type facility like we seen in Quick C, Borland C++, etc. is fine for me. o The compiler (and I do want a compiler as well as an interpreter) should be able to take code developed in an interpreted environment without much code modification (zero code mods would be perfect). o There should be good online (hypertext) as well as hard copy documentation. o There should be either a built-in or third party source code version control facility (I use SCCS out of habit but I know there must be better source code control software out there). I'm sure I forgot a few things (like mentioning a built-in 'make' facility) but those are the items that come to mind just now. -- Todd Ogasawara, U. of Hawaii UUCP: {uunet,ucbvax,dcdwest}!ucsd!nosc!uhunix!todd BITNET: todd@uhunix INTERNET: todd@uhunix.UHCC.HAWAII.EDU
fore057@csc.canterbury.ac.nz (03/23/91)
I use PDC Prolog for most of my development work. The things I like about the development environment are: o Code can be compiled and tested in memory, and then compiled into an object file with no modification. o During compilation, all sorts of minor bugs are detected and flagged, such as variables used once in a clause, mismatched types, non-deterministic clauses (unless specifically declared as such), etc., and the cursor is placed at the location of the bug, in the editor, and a clear message describing the error is given in another window. o Users have plenty of control over memory allocation for code, stack, heap, and so on. o Excellent diagnostics are available for code comparisons. o The trace and short-trace facilities are exceptionallly easy to follow, with variable values shown in one window whilst the clauses used are shown in another. o There is plenty of on-line help, plus a very complete set of manuals. o Projects can be linked and tested (if enough RAM is available) from within the environment. o Sources and libraries can be placed in organised subdirectories, and accessed as needed. Source files can be included in modules simply by indicating their names within the modules. As for the non-prolog features, I have no objection to typing variables, in fact I appreciate the easier debugging and speed which typing provides. I also have not yet found the fact that no conditional clauses can be asserted or saved during program execution to be a severe limitation. As for external disk or EMS databasing with multiple (LAN) access and B+tree indexing, well, I couldn't do without them now! The Borland Graphics Interface is also a plus. It's a case of horses for courses, I guess. Additional things I would like added are: o An overlay facility in the linker. o Object files larger than 64 kb. o A version for microsoft windows (there are already versions for OS/2 and UNIX). o The ability to go to a specified position within the source code. If run-time errors occur, the module name and error position (as an integer value) are given, and it would seem to be relatively trivial to configure the editor to place the cursor at the specified position, but this facility is not provided. Regards, Euan
ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (03/25/91)
In article <1991Mar23.162203.305@csc.canterbury.ac.nz>, fore057@csc.canterbury.ac.nz writes: > o Users have plenty of control over memory allocation for code, stack, heap, > and so on. Gods below! One of the major *FLAWS* in Turbo/PDC (and a lot of other products too, to be fair), and it's called a feature! One of the points about Prolog systems is that memory management is the SYSTEM's problem, not the programmer's. The half-dozen or so Prolog systems I use from time to time divide memory up using half-a-dozen or so different schemes. (For example, one has a special memory area whose size I HAVE TO control for numbers. Ick!) Dynamically resizing memory areas and moving them around to fit may have been state of the art 20 years ago, but by now it is "kindergarten" level. Let me give you an example of what is WRONG with this approach. As it happens, the system I was using was Turbo Prolog 2.something There was one phase of the program which needed a lot of space in area A, but very little in area B. A later phase needed a lot of space in area B, but very little in area A. It turned out to be impossible to find a single static allocation which was adequate for both phases. So I just couldn't run my program. Why? Because of an entirely ARTIFICIAL restriction. There was more than enough space on the machine to do the job. (In fact ALS Prolog just flew through it.) But because Turbo's implementors had seen fit to unload part of *their* job onto the paying customer, the system was not usable. In operating systems such as MS-DOS, where several programs may be sharing a single address space, it *is* reasonable to ask the programmer to specify a limit on the *total* amount of memory to be dedicated to any particular program. But the size of individual highly-system-specific partitions? That is quite *unreasonable*. > o There is plenty of on-line help, plus a very complete set of manuals. Hm. Presumably PDC have rewritten the manuals completely. I found the Turbo 2.something manuals incomplete and confusing. -- Seen from an MVS perspective, UNIX and MS-DOS are hard to tell apart.
fore057@csc.canterbury.ac.nz (03/25/91)
In article <5044@goanna.cs.rmit.oz.au>, ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes: > There was one phase of the program which needed a lot of space in > area A, but very little in area B. A later phase needed a lot of > space in area B, but very little in area A. It turned out to be > impossible to find a single static allocation which was adequate > for both phases. So I just couldn't run my program. Why? Because > of an entirely ARTIFICIAL restriction. There was more than enough > space on the machine to do the job. (In fact ALS Prolog just flew > through it.) But because Turbo's implementors had seen fit to > unload part of *their* job onto the paying customer, the system was > not usable. Was it stack space that was the problem? I'd be interested to hear what the PDC would recommend for this situation - are you there Per? A solution may have been to use the check_determ instruction to locate the non-deterministic clauses causing the problem, and insert some cuts. Was the ALS prolog running on an IBM compatible? I wonder what features are missing in ALS prolog compared to PDC prolog to make space for dynamic stack allocation between modules (if that's what you're refering to)? Does ALS have many of the other features I mentioned in my previous posting? Regards, Euan
jmcn@castle.ed.ac.uk (J McNicol) (03/26/91)
In article <12102@uhccux.uhcc.Hawaii.Edu> todd@uhunix1.uhcc.Hawaii.Edu (Todd Ogasawara) writes: >Some of the things I want in a development environment are (and I'm sure >I'm forgetting a few things here) in no particular order. Have you considered using Prolog-2 for Windows 3.0? It's a good solid Prolog which accesses Windows primitives for dialog and graphics handling. Windows being an 'environment', Prolog doesn't have to provide all of the tools itself. > >o An easy to use but powerful debugger/tracer. Something akin to what > Turbo Debugger is to Borland C++ The Prolog-2 debugger seems pretty good, with a separate trace window and buttons for skip, step, etc. > >o An integrated editor that is powerful, flexible, and extensible. I > am speaking here of something like the Sage Professional Editor or > even GNU EMACS. I would want to be able to go from the editor to > either the interpreter or compiler very easily for testing and then > get back to my editor again very easily. Just use MicroEmacs for Windows! >o The editor should also have a good help system that is context sensitive. > This is especially important for documentation on vendor-unique > extensions (windowing, menuing, etc.). A hypertext type facility like we > seen in Quick C, Borland C++, etc. is fine for me. > Emacs has a reasonable help facility. >o The compiler (and I do want a compiler as well as an interpreter) should > be able to take code developed in an interpreted environment without > much code modification (zero code mods would be perfect). > I don't think the compiler is terribly hot since I haven't got any speed increase using it, but it works (slowly). I probably haven't tested it sufficiently. >o There should be good online (hypertext) as well as hard copy documentation. Prolog-2 has a hypertext-like help facility in the Windows 3.0 style, documenting all extensions. It's just been upgraded and is very handy. I can't be as enthusiastic about the manuals though, they are chaotic to put it kindly. But the information is there. >o There should be either a built-in or third party source code version > control facility (I use SCCS out of habit but I know there must be > better source code control software out there). I use GNU RCS. > >I'm sure I forgot a few things (like mentioning a built-in 'make' facility) >but those are the items that come to mind just now. I have my own 'make' facility which is easy as clicking on an icon. Overall I like Prolog-2 for Windows very much, especially as it means I can write Windows 3.0-ish applications easily (there are no run-time license fees, just the large memory cost!) and there is no DOS memory limitation. BTW the support is excellent since the author of the software responds to queries directly. I just got some promised improvements, including some requests I made for selectable fonts and a polygon primitive. Julian Smart Disclaimer - I have nothing whatsoever to do with Expert Systems Ltd., I'm just a satisfied customer.
ted@nmsu.edu (Ted Dunning) (03/26/91)
In article <5044@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes: ... about turbo prolog ... > o There is plenty of on-line help, plus a very complete set of > manuals. Hm. Presumably PDC have rewritten the manuals completely. I found the Turbo 2.something manuals incomplete and confusing. in particular, what i found most confusing was the fact that the bold print warning was missing. it should have read: THIS PRODUCT IS NOT AN IMPLEMENTATION OF THE PROGRAMMING LANGUAGE PROLOG. i spent several hours trying to divine how the implementors expected one to write prolog programs before i realized that they explicitly didn't want me to be writing in prolog. anybody who thinks otherwise should post an viable implementation of setof/3 in turbo (pdc) prolog.
fore057@csc.canterbury.ac.nz (03/27/91)
Reply from Per Bilse, one of the authors of PDC Prolog: From: IN%"pdev@pdc.dk" 26-MAR-1991 21:42:14.83 Subj: Re: Environments I'm out here, but not in a posting capacity. Recommendations depend on what areas A and B refer to. If it's stack space, there's little to do. Some (all?) Prolog interpreters run on a virtual stack, allowing more than 64K stack, while we (having fully compiled target code) use the CPU stack; the difference in speed is between 100:1 and 1000:1 :-). And you can multiply that with anything between 2 and 5 if running in '286 protected mode ... the things we sacrifice for a puny performance gain ... :-) ... If the problem is in the trail, the restriction has been lifted: newer versions of PDC have a dynamic auto-expanding trail. Irrespective of all this, I agree with OK that os-related restrictions of this kind shouldn't be passed on to the programmer. On the other hand, we all know that many things are a tight squeeze in DOS and I suspect situations like the one he describes will only apply in rare instances: stack + trail will occupy at most 2*64K so if that's causing memory shortage, he'd be close to the limit anyway. Nevertheless, the performance ratio of a running program over a non-running one remains at approximately 1:0 ... While we're at it, I know of no modern-day operating system having memory limitations worth worrying about, or 16-bit near pointers. Hence, the UNIX version of PDC Prolog can have stack, trail, gstack, whatever, in the Gigabyte range. Nice. Feel free to post, if you wish. Best Wishes per (aka pdev, root, mmdf, etc)
ada612@csc.anu.edu.au (03/28/91)
In article <5044@goanna.cs.rmit.oz.au>, ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes: ++As it happens, the system I was using was Turbo Prolog 2.something ++There was one phase of the program which needed a lot of space in ++area A, but very little in area B. A later phase needed a lot of ++space in area B, but very little in area A. It turned out to be ++impossible to find a single static allocation which was adequate ++for both phases. So I just couldn't run my program. Why? Because ++of an entirely ARTIFICIAL restriction. There was more than enough ++space on the machine to do the job. (In fact ALS Prolog just flew ++through it.) But because Turbo's implementors had seen fit to ++unload part of *their* job onto the paying customer, the system was ++not usable. What kind of black magic is ALS Prolog employing here? The impression I get from the Jan 91 issue of AI Expert is that Arity, PDC (formerly Turbo), Quintus, & ALS Prologs for MS-DOS all suffer from annoying restrictions on memory, and that Turbo (now PDC) is for the most part less limited than the others in this respect. Everybody seems to have to make nasty compromises to shoehorn Prolog into MSDOS, and I wonder if Richard's program wasn't merely one where ALS's deal with the devil just happened to work out while PDC's didn't. Some anecdotal evidence that PDC is pretty economical with memory is that I have managed to write in it an LFG grammar-development system for students learning linguistics which includes a built in editor, simple morphology & lots of notational sugar for the rules and lexical entries. A similar system written in 1986-vintage Arity Prolog at Stuttgart seems to fill up the machine without providing any of these features (`Edit' appears on the menu, but there's a `no space' apology rather than an actual integrated editor). (The design of their parsing system plus the fact that they used overlays makes it unlikely that this is because their approach was inherently more memory-intensive than mine. I would in fact expect the opposite to be true.) Avery Andrews (ada612@csc.anu.edu.oz)
dinapoli@rodan.acs.syr.edu (Ron DiNapoli) (03/28/91)
In article <1991Mar28.113930.1@csc.anu.edu.au> ada612@csc.anu.edu.au writes: >In article <5044@goanna.cs.rmit.oz.au>, >ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes: > >++As it happens, the system I was using was Turbo Prolog 2.something >++There was one phase of the program which needed a lot of space in >++area A, but very little in area B. A later phase needed a lot of >++space in area B, but very little in area A. It turned out to be >++impossible to find a single static allocation which was adequate >++for both phases. So I just couldn't run my program. Why? Because >++of an entirely ARTIFICIAL restriction. There was more than enough >++space on the machine to do the job. (In fact ALS Prolog just flew >++through it.) But because Turbo's implementors had seen fit to >++unload part of *their* job onto the paying customer, the system was >++not usable. > >What kind of black magic is ALS Prolog employing here? The impression >I get from the Jan 91 issue of AI Expert is that Arity, PDC (formerly >Turbo), Quintus, & ALS Prologs for MS-DOS all suffer from annoying >restrictions on memory, and that Turbo (now PDC) is for the most part less >limited than the others in this respect. Everybody seems to have to make >nasty compromises to shoehorn Prolog into MSDOS, and I wonder if Richard's >program wasn't merely one where ALS's deal with the devil just happened >to work out while PDC's didn't. > ALS Prolog Professional for MS-DOS machines employs a virtual code space feature which, in theory, allows for an unlimited amount of code to be compiled. Due to other restrictions in the system this usually means that, in practice, you will run into other limitations of the system before you will run out of code space. It is possible to run out of code space if the procedures in physical memory are positioned in such a way that fragments the physical memory holding them. If this occurs it is possible that there will not be a free block of memory large enough to hold a procedure which needs to be loaded. In ALS Prolog for 386 machines (w/ DOS extenders) the Prolog system takes advantage of the virtual memory facilities provided by the OS. The user may, with command line switches, set the size of the heap and stack. The code space is allocated the remainder of memory (virtual) available to the Prolog application. Ron DiNapoli ALS, Inc.
bradley@cs.utexas.edu (Bradley L. Richards) (03/29/91)
In article <1991Mar28.113930.1@csc.anu.edu.au> ada612@csc.anu.edu.au writes: >What kind of black magic is ALS Prolog employing here? >Everybody seems to have to make >nasty compromises to shoehorn Prolog into MSDOS I doubt its black magic--just lack of laziness. Arity, non-386 LPA, and the rest just allocate a single 64k segment of memory for each stack. It takes a bit more work to manage chunks of memory larger than 64k on a non-386 machine, but it's hardly prohibitive. In fact, most compilers provide support for whatever size objects you want to manage. Of course, on 386 systems, the problem goes away altogether. Bradley
andaling@durras.anu.edu.au ("A.Andrews") (03/29/91)
Responding to some messages about memory allocation in LSA prolog that our news system seems to have lost ... I still find no evidence that PDC prolog is particularly primitive or lazy in its memory allocation. In it you specify the size of the stack and the trail, each with a 64K max, and the remaining areas (global stack & heap, for structures that are to be reclaimed on backtracking & those that aren't, respectively) jointly occupy the remaining available memory (which you can restrict if you want to), growing toward each other (the heap is subject to fragmentation, and doesn't automatically compress itself, but you can compact it manually if you want to, though this is harder than I think it ought to be -- this I guess is somewhat culpable). The 64K limits sound depressingly familiar, but I haven't found them particularly irksome, presumably because structures are stored on the global stack, which does not have a 64K limit (what happens with structures in other kings of PC Prolog? - my impression of 86 vintage Arity is that a single 64K stack performed the functions of both PDC's local and global stacks, but this might well be a misinterpretation). All the MSDOS Prolog systems seem to be blemished with 64K limitations, and even though everyone whinges about them as being utterly stupid, they seem to be something that MSDOS forces on you if you want tolerable execution speed. And PDC has nothing like the 40K `clause space' limitation of ALS Prolog, whatever that amounts to (but it sounds pretty ominous to me -- perhaps part of the price you by for on-the-fly compilation of conditional clauses?). Avery Andrews (ada612@csc.anu.edu.oz)