Some time ago there was a raging debate over the virtues of Tcl vs. Scheme
as an extension/scripting language. Unfortunately I did not capture the
major pros/cons at that time. Could someone send me a synopsys of the major points?

What about a comparison of Perl to Scheme?

Any help would be appreciated,

You can't defend the indefensible -- Scheme is a terrible choice.  The most
important thing about a extension/scripting language is that it be
-simple-.  It must have a simple easy-to-understand semantics, it must have
simple easy-to-use data structures, and it must have simple easy-to-read
syntax.  Scheme has none of these, while Tcl and Perl have them all.  Let's
take these aspects of simplicity one at a time:

Semantics.  Tcl and Perl are based on string substitution.  What could be
simpler?  Scheme has closures and continuations.  Even graduate students at
MIT are confused by that stuff.

Data structures.  Tcl and Perl have strings.  And basically, that's -all-
they have.  But strings are universal -- you can represent anything using
strings.  And strings are simple.  Heck, if everything is a string, you
don't even need a garbage collector!  Furthermore, everything else in a
modern computer is based on tools that consume and produce strings, so Tcl
and Perl fit right in.  Scheme doesn't even have a foreign function
interface, so you can't glue a Scheme program together with -anything-.

Syntax.  We all learned infix syntax in grade school.  `x + 2*y' is
concise, familiar and easy-to-read.  In Scheme you have to write
`(+ x (* 2 y))'.  Only an idiot would prefer to write that.

Dear Joe,

I think the CAD Framework Initiative should stick to Scheme.
There are many reasons.  Here are some of the more important ones:

1. It is already a international (IEEE) and national (ANSI) standard.

2. It is also used by the ISO DSSSL standard (Document Style and Semantics
Specification Language), which is adds programmability to SGML, the language
used for the World Wide Web.  (HTML is an SGML application.)

3. Scheme has been chosen for to be the basis for the GNU extension language,
GUILE.

4. There are many Scheme implementations, for every operating system.  Many of
these are free.  Similarly, there are a variety of different kinds of implementations,
suitable for different jobs, from small, embeddable interpreters to native code compilers.

5. Scheme is well documented and understood.  Becuase of its widespread use
in Computer Science education, there are many excellent textbooks.

6. Scheme is very flexible and adaptable. It is no accident that Scheme (and other Lisp
dialects) are so often used for prototyping new programming langauges and paradigms.
Object-oriented programming, rule-based programming, logic programming, data flow programming,
and constraint programming can all be done in Scheme, and have been done in Scheme.
Presumably, many of these programming techniques will be useful in the context of
computer-aided drafting.

To sum up, Scheme is a safe, conversative choice for a *standard* extension language.
It is not new or fashionable, but then new languages are not ripe for standardization.
It may not be perfect, or everyone's ideal language, but there is no question about
it being suitable and appropriate.  

Tom Gordon

Perl is my language of choice for systems work as it has nearly every system
call I use, plus lots of bells and whistles.  To me, that's its strongest
feature.  Another reason others use it is that there is quite a large, active
user-base for it (compare traffic on the comp.lang.perl.* with
comp.lang.scheme).  I personally don't think it's any panacea, but it gets
the job done w/o a lot of fuss (although Perl5 looks pretty overloaded with
features to me).

Tcl/Tk is nice because it is so tiny (like Scheme), but it has (IMO) an
annoying set of syntax rules (or rather, lack thereof).  I usually use Tcl/tk
to actually build a GUI, then Tcl or Perl to do the guts of my applications.

However, I would like to recall the discussion to Joe Mueller's
original question.  Remember, he's asked about Scheme vs. Perl
vs. Tcl for the purposes of an embedded extension language.  That's
in fact a very different question!  Off-hand, I wouldn't be
surprised if some of the things that Steven likes (and I like!)
about perl as a scripting language would not be appropriate for an
extension language...

Also, I would implore the group not to get lost in arguments about
infix vs. prefix syntax!  It's just a rewrite away!  Prefix can
easily become infix!

|   Syntax.  We all learned infix syntax in grade school.  `x + 2*y' is
|   concise, familiar and easy-to-read.  In Scheme you have to write
|   `(+ x (* 2 y))'.  Only an idiot would prefer to write that.

I'm surprised that those who argue against Scheme only use computers to do
arithmetic exercises from grade school.  that is such a lame criticism that
I wonder about the mental capacity with which those who make such arguments
must be endowed.

seriously, prefix syntax for heavy arithmetic is known to be a pain, but
it's always interesting to see how people compare prefix, infix and postfix
syntax.  Eyvind Ness of the OECD Halden Reactor Project showed me that it's
much more effective to show them with multiple arguments:

    postfix:    j k l m n + + + +
    infix:      j + k + l + m + n
    prefix:     (+ j k l m n)

infix and postfix are restricted to binary operators, whereas prefix can be
n-ary for an arbitrarily large n.  code becomes cleaner when this is used,
and is thus easier to debug.  this becomes more pronounced with more
complex arguments, of course.

|   Semantics.  Tcl and Perl are based on string substitution.  What could
|   be simpler?  Scheme has closures and continuations.  Even graduate
|   students at MIT are confused by that stuff.

this is like saying that Microsoft Word is as easy as clicking on menus and
"what you see is all you get", compared to LaTeX where it's so hard to
write new styles that only a handful of people worldwide can hack it.

you'll do great in marketing, Alan.

folks, you should look at the intellectual honesty of the critics of the
various suggested languages.  beware of those who criticize something for
being more powerful than you need the first few weeks of using it.  if a
language can be exhaustively learned in, say, 21 days, worry about the
_upper_ limit to what you can do in that language.  ease of learning comes
at the cost of pain in non-trivial use.  that doesn't mean that that which
is hard to learn is necessarily any less painful at non-trivial problems.

While I do consider the adjective "baroque" to be a compliment, I must
point out that Perl is actually more of a romantic piece, with allusions
to various classical motifs.  My favorite composer is Mahler, which should
surprise no one.

I would imagine that Perl packs too much extra baggage for a CAD
extension language.  Perl has many powerful features specialized for
manipulating streams of data and performing system related
operations.  Are these features important for a CAD extension
language?  Also, unless one is very familiar with Perl, the sheer
abundance of features and tricks can be confusing.  For instance, the
context dependent semantics and the various special characters makes
me uncomfortable.  I must say though, once you've got the hang of it,
Perl is very handy for certain types of programming.

Tcl has many cleanly engineered low level C routines (I use the
hashtables frequently), but suffers from a few drawbacks as a high
level language.  All the upvar and global/local stuff seems a little
too adhoc to me.  Also, Tcl is slow because of all that string
conversions coupled with numerous hashtable lookup for everything.  If
the goal is to provide a high level command-line interface to
low-level code within your CAD program, then Tcl would be okay; but,
if you want to expose CAD specific structures (like netlists) to a
high level language for interactive processing, then Tcl would not be
high on my list of languages.

Scheme seems like a very good choice -- minimal scheme is lightweight
and not tailored for any specific purposes so you can customize scheme
for a specific purpose without any extra baggage.  Also, in my
opinion, scheme is elegant, expressive, and fun.

I think the choice of languages will be decreasingly important in the
future with the emergence of language neutral tools like ILU form PARC
Xerox, Guile from FSF, and the JavaVM from Sun.  Perhaps your group
can concentrate on building a scheme interface to ILU or get involved
with Guile or Java and resolve the language problem by looking towards
the future.

    JM> Tcl, and Perl as extension/scripting languages to (hopefully)
    JM> better defend the choice of Scheme....

Alan Bawden (AB) replies:
    AB> You can't defend the indefensible -- Scheme is a terrible
    AB> choice.  The most important thing about a extension/scripting
    AB> language is that it be -simple-.  It must have a simple
    AB> easy-to-understand semantics, it must have simple easy-to-use
    AB> data structures, and it must have simple easy-to-read syntax.
    AB> Scheme has none of these, while Tcl and Perl have them all.

Well, I disagree here.  Scheme, too, is simple and elegant, has very
straight forward and consistent semantics, is structure on the concept
of simple pairs as the main data structure, and is easy too read
after one takes time to learn it.

    AB> Let's take these aspects of simplicity one at a time:

    AB> Semantics.  Tcl and Perl are based on string substitution.
    AB> What could be simpler?  Scheme has closures and continuations.

Hmm, when I'm on a Mac or PC many of the strings are mapped
differently than on a Unix system.  String subsitiution often gives me
grief when I'm trying to perform tasks on different platforms.  So I
guess string substitution is not so simple for me.  I find closures
and continuations easier to handle.

    AB> Even graduate students at MIT are confused by that stuff.

I know/knew undergraduate and even highschool students who understood
these "confusing" ideas, what's the point of this argument?  Some
people get it, some people don't.  Are you saying that scheme is
inherently harder to learn?

    AB> Data structures.  Tcl and Perl have strings.  And basically,

I think Perl has scalars, arrays of scalars, and associative arrays of
scalars where scalars can be a string, a number, and a reference which
are internally represented in a efficient manner (i.e. not as strings).

    AB> that's -all- they have.  But strings are universal -- you can
    AB> represent anything using strings.  And strings are simple.

Same with ones and zeros.  Strings are representations of ones and
zeros that most humans find easy to work with.  However, they are not
efficient as far as the computer is concern (waste lots of space and
computational cycles to process).  Why not let the computer work
efficiently and only resort to strings when they have to communicate
with the user?  Why not use structures that encompass strings?  A CAD
program may have lists that contain millions of nodes, should I use
'NODE1' 'NODE2' ... 'NODE1000000' to enumerate all my nodes?

    AB> Heck, if everything is a string, you don't even need a garbage
    AB> collector!  Furthermore, everything else in a modern computer

Can you explain this to me?  How does using only strings eliminate the
need for a garbage collector?  I'll have to think about this one.

    AB> is based on tools that consume and produce strings, so Tcl and
    AB> Perl fit right in.  Scheme doesn't even have a foreign

Isn't most of the text-base tools from the last generation?  I thought
serialization/marshalling/pickeling or whatever it's call is the new
way of interprocess/interobject sharing of data.  Also, isn't HTTP-NG
trying to move away form a text-based protocal for WWW (the most
recent example of a text-base protocal).

    AB> function interface, so you can't glue a Scheme program
    AB> together with -anything-.

I think Elk 2.2, Guile, Libscheme, SIOD all have FFIs.  I'm hard press
to think of a publically available scheme that does not have an FFI.

    AB> Syntax.  We all learned infix syntax in grade school.  `x +
    AB> 2*y' is concise, familiar and easy-to-read.  In Scheme you
    AB> have to write `(+ x (* 2 y))'.  Only an idiot would prefer to
    AB> write that.

Hey, I'm an idiot then.  I learned 'x + 2 * y' in grade shcool,
'y 2 * x +' in college, and '(+ x (* 2 y))' in graduate school.  What
are my teachers doing to me!  Turning me into an idjit!?

-- Chak Tan

This is a false comparison of prefix vs. postfix-- it really has to do using parentheses for
grouping.   With parentheses for grouping, postfix is as concise as prefix:

       postfix: (j k l m n +)
       prefix:  (+ j k l m n)

Without parentheses for grouping, prefix is as verbose as postfix:

       postfix: j k l m n + + + +
       prefix:  + + + + j k l m n

In each case, without parentheses, you have to fix an arity for the operator; with parentheses,
they can have variable arity.

This is correct.  Perl also has closures, though not continuations.

To be sure, Mahler's work is brilliant in concept and construction, but
there is a high cost in execution.  OTOH, there are others equal in
brilliance but more accessible.  (oh dear, the metaphor is breaking down)

Speaking to the original question, for suitability as an embedded language,
I'd have to go with Scheme.  The overhead of the language is low and the
structure is rich.

Also, this is more syntax than semantics.  And you've hit upon a
central issue, because a lot of people's /perception/ of simplicity
comes from syntax rather than semantics.  And, it turns out, some
people are a lot more comfortable with strings and others are a lot
more comfortable with parenthesized lists.  

All three languages have a small set fundamental types.

But I really think you should learn Perl before spouting off about it
like this.  Perl does not represent everything as strings.

Back to simple data structures;  Scheme (like Lisp) has the ordered pair
as a fundamental type and all data structures are built from this.  It is
a very simple concept that lets you build anything you want.  My experience
with Lisp in college was that the typical student learned to build complex
data structures and abstract types much more quickly with Lisp than with
C/Pascal.  Also people tend to use abstraction more effectively with Lisp,
especially in small programs (such as you would write a lot in an extension
language) because it is simpler (and less verbose) to do so.

Not that I have a problem with infix on the level of `x + 2*y', but
when you're talking about all the types of expressions you typically
find in a programming language, most people can't seem to remember all
the precedence rules.  Look at some random source code... a lot of
expressions are over-parenthesized because the author wasn't sure of
precedence and rather than wasting time looking it up played it safe.
Sure, you can do that and never bother learning the precedence rules,
but if you're parenthesizing everything anyway, where's the difference
from Lisp?

In any case, syntax is a lot more than the form of arithmetic
expressions.  Scheme's syntax is arguably the simplest possible:
everything is a parenthesized list, there are no special cases, no
exceptions, no precendence rules.  What could be simpler?  ;-)

[Jurgen Botz]

|   Back to simple data structures; Scheme (like Lisp) has the ordered pair
|   as a fundamental type and all data structures are built from this.

the vector is also a fundamental type, and may be more useful for building
data structures than lists.  many new Lisp and Scheme programmers tend to
think of the list as the only fundamental type, often causing slow code.

Sorry, but it seemed obvious to me he was kidding (even though I don't know him
at all. Of course the lcs.mit.edu was a confirmation): the arguments were so
"true" (I really enjoyed the "even graduates get confused") !

Thanks Alan,

Nope. A scheme hater wouldn't talk about "easy-to-understand semantics", he
wouldn't know continuations exist and finally wouldn't be able to tell the
difference between a language and an implementation (which rules out the "scheme
doesn't even have an FFI"). The post was to well informed to be from some idiot
believing the Tcl or Perl is simple !

   Choose an implementation.  For example, Guile.  Gosh, it's got two
   foreign function interfaces, one compatible with Tcl's.

We've been through this.  Guile is *not* Scheme.  It may be based on
Scheme, but don't call it Scheme!  (Otherwise I will no longer say I
like Scheme.. :)

   > Syntax.  We all learned infix syntax in grade school.  `x + 2*y' is
   > concise, familiar and easy-to-read.  In Scheme you have to write `(+
   > x (* 2 y))'.  Only an idiot would prefer to write that.

   Or rather [expr $x+2*$y].  But yes, it's still better.  But Guile has
   (or will have RSN) a C-like syntax, translated automatically to Scheme.

Yikes!

   |   Syntax.  We all learned infix syntax in grade school.  `x + 2*y' is
   |   concise, familiar and easy-to-read.  In Scheme you have to write
   |   `(+ x (* 2 y))'.  Only an idiot would prefer to write that.

   I'm surprised that those who argue against Scheme only use computers to do
   arithmetic exercises from grade school.  that is such a lame criticism that
   I wonder about the mental capacity with which those who make such arguments
   must be endowed.

Are you guys blind?!  Didn't you see all the smileys (or frownies) in
Alan's article?!  Knowing Alan's background and the extend of his
contributions to Scheme I can't imagine him advocating _Tcl_ (for
crying out loud!) over Scheme.  He may have his gripes with the current
state of affairs in Scheme (and rightfully so), but still...

   folks, you should look at the intellectual honesty of the critics of the
   various suggested languages.

Erik, DON'T accuse Alan Bawden of intellectual dishonesty, please!

|   Are you guys blind?!  Didn't you see all the smileys (or frownies) in
|   Alan's article?!  Knowing Alan's background and the extend of his
|   contributions to Scheme I can't imagine him advocating _Tcl_ (for
|   crying out loud!) over Scheme.

right.  that's what I said in a followup, as well: you have to know Alan's
background and the extent of his contributions to Scheme to understand that
he was joking.

of course, it's embarrassing to fail to understand very good inside jokes,
but I find some consolation in the fact that more people than I got worked
up over his article.  he _did_ give an exceedingly good impression of a
Scheme hater.  but now we'll think that rabid Scheme haters are only
joking, and I think that's going to cause those who don't know the Scheme
community sufficiently well to know that Alan's was a joke and the others
aren't to hold back their comments, leading to more people actually
believing that Scheme's crap.

I think it's important that people reacted to Alan's article.  at least we
have managed to communicate to all of us on the fringes of the community
that we have some darn clever folks in the center of said community, and
that those almost-but-not-quite-absurd criticisms of Scheme weren't real.

sorry for being such a spoilsport, but this is the first time I think I had
a right not to "get" some joke.  it was too clever for its own good.  OK,
so I didn't pass the secret rites of entry to the community.  maybe later.

Damn -- Erik blew my cover!  I guess I shouldn't have admitted to him in
private that I was kidding around.

Actually, several people I have never met indicated that they understood
what I was up to:  I figured that if we were going to have to sit through
the stupid Scheme-vs-Tcl discussion for the tenth time, this time I'd see
what it was like to be on the other side, and perhaps I could push the
discussion someplace amusing.

The people who pointed out that I didn't know anything about Perl are
probably correct.

   Alan Bawden should consider the cartoon business.  He could really
   give Scott Adams some competition!  

High praise indeed.  Thanks, man, that's the best
endorsement I've received all year!