bs30@sirius.gte.com (Bernard Silver) (10/26/90)
Roger Scowen, convener and project editor for the ISO Prolog Group (WG17), had a few comments on the discussion going on here, and gave me permission to post the nessage below. In it, Roger cites a number of ISO documents. To give a flavour of the documents, here is the relevant part of N26, pg 9: Resolution XXX asks the project editors to formulate Principles and Rationale for Standard Prolog... a) Faithful to the spirit of logic programming b) The standard shall have a clear unambiguous definition c) The standard will try to leave the way open for extensions, for example the inclusion of constraints, object-oriented programming, parallel programming. d) The standard will not incluide features that will be an embarrassment in the future because they are expensive to those programs that do not use them, and provide only small benefits for those that do. e) The standard will not provide the same functionality in two different ways without good reason. f) Standard Prolog will be suitable for the development of large programs as well as small ones. g) Standard Prolog will, when possible, be compatible with existing code. h) When alternative formulations are possible, the main guidelines for the decision must be: 1) Reinforce the coherence and clarity of the language if there is no significant cost 2) Choose the alternative that reinforces the declarative aspects of Prolog" Here is Roger's message: ========================================================= Dear Bernard I have not seen all the correspondence on arg/3 in comp.lang.prolog but here a few comments. WG17 (and BSI) have tried to follow general principles - but have been unsuccessful in defining them or agreeing on proposals for principles. For example, see N26,p9; N35,p1; N36,Res'nA44. I have tried to apply consistently the concepts of Instantiation error (the goal might succeed or fail if more of the arguments were instantiated) and Type error (the goal can never succeed because one argument has an incorrect type). The idea of instantiation error is to leave open the idea of coroutining and freeze, etc. But WG17 has changed its mind on Term ordering - where ordering of variables used to give an instantiation error, but is now implementation dependent. Defining the error cases has always been the most difficult part of defining a BIP - see my comment in N64, 8.11.0.6(i). [This concerns the new I/O predicates. Without a good set of guiding principles, Roger cannot decide when a predicate should fail or generate an error. Bernard] Roger Scowen (SC22 WG17 Convener), DITC/93, National Physical Laboratory Teddington, Middlesex, England TW11 0LW 24 October 1990 Tel - Britain: 081 943 6956 (If no answer - NPL Operator is 081 977 3222) Tel - Abroad: +44 81 943 6956 (NPL Operator is +44 81 977 3222) Telex: 262344 Fax: Britain - 081 977 7091, Abroad - +44 81 977 7091 Email: rss@seg.npl.co.uk -- Bernard Silver GTE Laboratories bsilver@gte.com (617) 466-2663