Newsgroups: gnu.misc.discuss,comp.lang.tcl,comp.lang.scheme
Path: cantaloupe.srv.cs.cmu.edu!das-news.harvard.edu!news2.near.net!MathWorks.Com!europa.eng.gtefsd.com!howland.reston.ans.net!news.sprintlink.net!uunet!sytex!smcl
From: smcl@sytex.com (Scott McLoughlin)
Subject: Re: Why you should not use Tcl
Message-ID: <09Z0sc1w165w@sytex.com>
Sender: bbs@sytex.com
Organization: Sytex Access Ltd.
References: <GS.94Sep26114614@dispo.ivu-berlin.de>
Date: Mon, 26 Sep 1994 20:03:56 GMT
Lines: 83
Xref: glinda.oz.cs.cmu.edu gnu.misc.discuss:18298 comp.lang.tcl:19311 comp.lang.scheme:9916

gs@ivu-berlin.de (Gregor Schmid) writes:

> This is only partly true. You may carry around a pointer to the end
> of the list from a prior calculation and thus get an O(1) append time.
> This is the general case where it matters, e.g. when you are building
> a list.
> 

Howdy,
        But take a look at Richard Waters article in Lisp Pointers
IV.4 1993 "To NReverse When Consing a List ...".  He makes a good
case for using nreverse (reverse! in scheme, non-standard but often
there) vs rplacd (set-cdr! in scheme), looks at generated machine code
in various lisps, times the two approaches, etc.  Basically, got to
watch those inner loops (and I imagine write barrier detection in
certain GC implementations) and what the compiler/rts can do in
real implementations.
        Now for my two cents.  I like Lisp and Scheme. Visual Basic and
TCL are popular on their respective platforms.  Whose "fault" is this?
It's _our_ fault (I'm developing a Lisp system for Windows): language
implementors.
        I feel that paren syntax is one of Lisp's greatest _strengths_:
the ability to easily write macros that write Lisp programs. A wonderful
concession to the "hacker" in all of us. See Paul Grahams recent book. 
If Lisp were more popular, it would have been called "Tricks of the 
Common Lisp Masters".  Or look at H.Baker's paper on "META" - an
excellent hack for small parsing problems vs. 300 pages of LL/LR
parsing theory.
        The language is perfectly _cool_. Not everyone loves it, but
who cares. We're not going to please everyone.
        But.... where are the implementations that "keep up with the
times". MIT Scheme is slick - but it's Win32s or better and has no
GUI interface.  SCM is small and portable but it's fairly minimal.
CLISP is nice, but I don't like the built in editor. Etc. No one 
implementation is hacked on hard enough to make it portable/
feature rich/etc.
        I know that there are no easy answers.  There _are_ happy
users out there.  Never seems to reach critical mass though. Some
nudnick criticized a happless Windows user of MIT Scheme a few
posts ago: "Get a real OS".  This attitude is stiffling.  (Tk/Tcl
has just been ported to NT as I understand it.)  We've got to 
return to a fundamental design principle if Lisp/Scheme are to
thrive and grow: Easy things should be easy; difficult things 
should be possible.
        Anyway, here's a simple plan.  
        (1) Get GCL running on Win32s. Just plain _stupid_ not
        to.
        (2) Find a smaller Lisp/scheme and make it EGCL or 
        EGScheme (embeddable) - now. Hack real hard until it
        works on Unixes/Windows. It _doesn't_ have to be
        recompilable, just "portable" - meaning ported. Support
        as much native OS functionality as possible, in fact.
        (3) Make sure a GUI tool runs on (1) and (2) above. Don't
        start from scratch. SCM maybe a good place to start - it
        runs on _everything_, although there are other considerations.
Easier said than done, I know.... Oh yeah:
        (4) Make sure docs/online help are available in the format 
        used by each platform. (TeX alone doesn't cut it.)
        (5) Don't get _too_ clever. Use low tag bits/tagged objects
        hybrid scheme. Maybe use non-copying scheme to support easy
        C integration - _or_ provide for "locked references" to
        support the same.

Sorry for long post...

P.S. LinkLisp for Windows (16 bit!) coming soon. CL subset .DLL for
embedding in your favorite C/Pascal application.  Visual Basic VBX
on the way! Also DDE interface for implementing "Lisp Servers" or
interfacing a DDE aware editor with Lisp.  Lisp editting "shell"
provided. Source for shell provided as a "sample app".  Fast bytecode
compiler/vm. Large RTL in C shared across all Lisp processes. Ability
to define "binary" data structures. Link to DLL's.  LinkLisp aware
.DLL's able to generate "Simple-Errors" for integration with Lisp's
structured exception handling.  And more... For more information,
email.  We have a promo-flier and are working on a more technical
"white paper" for the discriminating consumer ;-)
      LinkLisp(tm) is a trademark of Conscious Computing.
      Windows(tm) is a trademark of the Microsoft Corporation.

=============================================
Scott McLoughlin
Conscious Computing
=============================================
