Re: scsh in PLT Scheme?

["Neil W. Van Dyke" <nwv@neilvandyke.org>]

Some Guile 1.6 socket/port features I've used recently (which probably
had their origins in Scsh) that I don't think are currently in PLT 200:

  1. Ability to bind a socket to a specific address.

     This is especially useful for binding servers under early
     development to only 127.0.0.1, rather than expose
     non-yet-working-much-less-secure code to the Internet.

     Of perhaps less relevance to PLT, being able to bind to specific
     addresses is also necessary for multihoming Web services -- wherein
     a physical network interface is associated with multiple IP
     addresses (usually one for each Web site or hosting service
     customer, so that everyone can be on port 80).

  2. Block I/O, for low-level efficiency when doing things like
     shuffling blocks of bytes verbatim between ports.  In Guile, these
     are "read-string!/partial" and "write-string!/partial".  My most
     recent real-world example is in implementing an HTTP proxy.

  3. Ability to make socket I/O be non-blocking.  In Guile, this is:
     (fcntl port F_SETFL (logior O_NONBLOCK (fcntl port F_GETFL)))

  4. Posix "select" or similar.  (I will cleverly avoid making run-time
     efficiency claims here.)  Sometimes the desired behavior of a
     system with many concurrent I/O activities reduces nicely to a set
     of FSMs that are scheduled within a single-threaded event loop.
     Losing the unnecessary complexity of multithreading sometimes makes
     the behavior of these systems tremendously easier to understand.

     If I end up teaching intro CS in a few years, I may want to teach
     "select" as part of a unit on concurrency, both to contrast/compare
     with multithreading abstractions, and also to plant the concept so
     that students later recognize situations in which they've
     essentially semaphored their multithreaded systems into a
     single-threaded event loop.

Aside on all the host OS process control features that are in many shell
scripting languages: as your "scripting" language becomes more powerful,
and you have better library support with direct bindings to the
language, I think the cases in which you want to exec external processes
becomes relatively few.  (In case there are any Unix newbies on this
list: historically, the Unix "software tools" convention was to have
extremely dumb shell script languages that were glue for composing
behavior from a haphazard set of simple tools.  Even simple tasks such
as adding two numbers required the exec of a heavyweight process for
each computation.  Much of the need for process pipelines came from the
fact that the output of these tools was often oriented towards display
to humans rather than as input to other tools.  So you often had to
construct a pipeline of several text-processing filter tools, each with
its own heavyweight process, just to, in essence, supply the value of
one function as a parameter to another function.)

Neil

-- 
                                                        Neil W. Van Dyke
                                             http://www.neilvandyke.org/