Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!julius.cs.uiuc.edu!apple!portal!cup.portal.com!pgl From: pgl@cup.portal.com (Peter G Ludemann) Newsgroups: comp.lang.prolog Subject: Re: Standard ---> IBM PROLOG translation Message-ID: <34488@cup.portal.com> Date: 3 Oct 90 03:51:31 GMT References: <2574@dsacg3.dsac.dla.mil> <3850@goanna.cs.rmit.oz.au> Organization: The Portal System (TM) Lines: 124 I'm part of the IBM Prolog development group, so I guess I should try to put the record straight on IBM Prolog. It's a lot better than what some people allege it to be. In fact, I'd go so far as to say that it's the best Prolog on the market in terms of features, performance, and robustness. (But I'm biased ...) --- Disclaimer: the following are my own opinions; they have not been approved by IBM management or IBM lawyers; and I take full responsibility for any mistakes. First of all, there are *two* IBM Prologs. One is now obsolete. It implemented Grant Robert's Waterloo Prolog syntax (although it didn't use Grant's implementation techniques). Remember that this was done back in the Dark Ages when many people had only punched cards for input. So, the standard syntax was UPPER CASE. "Ugggghhhh", I hear you say. So, there was a second syntax called MIXED. It may come as no great surprise that almost everyone used MIXED. In fact, the new IBM Prolog doesn't even support upper-case only input (it doesn't require statement numbers in columns 73-80 either. :-)) So, let's move on to the new IBM Prolog. Its second release has just been released on CMS/SP, CMS/XA, MVS/XA and MVS/ESA (translation: it can exploit up to 2**31 bytes of memory); and has been announced for PS/2. [I really want to tell you some performance numbers, but I'll need legal clearance for that. Suffice it to say that I ran Peter Van Roy's tak benchmark and got speed figures comparable to tak with an optimizing C compiler; and that some benchmarks run in the 2+ mega-LIPS range.] Richard O'Keefe says: > Admittedly, the manual I have is for Version 1 Release 1 on VM/SP, > but if IBM's MVS release of IBM PROLOG differs significantly from > IBM's VM/SP release, other Prolog vendors will have difficulty keeping > the smiles off their faces. First, a minor correction to Richard: your manuals are also for VM/XA. Anyway, you can stop smiling; the MVS release is as compatible as can be after taking into account differences in operating systems (e.g., file naming conventions are different). I can readily pick my CMS programs and run them on MVS. What's more, IBM Prolog is tightly integrated with REXX (the system command language; it's better than C-shell + awk), GDDM (graphics display) and ISPF (dialogue manager); it also has very good facilities for calling and being called by C, Fortran, PL/I, Cobol and assembler and, last but no least, it also integrates well with the SQL/DS and DB2 relational databases. ----- As Richard points out, there is no need to write an "Edinburgh" translator; IBM provides one. IBM provides the user with the ability to tailor the syntax. Suppose that you think that lists should be written {a,b,c} instead of [a,b,c]? No problem. Would you like to use "if" instead of ":-"? Again, no problem. You get two pre-defined syntaxes: IBM standard ("synt1") and Edinburgh ("synt2"). But there's more ... > Better still, by using a Prolog program you can translate findall/3 to > compute/4 ... Why bother? IBM provides a bagof and a setof (it might come as no surprise that they translate almost directly into compute/4 or compute/5). What's more, they pass every evil test that Richard has mentioned about correct behaviour (thank-you Richard: I appreciate people who torture test programs. eally). IBM Prolog also provides user:expand_rule/2 which is a generalization of the usual expand_term/2. So, if you're really hung up on providing a translator, you can have it done for you during "consult". > The thing that puzzles me most is that Chapter 13 of the IBM PROLOG > manual states clearly and explicitly in the very first paragraph that > IBM PROLOG can process programs written with the Edinburgh > syntax and using predicates that are normally part of an [sic] > Prolog implementation for the Edinburgh syntax. > You can switch freely between syntaxes in your program, > and programs written in Edinburgh syntax can use all the > built-in predicates and data types of IBM PROLOG. > IBM's "Edinburgh" syntax (called 'synt2') isn't _quite Edinburgh syntax, > but it's close enough for government work. Coming from Richard, I'll take the "close enough" comment as a great complement. Besides, it's a little difficult know what exactly "Edinburgh" syntax is, what with Quintus, Arity, ALS, C-Prolog et al, not to mention ISO. Anyway, you really can write some predicates in Edinburgh and call them from IBM "standard" syntax (called "synt1"). What's more, you don't need to put built2: in front of all the predicates. If you're in synt2 (Edinburgh), write(X) will do what you expect (that is, you will get built2:write(X) which doesn't put a new-line after the term); if you're in synt1 (IBM), write(X) will get built:write(X) which does put a new-line after the term. It's all done with "priority prefixes" which are automatically switched when syntaxes are changed. The description is in the manual, under the "declare" directive and the "prio_pref" global term. Moreover, you can control in which syntax a term is written. For example, write(f(','(a,b))) from synt1 ==> f(","(a,b)) write(f(','(a,b))) from synt2 ==> f((a,b)) because "," is an operator only in synt2 and because '...' is the delimiter for atoms in synt2 but "..." is the delimiter in synt1. (This is a special case of `meta predicates'.) There are lots more nice features in the implementation, but I've rambled on enough. Feel free to take cheap shots at JCL (I don't use it any more; I use REXX); I think that you'll find cheap shots at IBM Prolog a little more difficult. Flames to me: - Peter Ludemann ludemann@mlpvm1.iinus1.ibm.com (disclaimer: the above are my opinions, and not IBM's)