Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!sgi!decwrl!curie.dec.com!vantreeck
From: vantreeck@curie.dec.com
Newsgroups: comp.lang.prolog
Subject: BSI standards
Message-ID: <8803082357.AA01587@decwrl.dec.com>
Date: 8 Mar 88 23:57:05 GMT
Organization: Digital Equipment Corporation
Lines: 43

RE: Chris Moss' comments on the proposed BSI standards for PROLOG syntax.

I read the reports also. I'd rather see user defined operators left out the
standard entirely because it complicates the parsing current Edinburgh syntax
such that it is difficult to write a parser in a low level language (which
would provide significant space and time advantages). And I also don't like
user defined operators because it makes it impossible to write a simple BNF to
describe the syntax, i.e., makes the language much more difficult to
understand for very little gain in language capability. It seems like an lot
of work is being done to make PROLOG syntax work for a feature of very minor
importance. 

I know other disagree. And seeing as how user defined operators are going
to be part of PROLOG, I am *VERY HAPPY* to see that the syntax for operators
is being done such that it will be easier to write deterministic parsers.
I'd much rather have half a loaf than none.

RE: the rest of the standard.

I also see proposals for new data types, e.g., character, string, and list. I
wish someone could explain why these are really needed as part of standard.
PROLOG is supposed to be a high level language. It's advantage over lower
level languages is that it allows one to program at a more abstract level. One
should not have to be labored with low level, implementation details, of how
data is physically represented. 

It seems to me that type string is totally unnecessary. I have a small PROLOG
compiler on my Mac+ that does not make a distinction between string and atom.
The symbol table is garbage collected on backtracking. Yes, it is a little
slower than putting a string on top of the heap. But how much time do most
PROLOG programs spend doing string functions? 

I doubt that most PROLOG programs spend enough time doing string functions
that it should drive the PROLOG programmer into thinking about physical data
representation. If a lot of that kind of string manipulation is significantly
impacting performance of a PROLOG program, it would be better to write that
portion of the program in a language more suited to that task, and
link it into the PROLOG program.

If the consensus is that it is necessary to have implementation details drive
the standard, it should be clearly isolated as ANSI C and Ada do, e.g., use of
a ":- pragma" directive.

-George