Since the discussion goes on whether to base scsh on another Scheme
implementation, let me ask, what exactly makes SCM a bad choice? I
don't count the recent flame.
As you know, SCM is the base of guile and cygnus recently announced
their plans to hire two additional full-time people for guile work,
one documentation writer and one coder. Those are resources that can
be very useful for fixing things that are time-consuming and boring.
Guile intents to be a collection of a number of useful
libraries. Making scsh such a library would mean:
- scsh would be distributed to a much wider audience.
- this audience, having installed guile for other reason, would have
scsh available on their system. That makes evaluating scsh much
easier.
- I'm sure the guile people will implement something like scsh
sooner or later, limiting scsh's audience further.
- Guile is probably the Scheme implementation with the best chances to
get a fancy development environment in the near future.
Martin-
I have been refractory wrt scsh involvement since the 0.4 release due to
alternate crises; sorry for the delay in responding to your question.
I have on multiple occasions urged Tom Lord to port scsh to scm. Tom has
never picked up on this. It isn't that he is uninterested, it is simply
that his role in guile is more of a coordinator rather than a boss. He
has told me he is not able to control what volunteers choose to work on.
I did a careful job with scsh's design because I wish to avoid a common
problem I see with contributed software: people keep reinventing incompatible
80% solutions, and never progress to something good. Since each solution is
quickly hacked together, the next guy usually throws it out and builds his own
-- duplicating effort. But since that next guy had to start from scratch, he
usually ends up with another 80% solution. (I had to do this in with emacs
when I wrote comint -- there were five or more different lisp/shell/scheme
packages, all incompatible, most based on hacked-up versions of the original
shell.el code. By sitting down and doing a *good* job once, you could put a
stop to all the bad versions, and future hackers could leverage off a quality
substrate.)
A big contribution of scsh is not the *implmentation*, it's the full-coverage
syscall API. It tooks me *years* to put it all together in a coherent,
well-designed way that integrated naturally with Scheme. It's not likely that
J. Random Hacker could do this -- J. Random Hacker usually has an actual
problem he wants to solve, and he'll have a hard time following through to
design and implement the interface beyond the subset he needs for this
project's code. So you fall into the 80% loop. J. Random Hacker is also
usually in a hurry to get on with hacking his actual app, so he won't take
great pains with his API design. Examples of this would be the early pipes,
serial line, and socket code hidden away in the vm-extension code of Scheme
48. Brutal, low-level, ugly design. The implementors would agree with me
here -- then tell you they had a job to do, and it wasn't OS API design.
By doing a careful job once, I'm hoping we can move forwards, rather than
loop.
Unfortunately, when I have looked over recent snapshots of guile, I do
not see this happening. Guile has this "gscsh" library, which provides
a process-notation macro that is less featureful than scsh's, and the
Posix library API is less extensive than, not as good as, and incompatible
with, scsh's.
I *really* wish guile would simply steal scsh's design. It's by far the best
Scheme interface to Unix ever written. I do not blow my own horn when I say
that -- it is simply that no-one has ever really made a serious effort to do a
complete, integrated job.
It is flat-out impossible for me to consider porting scsh to guile myself.
I just don't have the time. I am already dreading the move to the next
Scheme 48 release (but it will be *really* nice to pick up threads).
You raised two other points in your post:
- scsh could use all the libraries. Imagine what you could do with the
Tk GUI toolkit in scsh "shell" script.
Tk is a terrible choice for a Scheme GUI. Osterhout, for reasons I cannot
fathom, built tcl into the Tk functionality. This is brain-dead. Tk should
have been written as a pure C lib, and then bound into tcl. The problem is
that Tk's idea of a callback is a *string* of tcl source to be executed. This
makes Tk a poor fit for other languages; everyone who has ever done a port has
ended up with ugly kludges to handle this horrible design choice.
I have heard that people are working on a tcl-freed variant of Tk. That
would certainly be more appealing.
However, I also think the whole callback/event-loop model is a poor substitute
for concurrency. I would much prefer to assume threads and design a system
like CML's eXene, or DEC SRC's Trestle (built on top of Modula-3). I do
not actually think it would be that hard to rip-off the look and feel of
Tk's widget set, and build a native Scheme widget set for X that was Scheme
all the way to the protocol layer. This is the high road. If you must do
callbacks, you do them with proper Scheme closures. Better yet, use concurrency
and just let threads syncrhonously block on event channels.
I know of two nice Scheme GUI's being developed that the guile people might
want to consider: Indiana U's "Bob" and Rice's Mr. Ed.
- Maybe scsh could profit from additional syntaxes planned for
Guile when going towards some form of elegant syntax for interactive
shell work.
When the guile people claim they will develop infix syntaxes for guile
-- like the Dylan people claimed -- I just roll my eyes. It's a waste of
time. Contrary to the popular claim, people are *not* afraid of parens.
Consider autocad -- probably the single most popular CAD tool ever
developed. Hacked exclusively in autolisp. Parens all over the place.
Consider as well emacs lisp.
I *am* interested in designing a nice alternate syntax for scsh's
process notation that would be more adapted to interactive use.
That is a very specialised notation, however, and not likely to
be what anyone would do if they were to design a general infix syntax
for a general-purpose programming language.
-Olin
|