CLIM mail archive

[Prev][Next][Index][Thread]

Re: Using Processes in CLIM



One additional point of history, and one comment on packaging:

> Date: Fri, 29 Mar 91 23:15:03 PST
> From: Jon L White <jonl%kuwait@lucid.com>
> 
> 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.

Actually those vendors copied an out of date version of the Symbolics
design, or to look at it from another point of view the Symbolics
design was actively changing while they were copying it, so this didn't
actually produce a common de facto standard after all.  None of the PC
Common Lisps I'm aware of have multiple processes, so it's not an
industry-wide de facto standard in any case.

> 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.

I think it would be a good idea to keep these sort of things out of the
CLIM package, reserving that package for things that are conceptually
part of CLIM and that have been relatively carefully worked out.  The
things in the CLIM package should be portable to -all- CLIM implementations
and should be relatively stable.

Having a second package, such as CLIM-SYS, for useful things that happen
to be present in some versions of CLIM seems reasonable, but they shouldn't
be mixed together with the things that are more stable and more widely
portable.


0,,


Main Index | Thread Index