Re: Lstreams, coding and md5 (was: Re: [PATCH] menubar selection in mswindows)

kkm> Why don't you want to use the same coding-system-for-write kkm> variable? coding-system-for-process-output and kkm> coding-system-for-md5 are only messing things, i.e. I should kkm> which one I should bind in a let clause around a call to kkm> which function. There must be only one variable for one I/O kkm> direction (if we loosely assume that md5 hash is intended to kkm> be transmitted, so is a kind of output). But output is not uniform, even for the same buffer. Mail and process buffers are examples. If you're only going to use one variable for everything, then you're going to be binding it in a very large number of cases and may as well have an argument for each such function. In My Uniformed Opinion == I'd want to try it both ways and see which produces more readable code, but that may be infeasible. The main reason for the multiplicity of variables is historical, I guess; that's the way Mule does it now. In fact, on your argument, one doesn't need even a directional distinction. One knows that one end of the conversion is internal, and each operation knows whether it is input (variable external to constant internal) or output (constant internal to variable external). kkm> If there must be a configure variable which defines a default kkm> coding system for md5 hashing, heaven save C code from kkm> depending on it, no? Exactly. Now I've said it, you've said, Hrvoje has said it, Martin has said it, and I've probably missed 18 or 20 names. Altogether now: the coding system design should be carefully thought out! As I wrote before, I don't know how much it needs changing and how much it just needs documentation. Either way it needs thinking about.