Newsgroups: comp.lang.prolog
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!howland.reston.ans.net!swrinde!pipex!uunet!allegra!alice!pereira
From: pereira@alta.research.att.com (Fernando Pereira)
Subject: Re: In defense of Prolog's dynamic typing
In-Reply-To: vanroy@dfki.uni-sb.de's message of 23 Nov 1994 14:17:42 GMT
Message-ID: <PEREIRA.94Nov23222128@alta.research.att.com>
Sender: usenet@research.att.com (netnews <9149-80593> 0112740)
Nntp-Posting-Host: alta.research.att.com
Reply-To: pereira@research.att.com
Organization: AT&T Bell Laboratories
References: <3aviu6$7dq@hitchcock.dfki.uni-sb.de>
Date: Thu, 24 Nov 1994 03:21:28 GMT
Lines: 56

In article <3aviu6$7dq@hitchcock.dfki.uni-sb.de> vanroy@dfki.uni-sb.de (Peter Van Roy) writes:
> Here's a strong argument _against_ strong typing.

> In Prolog, programs and terms have exactly the same syntax, and it
> is easy to manipulate programs as data.  This is second nature to
> Prolog programmers, and most good ones have used preprocessors and
> program generators to good advantage.  Prolog supports this well,
> in particular, the ==/2 comparison effectively treats variables as
> atoms, so that terms representing programs can be manipulated with
> ease.

> So here's a question for advocates of strong typing: how can I
> manipulate programs as data in a strongly typed language in a way
> that is as simple and natural as Prolog's?
This old chestnut is popular among Lisp and Prolog afficionados.
But in any decent strongly-typed language (eg. SML, Modula-3) you
can define datatypes for the abstract syntax of the language and write
syntax-driven program manipulation programs. Pattern-matching helps in
writing such programs, thus SML is an especially good candidate for
this. The other thing you need is an easily-callable parser for the
language returning abstract syntax, the analogue of Prolog's read/1,
and a way of compiling from abstract syntax analogous to Prolog's
assert/1. That is, you need an open compiler, like the one in the
latest version of SML/NJ. This is the short answer.

The longer answer is that I've never seen or written myself more
obscure and buggy programs than those that manipulate Prolog terms
intended to represent Prolog programs. The promiscuous use of unbound
logical variables to represent program variables leads to complicated
case analysis using var/1 and cut, and to the danger of accidentally
binding those variables. Even the trivial problem of translating DCG
rules to Prolog has several of those pitfalls, and almost all such
translators are or have been buggy. Some of the most clever but most
obnoxiously unmaintainable parts of Prolog compilers I have seen
involve taking advantage of variable promiscuity to propagate variable
occurrence information. And so on. 

Sure, the identification of terms and programs is seductive, and leads
to very concise hacks. But it leads to unmaintainable, unsafe code.

And now for a final heresy. I've written lots of Prolog, and lots of
C. Writing the Prolog code has often been more gratifying, because
something is up and running much sooner. But the C programs tend to
have far fewer runtime bugs once they compile and link, because even
the lame C type system catches many type bugs that Prolog lets by.





--
Fernando Pereira
2D-447, AT&T Bell Laboratories
600 Mountain Ave, PO Box 636
Murray Hill, NJ 07974-0636
pereira@research.att.com
