RE: [Haskell-cafe] Seeking comments on this IO proposal
On 17 December 2004 16:49, John Goerzen wrote: > First, if someone were to make a working, useful package out of this, > is it likely that it would become the "standard" (whatever that > means) IO system in Haskell anytime in the near future? I ask > because I don't want to put a lot of time into developing an IO > library, and code that works with it, only to have nobody use my code > because it's incompatible with everything they're doing. I'm keen to transition over to a more general IO framework, and I believe Bens/my proposal is heading in the right direction. When we have a more complete implementation, I'd be happy to include it with GHC for experimentation, and over time transition code to use the new framework while leaving the old System.IO in place for the time being. The design isn't by any means set in stone at this stage though. > Second is my own level of expertise. I frankly don't understand how > much of that code could even compile (example: I couldn't find > setNonBlockingFD anywhere in my docs; maybe it's from one of those > GHC.* areas), and I don't really understand the whole array/buffer > situation either. I spent some time reading docs, and I'm still not > sure exactly how one builds a mutable, resiable array. I've also > never done anything but the most trivial FFI work. Much of the reason for the complexity is because I was paying careful attention to performance (perhaps too much attention). I don't want the addition of a text encoding/decoding layer to the IO subsystem to affect performance more than is necessary, and that means doing the translation on raw character buffers rather than strings. Unfortunately this does mean that porting to other compilers is going to be more work. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Seeking comments on this IO proposal
At Fri, 17 Dec 2004 10:48:34 -0600, John Goerzen wrote: > First, if someone were to make a working, useful package out of this, is > it likely that it would become the "standard" (whatever that means) IO > system in Haskell anytime in the near future? I ask because I don't > want to put a lot of time into developing an IO library, and code that > works with it, only to have nobody use my code because it's incompatible > with everything they're doing. I am quite ignorant about the different proposals coming along these days, but I would hope that anything that hopes to be the next generation of IO would address: (1) binary IO (especially dealing with bit-fields -- like what you would see in network packets, or binary data formats like .swf or stuff). (2) Internationalization / Unicode I am not saying that it must *solve* these problems -- just that it needs to have a plan for how to add these later. Thanks! Jeremy, the ignorant, Shaw. -- This message contains information which may be confidential and privileged. Unless you are the addressee (or authorized to receive for the addressee), you may not use, copy or disclose to anyone the message or any information contained in the message. If you have received the message in error, please advise the sender and delete the message. Thank you. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Seeking comments on this IO proposal
Thank you, Ben, Simon PJ, Simon M, David, and the others that sent such helpful responses. It seems that there is rough consensus that Ben/SimonM's ideas are the right way forward. Obviously these ideas represent a significant shift from the way things are now. I spent some time looking over Simon's example. My first reaction was: "this is almost as complex as Java." Then I saw the System.IO.Text module, and how it could be used in a pretty much self-contained fashion with the same ease as the current IO system, and I felt much better about it. I like the ideas. There are two concerns, though, before I dive right into something like this. First, if someone were to make a working, useful package out of this, is it likely that it would become the "standard" (whatever that means) IO system in Haskell anytime in the near future? I ask because I don't want to put a lot of time into developing an IO library, and code that works with it, only to have nobody use my code because it's incompatible with everything they're doing. Second is my own level of expertise. I frankly don't understand how much of that code could even compile (example: I couldn't find setNonBlockingFD anywhere in my docs; maybe it's from one of those GHC.* areas), and I don't really understand the whole array/buffer situation either. I spent some time reading docs, and I'm still not sure exactly how one builds a mutable, resiable array. I've also never done anything but the most trivial FFI work. I'm willing to learn, but since there's a lot there that's new to me, I'm not terribly confident that I would write correct, useful code. I'm especially unsure of how to make it work with the non-GHC compilers/interpreters out there, given all the GHC pragmas in the code. On Fri, Dec 17, 2004 at 12:09:34AM +, Ben Rudiak-Gould wrote: > John Goerzen wrote: > > >My proposal is here: > > > > http://www.complete.org/~jgoerzen/t/MissingH.IO.HVIO.html > > > >I'm aware that others have been working on IO proposals; specifically, > >Simon Marlow's here: > > > > http://www.haskell.org/~simonmar/io/System.IO.html > > The proposal on Simon M's page was originally my design, though Simon > made many improvements. You can read my rationale for the original > design in these mailing-list messages: > >http://www.haskell.org/pipermail/haskell/2003-July/012312.html >http://www.haskell.org/pipermail/libraries/2003-July/001255.html >http://www.haskell.org/pipermail/libraries/2003-July/001257.html >http://www.haskell.org/pipermail/libraries/2003-July/001273.html >http://www.haskell.org/pipermail/libraries/2003-August/001319.html >http://www.haskell.org/pipermail/libraries/2003-August/001336.html >http://www.haskell.org/pipermail/libraries/2003-August/001366.html > > I had to abandon many of the original ideas because the Posix and Win32 > APIs can't support them. (Some examples of things you should be able to > do, but can't in Posix or Win32: given a directory handle and the name > of a file in the directory, open that file; given a file handle with > read access, acquire write access if available; conduct atomic > filesystem transactions.) The most important idea that survives is the > separation of files from input streams and output streams, > > Given this background you can probably guess that I'm not too keen on > the traditional open/read/write/seek/close model; I don't think it's a > good abstraction for anything, even files. I love the idea of gzip and > gunzip as transformations on streams, though, and streams backed by > memory buffers appear in my proposal too. > > > * Would I be better advised to try to implement some existing ideas > > instead? > > Yes, you should definitely spend your time implementing my pet idea, not > yours. :-) > > > * Are there any other implementations of these things that are ready > > to use? (With code) > > Simon wrote a prototype implementation of his/my proposal: > >http://www.mail-archive.com/haskell-cafe@haskell.org/msg05138.html > > > -- Ben > > ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Seeking comments on this IO proposal
What about Peter Simons' BlockIO library? Its very fast and has a reasonably simple interface. Keean. Ben Rudiak-Gould wrote: John Goerzen wrote: >My proposal is here: > > http://www.complete.org/~jgoerzen/t/MissingH.IO.HVIO.html > >I'm aware that others have been working on IO proposals; specifically, >Simon Marlow's here: > > http://www.haskell.org/~simonmar/io/System.IO.html ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Seeking comments on this IO proposal
On Fri, Dec 17, 2004 at 12:09:34AM +, Ben Rudiak-Gould wrote: > Given this background you can probably guess that I'm not too keen on > the traditional open/read/write/seek/close model; I don't think it's a > good abstraction for anything, even files. I love the idea of gzip and > gunzip as transformations on streams, though, and streams backed by > memory buffers appear in my proposal too. The traditional model may be limited, but it's still sufficient for many purposes, and since it's what is supported by the OS, there's something to be said for using it. As a non-library-developer, I must admit that I thought the proposal was pretty nice-looking. In general, I like the idea of creating a standard interface having multiple back ends, and certainly don't see how (for example) viewing a String as a non-seekable read-only file would be at all a bad interface. Of course, you could view it as a seekable read-only file, if you were willing to give up the guarantee of memory-efficient lazy consumption of said string. Presumably you'd need separate classes for binary vs text streams? Since hGetBuf certainly couldn't be used on a String, since it has no binary representation... -- David Roundy http://www.darcs.net ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Seeking comments on this IO proposal
John Goerzen wrote: >My proposal is here: > > http://www.complete.org/~jgoerzen/t/MissingH.IO.HVIO.html > >I'm aware that others have been working on IO proposals; specifically, >Simon Marlow's here: > > http://www.haskell.org/~simonmar/io/System.IO.html The proposal on Simon M's page was originally my design, though Simon made many improvements. You can read my rationale for the original design in these mailing-list messages: http://www.haskell.org/pipermail/haskell/2003-July/012312.html http://www.haskell.org/pipermail/libraries/2003-July/001255.html http://www.haskell.org/pipermail/libraries/2003-July/001257.html http://www.haskell.org/pipermail/libraries/2003-July/001273.html http://www.haskell.org/pipermail/libraries/2003-August/001319.html http://www.haskell.org/pipermail/libraries/2003-August/001336.html http://www.haskell.org/pipermail/libraries/2003-August/001366.html I had to abandon many of the original ideas because the Posix and Win32 APIs can't support them. (Some examples of things you should be able to do, but can't in Posix or Win32: given a directory handle and the name of a file in the directory, open that file; given a file handle with read access, acquire write access if available; conduct atomic filesystem transactions.) The most important idea that survives is the separation of files from input streams and output streams, Given this background you can probably guess that I'm not too keen on the traditional open/read/write/seek/close model; I don't think it's a good abstraction for anything, even files. I love the idea of gzip and gunzip as transformations on streams, though, and streams backed by memory buffers appear in my proposal too. > * Would I be better advised to try to implement some existing ideas > instead? Yes, you should definitely spend your time implementing my pet idea, not yours. :-) > * Are there any other implementations of these things that are ready > to use? (With code) Simon wrote a prototype implementation of his/my proposal: http://www.mail-archive.com/haskell-cafe@haskell.org/msg05138.html -- Ben ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
