Religious wars usually start when people are *very* convinced of their
favourite language/system/hardware or whatever gadget. I'd like to
avoid this by starting from the application requirement's point of
view on extension languages.
[1] Interpreted Language
An extension language should support the rapid prototyping of
applications, i.e., it needs to be flexible in various respects. The
success of Tcl/Tk shows that a language which is easy to use (cf. the
good ol' BASIC days), and which provides a full set of operations from
very low-level basics to higher-lever graphics will find user
acceptance because it meets users' needs.
>From this, I infer that we call for an interpreted, not primarily
compiled, language. A copmiler may come handy for performance boosts
once the built system has reached some maturity, but it should be
avoided to compile code (long edit-compile-run cycles inhibit
prototyping).
[2] Dynamic Type System
The data types supported by the extension language should be the
standard data types (integer, floats, strings, characters), plus
sequential lists and hash-indexed arrays of data objects. This is a
direct lesson from several languages.
Especially the hash-indexed arrays are crucial when it comes to
implementing associative structures. Lists are a natural form of
variable-length collections. As Tcl/Tk shows, the syntactic typing of
data objects (which is due to the fact that strings are the only real
data type in Tcl) is insufficient and awkward for many applications,
e.g., when an object-oriented database is interfaced. Explicit type
markers will be necessary, making the handling of such marked data
objects somewhat obscure.
In LISP, every object "knows" its type. This certainly is an approach
which is superior to that of classical compiled languages where it is
impossible to tell what kind of object a pointer actually points to.
In LISP, type casts are meaningless: either you convert the object to
a different type (possibly also changing the semantics), or you have
to stick with the object as is.
A facility similar to that of defstruct/Flavors in LISP would allow
users to introduce their own first-class data types, including object
systems resembling those of any application. This can be implemented
in a few pages of LISP code, so it shouldn't be a problem.
[3] Syntax
Syntax is probably what keeps so many people from using basically
comfortable language environments such as Smalltalk and LISP. I
remember a package called CGOL which basically introduced ALGOL-like
infix notation for LISP. The resulting programs very much looked like
ALGOL or PASCAL programs.
I guess, if we manage to separate syntax from the extension language
implementation, this would be a big win. Of course, some kind of
standard syntax would have to be defined, but an extension language
should be able to significantly change its syntax if needed.
Granted that feature, there isn't really a question of whether the GNU
extension language is Scheme or LISP or Tcl or Python. There would be
a semantics for certain data types, function primitives, and control
structures. That's all. Map that onto your favourite syntax. RMS may
prefer to provide a Scheme-like base system. Others may want to
implement a C-like syntax.
[4] Built-In Features
Tcl by itself is nice but not perfect. I suppose, much of the success
of Tcl is contributed by the availability of Tk. The large user
community facing the problem of having to prototype user interfaces
has been calling for such a system for a long time. Smalltalk had
comparable features but was too difficult to handle and too exotic for
most people.
In my opinion, an extension language should define built-in operations
in the following areas:
- string and pattern manipulation (ever done programming in SNOBOL?);
- file manipulation (this is essential for replacing many shell
and awk/perl scripts);
- invocation of programs and capture of results (this requires some
transparent use of pipe mechanisms);
- inter-process communication (not just bits and bytes, but structured
objects), including an event mechanism.
With the de-facto standard X11/Motif, there is a common user interface
programming API on many platforms. Even PC windowing systems aren't
that different from Motif in their functionality anymore.
This added functionality should be provided as a separate GNU X
toolkit on top of the extension language. Graphical user interfaces
have become as essential for programs as arithmetical operations. In
the case of Tcl/Tk, one isn't really sure if Tcl and Tk are designed
as separate systems or an integrated environment. The separation is
there in some points, at others it isn't.
A tight integration of a visual toolkit will help prototyping
significantly. The integration should be tight because of the need of
a seamless integration with the object system of the extension
language.
[5] Extensions
So how about extending the language? Extensions can be built in one of
three ways:
- programs written in the extension language itself provide new
functionality through a well-defined API (something like a LISP
package system would be useful to keep name spaces separate);
- the dynamic loading of modules provides a way of dynamically
including implementations of defined APIs which are provided by some
compiled-in extension (this may be the preferred way of handling the
GUI extension).
- adding new commands in *some* other language requires the definition
of an interface protocol regarding control flow and data passing (this
is the Tcl model).
The first alternative certainly is the LISP way of doing it. In order
to be of use even for complex extensions, an optimizing compiler must
be available (looking at the KCL/AKCL LISP, you can see how this may
be done by going over a conventional language like C).
The second and third alternative require the rebuilding of the
language interpreter (aka "wish inflation") unless a generic protocol
for the automatic integration of dynamically loaded modules is defined
(e.g., loading a dynamic library could put the resepctive symbols into
a new name space/package, and a special segment in a shared library
could be used to specify the parameter passing conventions of the
exported functions).
-----
To summarize: in my opinion, an extension language should have rapid
application prototyping as its foremost goal. This will facilitate the
prototyping of entire applications as well as the quick writing of
small scripts. Consequently, an interpreted language with dynamic
typing and a user-definable syntax is needed. Some basic non-standard
operations (when compared, e.g., to C or C++) will be required for
string and file manipulation, and for inter-process communication (as
distributed environments become more and more common). The language
should encourage users to write extensions in the extension language
itself, but allow the dynamic linking of code at the same time.
If you ckeck these requirements against Tcl/Tk, you'll notice that
with the exception of the syntax issue, the typing system, and the
extension mechanism, pretty much everything else is there. That's why
Tcl/Tk is successful. However, when it comes to writing serious
applications requiring complex typing (e.g., a project management
system for concurrent engineering, or a product documentation and
information system for mechanical engineering), Tcl/Tk is not suited
well primarily because it is lacking a proper type system. In the
realm of multimedia applications and computer-supported cooperative
work (that's what I'm interested in), communication and information
exchange are important. The simple Tk "send" command certainly doesn't
satisfy those needs.
-----
Well, I hope the above provides some useful ideas for to the ongoing
discussion, as well as a rationale for some features a scripting or
extension language should have.
Greetings,
--Juergen Wagner
Juergen.Wagner@iao.fhg.de
gandalf@csli.stanford.edu
Fraunhofer-Institut fuer Arbeitswirtschaft und Organisation (FhG-IAO)
Nobelstr. 12c Voice: +49-711-970-2013
D-70569 Stuttgart, Germany Fax: +49-711-970-2299
<a href = http://www.iao.fhg.de/Public/leute/jrw-en.html>J. Wagner</a>