Trying to keep too many options open can prevent one from taking advantage of any at all.
The Lisp community would benefit enormously if one implementation were the defacto open source standard, and I think we should choose one and put our efforts behind it. Do we want other implementations to adopt the fictional unified API? Then we should make sure one open source implementation is more popular than any other. If the unified API is that good and that popular, the others will take care of themselves. Steve On Mon, 2005-12-26 at 23:38 +0100, Peter Schuller wrote: > > >> ...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 _______________________________________________ Gardeners mailing list [email protected] http://www.lispniks.com/mailman/listinfo/gardeners
