[318] in Zephyr Mailing List
Re: undead zwgcs
daemon@ATHENA.MIT.EDU (Ken Raeburn)
Mon Sep 28 11:55:41 1998
To: Greg Hudson <ghudson@MIT.EDU>
Cc: griffon@snurgle.org, zephyr@MIT.EDU
From: Ken Raeburn <raeburn@cygnus.com>
Date: 28 Sep 1998 11:51:09 -0400
In-Reply-To: Greg Hudson's message of "Tue, 22 Sep 1998 14:09:05 EDT"
Greg Hudson <ghudson@mit.edu> writes:
> There is no particular reason to make zctl programmable (which would
> drastically expand the realm of historical user expectations as well
> as bring in a dependency on some giant ball of hair like tcl or perl)
> as long as it has a predictable tool-like interface. Anything
> complicated can be done in a scripting language like, say, /bin/sh.
I don't have a strong feeling either way for zctl; scripting just
needs to be possible one way or the other.
> Even adding line-editing would be a poor idea, in my opinion. zctl's
> uses are pretty much all non-interactive.
Yeah, in that instance I'm thinking in more general terms of the
demise of ss. :-)
> (zwgc is an entirely different matter. One of the issues there is
> that there has to be backward compatibility for people with existing
> .zwgc.desc files, so if any language is going to replace the zwgc
> interpreter, it should be a decent target language. Scratch tcl and
> probably perl.)
I don't think there needs to be compatibility, necessarily, but as I
understand it one of the points of Guile is that it's supposed to be
able to work with other languages (like Tcl for example). So the
parser for the existing language could be reworked to return Scheme
objects, which could either be rewritten as Scheme code and saved to
disk, or interpreted under Scheme at run time.
On the other hand, I don't see that either Tcl or Perl would be a
particularly poor choice either. For any of the three, a few
auxiliary routines would be needed that could be written in the target
language or in C, and some hooks for receiving the message and for
displaying it.
