> >> ...or send a bug-report. ;-) > > > > But then you would need to convince X number of implementations to > > change... Probably qeasier said than done :) > > Whoa, whoa, slow down here. > > Try this on for size: > > Question: You consider yourself a "gardener". You use implementation > X or library Y. It has a bug / missing feature / portability issue / > quality of implementation issue / whatever. What do you do? > > Answer: Report to the appropriate forum. > > Of course, I may not always make sense to do this: you may be too > pressed for time, you may not be sure it it is a bug or not, you may > not really care about the issue, etc.
It's not really that; it's that a given behavior might not even *BE* a bug from the implementations point of view, but required in order to implement this fictional unified API. It might not even be possible to change the bahavior without causing unacceptable backward compatibility issues. That is why I implied it would be difficult to "fix" every implementation. Of course I have no actual experience to point to that prooves this is an issue... it's more of a general feeling I have. > I strongly believe that this is one of the best and most effective > ways a "gardener" can tend this lisp-garden. > > Not doing that because > > > But then you would need to convince X number of implementations to > > change... Probably qeasier said than done :) > > is putting the cart before the horse: one thing at a time. After > implementation X does it, you people caring about implementation Y > should have an easier time of getting it to converge. On the other hand I would hope for something that is usable *soon* and in a consistent way. I still believe it might be easier to create a separate I/O API - provided that it is possible to provide standard CL stream compatibility on "most" implementations. There are a lot of subtle issues that I think must be "dealt" with in order to provide an API with a truly unified feeling. Things like non-blocking vs. blocking I/O must be considered (e.g., READ-SEQUENCE does not handle non-blocking I/O AFAIK... there was a SBCL-specific alternative but that is, well, SBCL specific). Then there is this whole issue with binary vs. character I/O. I have ran into issues where all I want is a simple line-based parser; but since I used character streams (because that is was CLOCC-PORT returned when returning an input stream connected to a process), I started getting reports of character encoding errors being signalled. I could witch to binary streams, but then I would have to drop the use of CLOCC-PORT aswell as convenience functions such as READ-LINE. Very much solvable, but extremely annoying when you're used to the gazillion of languages that manage to handle i18n properly[1] without blowing up on "broken" (usually not broken, just in the wrong charset or whatever) input. IIRC there was an interesting discussion on comp.lang.lisp on how to portably pipe the input of one program on to another, in Common Lisp. The fact that the thread needed more than a couple of messages to sort the issue out says to me there is a problem. I dunno. Perhaps I am dead wrong on it all... I do plan to read up on things in more detail (e.g. gray streams) to get a better handle on what is reasonably possible to do. Does anyone have opinions on binary vs. character I/O? Is the distinction (to a degree that you ran into the above mentioned issues) desired? Or would it be preferrable to have mixed-mode streams that handle both? (I believe Allegro's simple streams do this?) [1] By "properly" I mean being able to perform simple operations like reading data up to a newline, without requireing valid data in whatever charset is mandated by the current locale. Especially being able to read some number of bytes (reagrdless of whether they constitute valid characters or not) and then write them out again *without* transforming (corruption) the data. -- / Peter Schuller, InfiDyne Technologies HB PGP userID: 0xE9758B7D or 'Peter Schuller <[EMAIL PROTECTED]>' Key retrieval: Send an E-Mail to [EMAIL PROTECTED] E-Mail: [EMAIL PROTECTED] Web: http://www.scode.org _______________________________________________ Gardeners mailing list [email protected] http://www.lispniks.com/mailman/listinfo/gardeners
