Newsgroups: gnu.misc.discuss,comp.lang.tcl,comp.lang.scheme,comp.lang.misc
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!news.mathworks.com!europa.eng.gtefsd.com!howland.reston.ans.net!news.sprintlink.net!malgudi.oar.net!chemabs!lwv26
From: lvirden@cas.org
Subject: Re: GNU Extension Language Plans
Content-Type: text/plain; charset=US-ASCII
Message-ID: <1994Oct22.234115.19088@chemabs.uucp>
Sender: lwv26@chemabs.uucp (Larry W. Virden)
Reply-To: lvirden@cas.org
Content-Transfer-Encoding: 7BIT
Organization: Nedriv Software and Shoe Shiners, Uninc.
References: <id.SA0E1.O_H@nmti.com> <y53Juc1w165w@sytex.com>
Mime-Version: 1.0
Date: Sat, 22 Oct 1994 23:41:15 GMT
Lines: 67
Xref: glinda.oz.cs.cmu.edu gnu.misc.discuss:19086 comp.lang.tcl:20758 comp.lang.scheme:10524 comp.lang.misc:18322


In article <y53Juc1w165w@sytex.com>, Scott McLoughlin <smcl@sytex.com> wrote:
:peter@nmti.com (Peter da Silva) writes:
:
:> I still think that all other things being equal a tighter, smaller language
:> is better than a larger and more complicated one, and all the enhancements
:> to Scheme suggested by RMS in <9410190420.AA02904@mole.gnu.ai.mit.edu> are
:> a bit worrisome. If this comes down to a fight between Sun and the FSF my
:

:        I don't, OTOH, see why not we couldn't just have a simple
:#ifdef compilation option to exclude various features from the 

Having to compile up multiple copies of interpreters has been tried in the
perl and tcl communities - to the frustrations of many.  What I and many
others have called for are ways to dynamically load independantly developed
sets of enriched command sets into a very small base interpreter.  This 
would allow me to tailor an application to a required set of objects
and appropriate operations/methods, while passing on pieces for which I have
no need.  Why should my applications be saddled with hundreds of k of X
overhead if the app I want to develop just wants to send messages to an
existing X app - but needs to do no window instantiation at all?  Equally,
if all I need to do is small integer manipulation, I would just as soon
not be saddled with bignum floats.  On the other hand, if a user wishes
to write their own extended commands for my app, and in doing so determines
that _they_ need bignum floats, X, or whatever, I would like for the language
to be able to support _them_ requesting said objects be loaded, along with
appropriate operation/method library code, etc.

:language, e.g. #undef GXL_UNIXCALLS or whatever. Same for "expect"
:interface (what is expect anyway?).

Expect is a nifty concept (available at least in a Tcl and Perl form -
perhaps in other languages now as well) where one defines a set of
interactions that need to take place one or more processes.  Think of
telecomm software in the micro world which allow you to capture login
scripts and then replay them to log into services, etc.  Expect is 
a language where one can write 'scripts' to invoke ftp, telnet, etc.
and then generate requests, watch for respones, etc.  The latest Expect,
with an extended environment known as Expectk, allows one to wrap aaGUI
around a traditional text based interaction such as ftp, password changes,
whatever, in a rather nifty way.  There is also a neat paper done able
a feature of Expect called Kibitz - where one links two separate programs
together with expect/kibitz glue between - so that one program feeds input
to another and then recieves the second's output as it's input (think 
of playing two chess programs against one another - not that this is
the only use, but a simple to grasp one).

:        I would guess in the general case, the lion's share of apps
:using the language will have oodles of giant GUI extensions, user
:i/o validation, etc. and one average size 8bit+ color image will have
:a footprint bigger than the whole language implementation anyway! For
:real tightness and power in a scripting language, I (and many others)
:would recommend using "Forth" where these things matter - but I

It is true that many apps will be extended using many pieces of 
extensions.  If they are all loaded only when needed, and able to be
unloaded when not needed, this would allow an app to consume only the
resources needed at any one time.  And if folk take into consideration
the 'hypertool' or applet approach, where entire mini-applications grow
up and communicate between one another, then one will find that more
use of distributed compute resouces, threading, etc. will be utilized.
-- 
:s Great net resources sought...
:s Larry W. Virden                 INET: lvirden@cas.org
:s <URL:http://www.mps.ohio-state.edu/cgi-bin/hpp?lvirden_sig.html>
The task of an educator should be to irrigate the desert not clear the forest.
