CLIM mail archive
[Prev][Next][Index][Thread]

Using Processes in CLIM

re: How many other people would like it?  How many other people ALMOST NEED
    it? What other facilities might fall into this category? 

For sake of rounding out the history behind this thrust, let me try to
recreate the comments I gave at last Monday's meeting which led to this
current topic.  I observed that several of the inner layers of CLIM
were "rolling the old oval wheel" by re-inventing system-programming
facilities that each implementation of Common Lisp (in the CLIM group)
must itself also have lying around somewhere in it's innards.  In 
particular, I mentioned the QUEUE data-type and a small set of primitive
operators on it, as well as the semaphor-like EVENT datatype, and 
remarked that Interlisp-D had these added in about 1983 *precisely* 
because they were necessary to support the version of multi-tasking 
being added at that time (and, not surprisingly, "push" came to "shove"
in this matter because the single-tasking version of the Interlisp-D 
window system/interface just couldn't keep itself from getting wedged 
now and then.  Especially with mouse-initiated operations.)

My suggestion is to expose the CLIM version of these two things,  and 
thereby perhaps set a de-facto standard in the Common Lisp world for 
these two extremely useful and oft-reinvented wheels.

Then someone (who? perhaps you?) noted that CLIM also has many
other primitives related to process control (waiting, locking, etc?)
and that perhaps these too should be exposed.  In fact, since the
primary non-Symbolics vendors of CLIM (to my knowledge, Lucid and
Franz, but possibly Harlequin also?) just cloned the Symbolics
design for multi-tasking, a minimal "de facto standard" here
shouldn't be very hard to do.

Now.  The absolutely worst possible thing to do would be to try to
make Multi-Tasking into a formal standard (such as by suggesting
it to X3J13?)  In fact, early in its history, X3J13 set up a multi-
processing subcommitte which promptly folded under the recognition
that it was premature to standardize on what only one vendor was
willing to do then.  And I don't even think that vendor was willing
to stand behind its full design.  [hmmm, the "foreign function" 
subcommittee, the "windows" subcommittee, and the "commercial subsets 
(read: delivery)" subcommittee all folded nearly as fast too.  Just
be thankful we got at least OO programming (CLOS), Iteration (LOOP),
and ErrorHandling (the CONDITION/SIGNAL system).]

The idea behind a "de facto" standard is that everybody wants it
because (1) it is simple, (2) it solves a common problem, and 
(3) it works.  So to win big this way, just:

   (1) Keep It Simple, (Say What, boss?)
   (2) Don't put in enough "features" to make it complete, clear,
       and unambiguous (you can't ever achieve perfection, so don't 
       get bogged down trying);  just make it enough for CLIM.
   (3) Make It Work!


So putting things in the CLIM package, or in the CLIM-SYS package,
should be satisfactory.  If some other user wants them exported from 
the RIGHTEOUS-LISP package instead, then Fine.  Nothing at all wrong
with having them exported from two (or even three!) packages.  You
just need one canonical export package for CLIM and the cooperative 
user to access them from.



-- JonL --

0,,
References:
Main Index | Thread Index