Re: [Groff] [off] micro-typography

[Colin Watson]

On Wed, Feb 13, 2002 at 01:28:00PM +0100, Thomas Baruchel wrote:
> On Wed, Feb 13, 2002 at 10:59:06AM +0000, Colin Watson wrote:
> > You also don't have to worry about whether the co-language can
> > handle sockets; just connect its stdin and stdout to the pipe/socket
> > to troff.
> 
> I don't completely agree. Of course you can do this in many cases, but it
> isn't very clean and therefore you have some exceptions. I don't see for
> the moment an unix language interpreter that couldn't do that, but I have in
> mind the difficulty to do that with the unix 'dc' calculator. If you try
> to launch it from a process and write on its stdin, you will not have
> the evaluations on stdout.

dc probably won't be able to handle sockets anyway. We have to discount
languages that can only deal with interactive use on a tty.

> Anyway, it won't be very clean, because your initial script would have
> to do everything (ie. define macros) BEFORE reading stdin. The script
> would be much more powerful by using a socket.

I don't see the difference. Reading a socket is just the same as reading
stdin, but stdin is simpler in many languages and involves less setup.

> Have an example: Troff will send two sorts of things to the
> interpreter: sequences belonging to a general protocol like the word
> 'EVALUATE' and code. For instance:
> 
> [troff->interpreter] EVALUATE (troff-print (log 5)) END
> 
> EVALUATE doesn't look like a Scheme macro. It would be very heavy
> and inelegant to cheat the interpreter with that. If in the contrary
> the interpreter is in the middle of a loop waiting for some
> information on the socket, it will see what is protocol, what is code,
> and will redirect everything where it should go in a much cleaner way.

But if the interpreter is in the middle of a loop waiting for some
information on stdin, it will also see what is protocol and what is
code.

Don't get me wrong; I'm not suggesting that troff's commands should be
commingled with the code being executed by the interpreter. The
interpreter's code will naturally come from a separate file, and will
then begin reading on some file descriptor. I'm merely suggesting that,
for simplicity, that file descriptor should be 0.

-- 
Colin Watson                                  address@hidden