NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/lang/tcl/1204

Text File | 1992-08-16 | 6.1 KB | 107 lines

Organization: Carnegie Mellon, Pittsburgh, PA
Path: sparky!uunet!europa.asd.contel.com!darwin.sura.net!udel!rochester!cantaloupe.srv.cs.cmu.edu!crabapple.srv.cs.cmu.edu!andrew.cmu.edu!<UNAUTHENTICATED>+
Newsgroups: comp.lang.tcl
Message-ID: <[e-mail]>
Date: Mon, 17 Aug 1992 01:11:10 -0400
From: [e-mail]
Subject: Why tcl scales just fine if you put something on top of it
Lines: 97

[I originally sent this as email to Dan Conolly@Convex in re his
original message. As I've seen a couple more messages in the thread on
the group, I thought I'd post it and stand the inevitable flames. This
is actually two messages cat'ed. Yes, since I wrote BOS I'm of course
more comfortable with it than anyone else (Hi, Colas! :-), but I do
think there is a more generic point to be made that just "use my neat
thing and all your problems will be solved". Of course, if you *do* use
my neat thing all your problems *will* be solved, but that is another
matter... :-)*10 --S]

Check out BOS - The Basic Object System. It's a C-callable library that
implements the notion of object and which uses Tcl as its interpreter
for interpreted methods (you can have "compiled" methods in C, and mix
compiled and interpreted methods in the same object, plus lots more
stuff). I regularly (a) subclass and (b) mixin existing objects using
BOS to extend, among other things, the set of tk widgets (I have all tk
widgets wrapped with BOS "classes"). BOS is a class-free object system,
also called a prototype-based object system; it is modeled loosely on
the Self system from Stanford. It solves most of the problems you
brought up in your message, I believe. I'm working on a compiler for BOS
that will translate interpreted methods into C code, which should solve
the rest of them.

BOS 1.31 is available from the tcl archive at barkley, and via anonymous
FTP to sambar.ndim.edrc.cmu.edu (128.2.214.236) under
/afs/cs/user/snl/public/bos-1.31.tar.Z. There isn't a whole lot of
example code yet, and the makefile will need some tweaking on your
system, but it is small, easy to understand, and 90% of the exported
interface is documented (the 10% that isn't is new as of 1.31 and will
get man pages and other docs Real Soon).

BTW, I spent quite a bit of time playing with lisp-based extension
languages and building software in lisp environments in general (all the
way from MACLISP on the ITS boxes at MIT and the Symbolics to SIOD and
Allegro), and am now thoroughly convinced that lightweight, easily
embeddable languages like tcl and hybrid environments that mix C,
fortran, and other compiled languages with such interpreted ones are the
way to go. Managing separate heaps for lisp and C, dealing with the
realities of unix environments and other basic problems prevent common
lisp from really being able to provide what is needed on a
lowest-common-denominator basis, for a number of reasons, not all of the
techinical. I am building a very major piece of software using BOS/tcl,
and find it just the right blend. Of course, everyone's mileage will
vary...

If you do pick up BOS and have any questions, comments, suggestions or
complaints, don't hesitate to drop me a line. There is plenty of ongoing
development in BOS, and what seems like growing interest from the net.

---  2nd message, after another cup of coffee and some remeniscence ...

Oh, BTW, Motif is a hunk of junk. :-) 1/2. I spent two years building a
substiantial piece of work using it -- a tookit for building DAG-based
UIs. Ever try to subclass a Motif widget? I built an interpreted
environment based on SIOD and my graph representation stuff and built
some fairly intense stuff, but maintaining it and debugging it was a
total headache, and the usual major disconnect between lisp
datatypes/heap and C data still manifested itself. I'm sure GJC can and
does do lovely things with SIOD, but I'm much happier with Tcl. My
solution to the everything-is-a-string problem was to introduct the
notion of FOREIGN slot types into BOS. You can define slot types that
are pointers to hunks of C data by giving BOS pointers to functions that
will copy, free, print and parse such things, and then write methods in
C that deal with such slots and bundle them together in BOS objects;
this is how I implement the BOS HashTable and List objects, for
instance. Very fast and no overhead as long as you don't as a HashTable
to give you all of its contents as a string (which you can ask it to
do), in which case you have to malloc up the string and free it
afterwards; as long as you are playing nice, however, you don't pay the
price. Much easier and safer than extending tcl or playing with lisp,
IMHO.

[Note - it took all of two weeks for the initial port of the old
Motif-based DAG toolkit to Tk, which was done with Tk 1.3 (I think,
maybe before that even). The Motif version of the toolkit had taken me
two solid years and still had troubles, mainly due to bizarre
interactions between incestuous Xm widgets and my subclasses of them,
lots of other stuff that I've fogotten about, having been happily
beating on tk/tcl for so long now. Although minor performance tweaks and
bugfixes have been done to the tk version, it hasn't needed any major
overhauls since it was ported. The port and subsequent maintainence
wasn't even done by me, but by a colleague who had done the original,
prehistoric version of the toolkit with an X10 version of the HP widgets.

In a subsequent followup, Dan pointed out that Motif has certain
performance advantages over tk, to which I replied that this is a
temporary state of affairs that, due to the nature of tk/tcl
(unencumbered and easily modified), will probably be remedied quickly
enough to warrant hanging around; at least, that's what I'M planning on
doing. Of course, if I get tired of hanging around, I could tweak it
myself, something I wouldn't have DREAMED of doing with Motif except
with the bits I was on extremely intimate terms with, since you never
really knew all the implications of a single change to a single
widget... plus it then becomes non-blessed. --S]
--
Sean Levy, n-dim Group, EDRC, CMU, 5000 Forbes Ave, PGH, PA 15213
Email: [e-mail], Phone: [phone], Fax: [phone]