Newsgroups: comp.lang.prolog
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!howland.reston.ans.net!agate!darkstar.UCSC.EDU!news.hal.COM!decwrl!netcomsv!netcom.com!pgweiss
From: pgweiss@netcom.com  (Paul G. Weiss)
Subject: Re: Death to Arity!
Message-ID: <pgweissD0oMA0.BpE@netcom.com>
Sender: pgweiss@netcom.com (Paul G. Weiss)
Reply-To: pgweiss@netcom.com
Organization: Arity Corporation
X-Newsreader: IBM NewsReader/2 v1.03
References: <1994Dec5.215606.15801@bnlux1.bnl.gov> <3c0qom$eb4@hobbes.cc.uga.edu> <TOM.94Dec9150953@heather.kwi.com>
Date: Mon, 12 Dec 1994 05:08:24 GMT
Lines: 91

Death to Arity?  You obviously feel very strongly about your choice of 
Prolog implementation!

In <TOM.94Dec9150953@heather.kwi.com>, tom@kwi.com (Tom Howland) writes:
..
>I really hate Arity Prolog. Some of the reasons include
>
>** doesn't have -> (if-then-else). Instead, they have the non-standard
>construct "snip", written as [! (begin snip) and !] (end snip). Snip can
>be translated directly into "->" as
>
>	   [! foo, baz !] <==> (foo, baz -> true)
>
>But there is no way to translate very basic uses of standard Prologs
>"->" into "snip". For example
>
>	(   foo
>	->  b
>	;   baz
>	),
>
>where "b" backtracks. You can't say this using "snip".
>

Actually (foo->b;baz) translates into Arity/Prolog as
ifthenelse(foo, b, baz).  The goal "b" is indeed allowed
to backtrack.  You don't use snips here at all.

>** doesn't have indexing on asserted code. This forces you to use the
>recorded database and use database references for fast access to the
>database. With indexing on dynamic code, you don't need database
>references anymore.
>

It is true, we don't index dynamic code.  We have instead concentrated
on our b-tree and hash-table access and, yes, database references.
Our customers have consistently told us that our admittedly non-standard
database is among their most favorite Arity/Prolog features.  Access to
database references allows them to do all kinds of clever things.  If
I ever changed this I'd be lynched.  

>** doesn't have dynamic stack expansion, nor does it have a garbage
>collector. For example, a seasoned Arity Prolog programmer would *never*
>call sort/2 -- he's afraid of running out of stack space!

We have always had a garbage collector.  However, if you are running our
16-bit product you are still limited to 64K of local+trail and 64K of global.  Our
32-bit product has no such limitation.

> Here is a
>typical atrocity I came across
>
>what they meant was
>
>    append_once(X,Y,Z) :- ( append(X,Y,Z) -> true ).
>
>what they wrote was
>
>    append_once(L1,L2,L3) :-
>        [! append(L1,L2,L3),  recordz(append_once,append(L1,L2,L3),_) !],
>        fail.
>    append_once(L1,L2,L3) :-
>        [! recorded(append_once,append(L1,L2,L3),Ref), hard_erase(Ref) !].
>
>Now, you may look at that and think it is merely incompetent, but in
>fact, it is clever when using Arity.
>
>This is because it is safer in Arity to get your bindings from the
>database then from normal unification. You're less likely to get stack
>overflows.
>

This indeed is an atrocity.  I would simply write:

	append_once(L1, L2, L3) :- [! append(L1, L2, L3) !].
or 
	append_once(L1, L2, L3) :- ifthenelse( append(L1,L2,L3), true, fail ).

I have to admit that I don't understand what you are saying about normal
unification and stack overflows.

>Working in an environment like this has a profound impact on the style
>of Prolog that you write. In other words, Arity forces you write crummy
>code.

Yes, it is true that you can write crummy code in Arity/Prolog, as in any other
programming language.  However, indicting Arity/Prolog for a poorly written piece
of user code is not what I'd call fair.

-Paul Weiss
-Arity Corporation
