[no subject]

[postmaster@att-in.att.com]

Mail to `att.att.com!attmail!mhs!envoy!ics.test/pn=_test_group' alias `att!attmail!mhs!envoy!ics.test/pn=_test_group' from 'CUNYVM.CUNY.EDU!Scheme%lcs.mit.edu' failed.
The error message was:
destination unknown or forwarding disallowed
The message began:
Received: from SCF.FUNDP.AC.BE by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 4525; Fri, 26 Jan 90 12:59:37 EST
Received: by BNANDP11 (Mailer R2.02A) id 5839; Fri, 26 Jan 90 16:38:36 +0100
Date:         Fri, 26 Jan 90 02:42:30 EST
Reply-To:     Scheme%lcs.mit.edu@CUNYVM.CUNY.EDU
Sender:       Scheme Programming Language <SCHEME%BNANDP11.BITNET@CUNYVM.CUNY.EDU>
From:         Automatic Scheme Digestifier <Scheme-Request%LCS.MIT.EDU@CUNYVM.CUNY.EDU>
Subject:      Scheme Digest #282
Comments: To: Scheme@lcs.mit.edu
To:           ICSUG TEST GROUP
              <attmail!mhs!envoy!ICS.TEST/PN=_TEST_GROUP@ATT.ATT.COM>

Scheme Digest #282                             26 Jan 90  02:42:30 EST

Today's Topics:

        Scheme as a standard extension language

----------------------------------------------------------------------

Message-ID: <1486@viewlog.UUCP>
Date: 24 Jan 90 23:13:30 GMT
From: Josh Marantz
 <zaphod.mps.ohio-state.edu!usc!apple!netcom!stratus!cloud9!viewlog!josh@think.c
 om>
To: scheme@mc.lcs.mit.edu
Subject: Scheme as a standard extension language

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.
cloud9!viewlog!josh@bu-cs.bu.edu

------------------------------

End of Scheme Digest
********************