Lex writes:

>On the other hand, there are primitives intended for low-level OS access
that Squeak doesn't understand.  For instance, adding pipes or Unix
domain sockets.  These kind of primitives tend to be pretty short, and
furthermore they aren't able to run under in Smalltalk.  For these, it's
probably *easier* to just write the C code directly.  The primitives are
unlikely to actually run in Smalltalk, anyway, so you have the same
edit-compile-restart cycle.

The downside of this, of course, is that such primitives must then be linked 
directly into the Smalltalk VM, numbers must be assigned, and so forth.  Using 
named primitives compiled into shared libraries (DLL's, etc.), you can write 
plugins that require no "hard-wiring" apart from the smalltalk glue you write, 
making it possible to build modular facilities that can be easily used by 
anyone, even if they do not own a C compiler.

Further, my experience is that this approach requires a substantially shorter 
and simpler edit-compile-restart cycle than a full squeak build and is 
substantially less error prone.  Additionally, you can quickly and easily test 
and manipulate the mixed C-and-Smalltalk code in ways you would never be able 
to do so with a squeak primitive.  This is particularly so when messing around 
with linkage issues.


Does this 2-way classification strike people as reasonable?  If so, is
there a reason to use Smalltalk variants in the low-level-OS-calls class
of primitives?


Lex


PS -- the pluggable primitives rule for the low-level OS stuff!!  Now if
only I had a separate 24 hours each day for hacking on Squeak!