Newsgroups: comp.lang.misc,comp.lang.scheme,comp.lang.tcl,comp.os.linux.misc
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!news.mathworks.com!udel!gatech!rutgers!att-out!nntpa!nntpa.cb.att.com!lgm
From: lgm@polaris.ih.att.com (Lawrence G. Mayka)
Subject: Re: GNU Extension Language Plans
In-Reply-To: davidm@prism.kla.com's message of 25 Oct 1994 02:32:29 GMT
Message-ID: <LGM.94Nov20184218@polaris.ih.att.com>
Sender: news@nntpa.cb.att.com (Netnews Administration)
Nntp-Posting-Host: polaris.ih.att.com
Organization: AT&T Bell Laboratories, Naperville, Illinois, USA
References: <9410190420.AA02904@mole.gnu.ai.mit.edu>
	<MULLER.94Oct20134800@panoramix.simulog.fr>
	<388u56$1gh@agate.berkeley.edu> <id.YD1E1.VHK@nmti.com>
	<BRUCE.94Oct24161921@iasc3.scm.liv.ac.uk>
	<DAVIDM.94Oct24193229@halfdome.prism.kla.com>
Date: Mon, 21 Nov 1994 00:42:18 GMT
Lines: 42
Xref: glinda.oz.cs.cmu.edu comp.lang.misc:19247 comp.lang.scheme:11386 comp.lang.tcl:22056 comp.os.linux.misc:33837

In article <DAVIDM.94Oct24193229@halfdome.prism.kla.com> davidm@prism.kla.com (David S. Masterson) writes:

   Doesn't this argue for not embedding *any* extension language in a program but
   instead defining a request/reply API that programs must conform to?  Isn't
   this the model that C uses (ie. think of functions as a request to something
   for service).  Then, any language that handles the API can be an extension
   language.

   Think performance might be a problem?  Short-circuit the request code to look
   in the local services list to see if the request could be handled locally.
   Afraid of programs that *might* build in a specific language?  Who cares!  As
   long as it supports the API, I'll start up my language processor that makes
   requests according to the API and bypass the in-built language.

Having faced and fought this "solution" only too often, I can say that
it has two fatal flaws.  One is data.  An API must certainly pass data
back and forth; indeed, often, internal state (i.e., data) is
precisely what the API is principally concerned with.  (Many "APIs"
I've dealt with are merely collections of 'set' and 'get' routines,
which don't fool anybody.)  Once you recognize the need for data, you
must define datatypes and their behavior, means of constructing new
datatypes which may inherit behavior from previous ones, etc.  You may
have to pass executable data (i.e., functions) across the API.  What
do you have?  A programming language, of course!  You may as well
realize right away that you are defining a programming language, and
make it a powerful, extensible, consistent one.

But, you might say, we can just use C for our APIs.  That is merely a
least-common-denominator "solution."  You're effectively saying that
we =can't= agree on a powerful, extensible, consistent language, so
let's agree on some bits-and-bytes instead.  That merely begs the
question, because application developers who want to be productive
will simply have to choose a more powerful language for their =real=
work anyway.  Perhaps more importantly, you severely hobble the API by
tightly restricting what it can express--an inadvertently 1984-style
approach to the problem.
--
        Lawrence G. Mayka
        AT&T Bell Laboratories
        lgm@ieain.att.com

Standard disclaimer.
