From: Josh Marantz
Subject: Scheme as a standard extension language
Date:
Message-ID: <1486@viewlog.UUCP>
I'm on a subcommittee of the CAD Framework Initiative (CFI), and we're
working to standardize on a specific standard extension language for
Electrical CAD/CAE applications.
The mission of CFI is "To develop world-wide industry acceptable
guidelines for design automation frameworks which will enable the
coexistence and cooperation of a variety of tools."
The goal of the working group on extension languages is to provide
integrators and users of multi-vendor systems a single extension
language that will work with all their applications.
The obvious analogy is that different flavors of Emacs have compatible
user interfaces and philosophies, but totally incompatible extension
languages (EEL, Mocklisp, Elisp, Teco...). Wouldn't it be nice if
they standardized?
Whether or not you agree with this premise, we are trying to come up
with a standard language (for some definition of "standard") that meets
various criteria. The criteria include:
High Productivity (implies high level language)
Good development environment
Automatic memory management (garbage collection)
Specific runtime call to reclaim memory (collect garbage)
Easy construction of complex data structures
Easy manipulation of strings, lists, and complex data structures
Quick turn around of code changes
Rapid prototyping
Built in debugging capability
Public domain source and commercial products available
Easy to parse EDIF using extension language
Late binding
Dynamic binding
Able to express rules and constraints
Able to construct module generator (to generate cells)
Sequential model of execution (stream i/o)
Standard language with a large user base
Multiple namespaces (packages)
Access to all other parts of framework from extension language
We could try to invent our own language that meets these requirements, but
leveraging off an existing standard is a high priority for us.
The two languages that we've come up with that come closest to meeting
these requirements are Common Lisp and Scheme. Common Lisp is
feature-rich and requires the fewest extensions to provide the
features we need. But it is huge and thereby dictates certain
architectural considerations and platform requirements where it would
be nice to remain more flexible. In particular, it may be desirable
to have several applications running on a workstation, each of which
has its own extension language processor linked in. Correct me if I'm
wrong, but if the extension language is 2 Meg worth of Common Lisp,
then this would not be a design option. My understanding is that
shared libraries might ease the problem, but would not eliminate it.
However, standard Common Lisp (with CLOS and the Pittman error
handler) provide us a nearly complete package that we wouldn't have to
augment. The useful features it provides that Scheme doesn't include:
structure definition (defstruct), error handling, an object/class
system, hash tables, optional strong typing, looping constructs, and
efficient compilation.
Scheme is more elegant and streamlined, but would require a large
number of extensions to supply all the features we need. I couldn't
find many of the required features in R3RS, but I've seen them in
various implementations of Scheme. For example:
Packages MIT-Scheme
Debugging Support MIT-Scheme
Object Oriented Programming XScheme
Simple integration with C Code SIOD
I personally support Scheme as the basis for an extension language,
primarily because it can be implemented without a big memory hit (as was
done with SIOD). It seems to me that even with the extensions we need,
Scheme would still be leaner than Common Lisp. For example, packages and
an object/class system can be trivially implemented with environments.
But what I need to present my case better is some sort of "common"
extension package that can provide the features we require. Is there
an effort out there to define extensions and enhancements that I could
present along with R3RS to the committee? Or should I try to come up
with a "Scheme's greatest hits" collection and suggest that we
standardize on those extensions as well as R3RS?
Any comments from the Scheme and Lisp communities are welcome. If
Common Lisp is not as expensive as I assume, then I'm sure someone
will correct me!
--
Joshua Marantz
Viewlogic Systems, Inc.
···················@bu-cs.bu.edu
It sounds like you're saying that you prefer Scheme to Common Lisp
because Scheme is "smaller", but Scheme is missing things that you
need, so you'll have to extend it. Well, if you think about it, this
shows why Common Lisp is the size that it is: it contains a whole lot
of stuff that people have needed from time to time. Once you put in
all the extensions to Scheme that you'll find you want to have, the
difference in size will not be as great.
When people talk about the "size of Common Lisp", whether they be
measuring the size of executable files or the reference manual, they
are really talking about the language plus a huge library of functions
that are useful to some people some of the time.
It is possible to construct a Common Lisp implementation in which an
executable doesn't pay for the parts of the library that it doesn't
use. I have heard that various Lisp implementors, such as Lucid and
Franz and possibly others, have done work in this area, but I don't
know any of the details. The decision of a standard extension
language for the CFI is important. If you really want to find out the
lowdown on this whole topic, I strongly recommend you talk to the
experienced, professional Lisp implementors at such companies, and
see what they can tell you. Of course, there are also experienced
Scheme implementors around, too, who you might want to talk to.
Of course, if you're considering an extended Scheme, you could equally
well consider a subset of Common Lisp.
Despite my role in defining Common Lisp, I do agree that Scheme has
advantages. Its main advantage is that it's more internally clean and
simple; Common Lisp was required to maintain all kinds of
compatibility with older Lisp dialects, whereas the Scheme designers
started from a tabula rasa and worked hard on elegance and simplicity.
The only counterbalancing argument might be that Common Lisp is
becoming more of a "standard", although Scheme is also something of a
standard in its own right; I'm not sure how much this matters in the
CFI decision.
From: Cris Perdue
Subject: Re: Scheme as a standard extension language
Date:
Message-ID: <131091@sun.Eng.Sun.COM>
Dan,
It is possible in principle to make small Common Lisp applications by
using just part of the language, but there is a problem. Common Lisp
defines no layers, so it is impossible to decide which parts of the
language can be avoided to reduce the size of an application. I
believe that most implementations are rather intertwined: support for
one language feature tends to rely on more of the rest of the language
than one might imagine. Many of these dependencies can be eliminated
if need be, and if we know which ones to eliminate.
One big advantage of Scheme is that the base language is such a layer.
Also, when one uses a language plus a set of libraries, it is usually
possible to find out the dependencies among the libraries and to find
out what features require large amounts of runtime support.
This is in addition to the benefits Scheme provides by not carrying
around a lot of features for backward compatibility. The
implementations become smaller and the language becomes intellectually
simpler and cleaner.