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

scsh in PLT Scheme?

The scsh FAQ
suggests that PLT Scheme (MzScheme) would be a suitable target for a
scsh port.  It also suggests that such a task would be "certainly hard."
After scanning the scsh sources, I agree that it would be difficult to

So before we embark on that course, let me poll the PLT audience: 

  - do you currently use scsh?	
  - what features of scsh do you use?
  - what features of scsh do you consider indispensable?
  - what features of scsh do you consider peripheral?
  - would you find scsh-under-PLT-Scheme useful?
  - would you use a PLT scsh-oid that implemented some, but not all of

On this last topic: it would be nice if a PLT scsh-oid used only
existing MzScheme features, so that the whole thing could be done in
Scheme. There is a large chunk of C code in scsh that otherwise would
have to be modified to work with PLT Scheme's FFI.  Because scsh is a
moving target, ported C code would raise significant maintenance issues.

Bypassing the scsh C code would mean that low-level Unix features would
not be available.  For instance, the terminal support in scsh would 
be missing in such a port.

Here's what I think we could build in Scheme alone:

 - extended process forms with redirections (scsh Manual, Ch. 2)
 - most of the system calls in Ch. 3, but not tty's or pty's
 - string manipulations (Ch. 5)
 - regexps (Ch. 6)
 - AWK-in-Scheme (Ch. 8)

Some of the scsh code for these features is just R5RS, and there's
no porting to do (knock on silicon).  Most of the work would be in
forcing the PLT Scheme process API to emulate the scsh process stuff.

Here's what would be missing:

 - low-level socket stuff (Ch. 4)
 - Scheme 48 threads, Unix signals  (Ch. 9)
 - system log stuff (Ch. 10)

MzScheme already has its own thread system, and makes sockets available
as Scheme ports via a high-level API.

How would you feel about this kind of (semi-)port of scsh?

-- Paul