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

Hrvoje> "Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp&gt; writes: Hrvoje> OK, this is the crux of your argument, and I see what you Hrvoje> mean. Still, how often does coding-system-for-write Hrvoje> differ from coding-system-for-process-output? For some Japanese users, every time she saves a file copy of a mail message. The local copy will be saved in Shift-JIS (Windows) or EUC-JP (Unix), the message will be sent as ISO-2022-JP. This is a hypothetical; I don't know how often it happens in real life. Hrvoje> It's not as simple as that. Remember that we are Hrvoje> creating, among other things, a programming language. Hrvoje> Before coding systems came into the picture, Fmd5 was an Hrvoje> exemplary of Lisp elegance: Agreed; I don't mean to argue that the argument is the best way, just giving you enough information that you can make a better decision. Hrvoje> This is as nice as it can get. However, with Mule, it Hrvoje> suddenly got 10 additional lines of docstring and two more Hrvoje> optional arguments that have *nothing* to do with the Hrvoje> process of md5-ing a stream of bytes, and that are very Hrvoje> (Mule)-implementation specific. I don't know if it matters to your argument, but this is _not_ implementation-specific, it is multi-lingual-environment-specific. The problem is not the way Mule is currently implemented, as far as I can see, it's that the internal and external representations differ. They will do so until UCS-4 rules. In other words, in the world where Mule is used, there is no such thing as a "stream of (generic) bytes." There is a "raw" external encoding, but that will not be directly useful for people making digitally signed email (unless they can truly type their message blind). Hrvoje> ...the point I'm trying to make is that interface to Hrvoje> user-visible Lisp functions should be well thought-out, or Hrvoje> problems will arise. Yes, indeed. I shudder to think what working on Mule would be like if Ben had not founded his work on that principle as applied to internal APIs. The bare minimum that will be necessary for any Mule-ized function whose value may end up being used by tools outside of XEmacs is going to be that it be told how its value will be used, so that it can choose an appropriate representation relative to which it will compute the value. I'm hoping that this can be done by using a property of the target of side-effects without extra arguments, but when the function has no textual target, there will need to be an argument or a flag variable it consults to know what representation is desired. In the case of Fmd5, it should normally be possible to guess the usage from properties of the source of the text, so the variable could be used. On the other hand, for other functions it may rarely be possible; if such cases are the majority, then for consistency of the Mule interface we would want an argument, I think. How do you see it? (This is not an academic question; it will definitely have an impact on my current hobby of extentifying Mule.)