Path: utzoo!mnetor!tmsoft!torsqnt!jarvis.csri.toronto.edu!rutgers!mit-eddie!uw-beaver!ubc-cs!eric!joplin!ssmith From: ssmith@joplin.mpr.ca (Shaun Smith) Newsgroups: comp.lang.prolog Subject: Re: More fun with WG17 Summary: Prolog for Users! Keywords: Prolog, WG17, Portability, Standards Message-ID: <1916@eric.mpr.ca> Date: 24 Nov 89 19:20:22 GMT References: <2609@munnari.oz.au> <696@sce.carleton.ca> <2643@munnari.oz.au> <715@sce.carleton.ca> <2780@munnari.oz.au> <1378@gould.doc.ic.ac.uk> Sender: news@eric.mpr.ca Reply-To: ssmith@rhumba.UUCP (Shaun Smith) Organization: Microtel Pacific Research Ltd., Burnaby, B.C., Canada Lines: 120 As one who programs in Prolog on a daily basis, I'd like to put my two bits worth in about the BSI standardization. I don't want to put words into Richard O'Keefe's mouth, and please don't jump all over me for my possible misunderstanding of his position, but after following the discussion of WG17, I find myself believing much of what he's said. I want a standard that embodies what "most" people believe to be "standard" prolog. Now, again, no flames until I've fully explained myself. Yes, I know there is no such thing as "standard" prolog or "common" prolog, but somehow we all seem to know what that means. As an example, let me tell you of a porting of a fairly large (~400k of source) prolog program. This program was written with portability in mind. The program was partitioned into "standard" prolog files and then a set of files that contained dialect dependent code. In other words, there was a large number of files that made up the core program and 2 files per prolog dialect. These files contained things like the usually non-standard "statistics" predicate or it's equivalent in the various prolog dialects. C-Prolog, Quintus Prolog, and Arity Prolog were originally supported. We ported the program to BIM Prolog. Now the point of this is, we were able to port this thing! I was amazed, but the writers of the program were determined that it should be portable, and be usable under different prologs on different platforms. In other words, they were doing the right thing. All we did was write the appropriate BIM Prolog specific file. By the way, all of these dialect specific files were very short. Here at MPR we've been developing a compiler and run time system for a language developed in house. We are using Prolog and C (for historical reasons) to do this. The very last thing management wants to see is 8 months to a year of code suddenly become unsupported by most Prolog vendors!! Ultimately, the standard should please those that use prolog, and whose business depends upon it. If the committee have ideas about what prolog might best become, then I too think that they are free to write a standard for that _other_ language. I beg those on the committee to please consider those who stand to lose the most by a standard that breaks all our code. Shaun Newsgroups: comp.lang.prolog Subject: Re: More fun with WG17 Summary: Prolog for Users! Expires: References: <2609@munnari.oz.au> <696@sce.carleton.ca> <2643@munnari.oz.au> <715@sce.carleton.ca> <2780@munnari.oz.au> <1378@gould.doc.ic.ac.uk> Sender: Reply-To: ssmith@rhumba.UUCP (Shaun Smith) Followup-To: Distribution: Organization: Microtel Pacific Research Ltd., Burnaby, B.C., Canada Keywords: Prolog, WG17, Portability, Standards As one who programs in Prolog on a daily basis, I'd like to put my two bits worth in about the BSI standardization. I don't want to put words into Richard O'Keefe's mouth, and please don't jump all over me for my possible misunderstanding of his position, but after following the discussion of WG17, I find myself believing much of what he's said. I want a standard that embodies what "most" people believe to be "standard" prolog. Now, again, no flames until I've fully explained myself. Yes, I know there is no such thing as "standard" prolog or "common" prolog, but somehow we all seem to know what that means. As an example, let me tell you of a porting of a fairly large (~400k of source) prolog program. This program was written with portability in mind. The program was partitioned into "standard" prolog files and then a set of files that contained dialect dependent code. In other words, there was a large number of files that made up the core program and 2 files per prolog dialect. These files contained things like the usually non-standard "statistics" predicate or it's equivalent in the various prolog dialects. C-Prolog, Quintus Prolog, and Arity Prolog were originally supported. We ported the program to BIM Prolog. Now the point of this is, we were able to port this thing! I was amazed, but the writers of the program were determined that it should be portable, and be usable under different prologs on different platforms. In other words, they were doing the right thing. All we did was write the appropriate BIM Prolog specific file. By the way, all of these dialect specific files were very short. Here at MPR we've been developing a compiler and run time system for a language developed in house. We are using Prolog and C (for historical reasons) to do this. The very last thing management wants to see is 8 months to a year of code suddenly become unsupported by most Prolog vendors!! Ultimately, the standard should please those that use prolog, and whose business depends upon it. If the committee have ideas about what prolog might best become, then I too think that they are free to write a standard for that _other_ language. I beg those on the committee to please consider those who stand to lose the most by a standard that breaks all our code. Shaun Shaun M. Smith | ssmith@joplin.mpr.ca Microtel Pacific Research | joplin.mpr.ca!ssmith@uunet.uu.net 8999 Nelson Way, Burnaby, BC | ssmith%joplin.mpr.ca@relay.ubc.ca Canada, V5A 4B5, (604) 293-5345 | ...!ubc-vision!joplinmpr.ca!ssmith