Newsgroups: comp.lang.scheme
Path: cantaloupe.srv.cs.cmu.edu!rochester!udel!news.mathworks.com!uunet!in1.uu.net!nntp.cadence.com!news
From: Edwin Petrus <esp>
Subject: Re: Extension/Scripting language comparisons
Content-Type: text/plain; charset=us-ascii
Message-ID: <DBILpt.CtJ@Cadence.COM>
To: esp
Sender: news@Cadence.COM
Content-Transfer-Encoding: 7bit
Organization: Cadence Design System, Inc.
References: <3thlus$isi@hpbab.wv> <ALAN.95Jul7023601@parsley.lcs.mit.edu>
Mime-Version: 1.0
Date: Mon, 10 Jul 1995 19:20:16 GMT
X-Mailer: Mozilla 1.1N (X11; I; SunOS 5.4 sun4m)
X-Url: news:ALAN.95Jul7023601@parsley.lcs.mit.edu
Lines: 77

"Scipting" and "Extension" should be seperated for the purposes of discussing
extension language merits for CFI.

I don't know when "scripting" blurs into "extension" but in most cases
where a CAD extension language is deployed, users tend to write large
programs that exercise the depth and breadth of the tools Framework
visible through the language. It is common to see software 
packages consisting of tens of thousands of lines of code written 
in an extension language (el).

Here are some requirements I would set out for a CAD extension
language (a dynamic and machine architecture independent language is assumed ) :

1. Scalable
	For large sized software projects, it is important 
	for the el deployed to be scalable. The language must 
	be rich in semantics both for expressing data and control.
	e.g. can it present a comprehensible view of an object oriented 
	database model? Event driven GUIs? Synchronous and 
	asynchronous networking?

2. Small.  
	Realize the core implementation in 250-500K size library 

3. Extensible
	Two levels: foreign function interface & meta-programming.
	the second is critical for implementing command languages
	to drive tools and specialized languages (e.g. test pattern generators,
	procedural database objects)

4. Portable
	Should not have dependencies on specific operating system features.
	i.e. it should be portable to unix, windows, os2, mac, etc. 

6. Public, standard, available, familiar.

These are some requirements I know of. I also know that to try and choose
one language that best fits the requirements will make many people happy and will
leave many others unsatisfied (hence, why we are talking about a CFI el again -
the matter was settled five years ago). 

This is a basic problem. How can you accommodate the person who is likely 
to write 50K lines of code and at the same time make the 50 lines script 
writer productive; or make the ones who are inseperable form their favourite 
language of the day happy (e.g. perl, tcl, python, scheme, smalltalk, visual
basic). 

I can at least say the answer is not academic. Syntax is a secondary issue.
Foreign function interfaces can be added to any language implementation.

Scheme gives a Framework a powerful, scalable, portable an extensible
foundation. It is easy to start with a very small raw implementation. If 
the implementaion is designed well, many other dynamic languages can
be targeted to the same implementation. The tcl follower need not be deprived
(see architecture of GUILE). 

The goal for CFI should be to declare a common language that 
can meet the above requirements. Users (customers) can vote with 
their money for the vendor that best satifies their needs - for extension
and scripting. That is, customer satisfaction is a marketing problem.
For example, A design outfit that relies heavily on, say perl, can
favor the CAD supplier with perl access. Likewise for tcl and others.

It is crucial for CFI to satisfy the technical requirements for
inter-operability. This goal must not be blurred by issues surrounding the
favourite language of the day. Successful vendors will leverage the CFI decision
to satisfy their cusotmers' needs in the areas of tools and Frameworks
extensibility. 

-----------------------------------------------------------------------
Edwin S. Petrus
Sr. Engineering Manager,
Cadence Design Systems, Inc.

esp@cadence.com
408-985-4271

