🚀 go-pugleaf

In article <398tet$9lp@csnews.cs.Colorado.EDU>,
Tom Christiansen  <tchrist@mox.perl.com> wrote:

>:-> In comp.lang.misc, jbotz@mtholyoke.edu (Jurgen Botz) writes:
>:Tom, much as RMS comes across as dogmatic and his message is always at
>:least partly political, I've yet to seem him trying to force anyone to
>:do anything.  

> A significant challenge will be for the
>FSF to implement this great extension language and then provide a generic
>API so that people building things don't HAVE to use it, so that they
>could in fact, if they desired, used tcl or ksh or rexx or whatever.  If
>they don't do that, then it does seem to me that they've fallen into the
>same ticklish trap that rms was complaining about: taking away choice by
>locking in the extension language to the app.

This is a good point.  However, how would this work?  It sounds as if Tom is
propsing that the generic API go through C (or some lower level like that)
rather then through the Scheme-like CL that GNU is proposing people write
translators for to use their favorite extension langauge.

The problem seems to me that there are many languages that all work well as
extension langauges.  I think that lisp works well for Emacs, but I embed Tcl
in my apps.

Perhaps below the Scheme-like level of GNUel, there should be a low level
interface that other extension languages could compile/translate to.  The goal
would be to eliminate speed problems of translations to scheme, and still
mantain a universal extension language interface that extension language
developers can easily translate to.
-- 
 -- Bradley M. Kuhn                                              Loyola College
     URL:   http://www.loyola.edu/homes/bkuhn
     EMAIL: bkuhn@cs.loyola.edu, bkuhn@loyola.edu