🚀 go-pugleaf

     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