RE: [Haskell-cafe] Re: I/O interface
On 12 January 2005 01:27, Ben Rudiak-Gould wrote: First of all, I don't think any OS shares file pointers between processes. Otherwise it would be practically impossible to safely use an inherited filehandle via any API. Different threads using the same filehandle do share a file pointer (which is a major nuisance in my experience, because of the lack of an atomic seek-read/write), but a Posix fork duplicates the file pointer along with all other state. I can't believe I'm wrong about this, but someone please correct me if I am. I'm afraid you're wrong. Believe me, I'm as surprised as you. See the definition of Open File Description in POSIX: http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#t ag_03_253 This limits the problem to a single process. If you're only using GHC's lightweight threads, there's no problem at all. If you're using OS threads, the worst thing that could happen is that you might have to protect handle access with a critical section. I don't think this would lead to a noticeable performance hit when combined with the other overhead of file read/write operations (or lazy evaluation for that matter). pread requires that the file is seekable, which means that it can't be used for all file handles: not for pipes, sockets, terminals nor various other devices. The file interface in this library is only used for files, which are always seekable (by definition). If you want to treat a file as a stream, you create an InputStream or OutputStream backed by the file. Such streams maintain internal (per-stream) file pointers. Unfortunately, they don't (at least in my prototype implementation). I assumed that dup()'ing file descriptors would be enough to produce separate file pointers, but no. So you can only safely make a single stream from a File. Making multiple streams would require re-opening the file for each subsequent one, or keeping a cached copy of the file pointer and seeking when necessary. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: I/O interface
Ben Rudiak-Gould [EMAIL PROTECTED] writes: First of all, I don't think any OS shares file pointers between processes. Unix does. It's because shared files are usually stdin/stdout/stderr (I mean that they are visible as stdin/stdout/stderr, rather than about their nature as terminals - they may be regular files), which are usually accessed sequentially without seeking. Quite often they are not seekable at all (terminals or pipes), which means that they behave as if the file pointer was always positioned at the end (for writing) or beginning (for reading) and shared. If they are seekable, the position is shared so you can redirect I/O to a process running subprograms. Otherwise it would be practically impossible to safely use an inherited filehandle via any API. Pipes are not seekable and always behave as if the position is shared. It doesn't make them impossible to safely inherit. They are inherited on fork because they are anonymous objects, so it's the only way to connect them; after fork most programs close the reading end in one of the processes and the writing end in the other. It's rare that two processes read from the same pipe or write to the same pipe. If they do, one of them is usually a helper program started by the other, and the other waits for the helper to finish. If you want two processes to access the same file indepenently, pass a file name and open it twice. The file interface in this library is only used for files, which are always seekable (by definition). What do you mean by files? What you get from open() is not always seekable, because it's not always a regular file. The name may refer to a device (whether it's seekable depends on the particular device; block devices are seekable but most character devices are not, e.g. /dev/ttyS0, /dev/lp0 - serial and parallel ports) or to a named pipe (not seekable). -- __( Marcin Kowalczyk \__/ [EMAIL PROTECTED] ^^ http://qrnik.knm.org.pl/~qrczak/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unit testing in Haskell
I find that I don't need unit testing frameworks. A few features of Haskell and the associated interpreters (ghci and hugs) combine to make unit testing as you go really easy. I just write a few tests for each function I write and then some more module wide tests once the whole module is finished. Sometimes I need a little scaffolding to be able to output complex data types (or type synonyms), but often just deriving Show does the job! To me, unit testing is two things - testing at a low level (each and every function_ - regression testing by running all the unit tests again The second may benefit more from the frameworks, but I find the first can be done very effectively on an ad-hoc basis. Matt On 12/01/2005, at 6:05 AM, Dmitri Pissarenko wrote: Hello! When programming in an imperative language like Java, unit tests are a very important development tool IMHO. I want to try out unit testing in Haskell and wonder what experienced Haskellers think about unit testing in Haskell in general and the hUnit testing framework (see URL below) in particular? http://hunit.sourceforge.net/ What other unit testing frameworks for Haskell do you use? TIA dap -- Dmitri Pissarenko Software Engineer http://dapissarenko.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building GUIs for Haskell programs
Can anyone attest to the sense (or otherwise) of the following programming pattern - program all back end stuff in Haskell and compile to library - program all GUI stuff in *insert imperative language of choice and link to the library for back end functionality It seems the ultimate decoupling of interface from logic. Matt On 12/01/2005, at 2:33 PM, Duncan Coutts wrote: On Tue, 2005-01-11 at 21:05 +0100, Dmitri Pissarenko wrote: Hello! I want to learn to create GUIs with Haskell. Which GUI frameworks can you recommend? wxHaskell is good for building portable GUIs. It has an extensive selection of widgets and has a good API. gtk2hs is good for building GUIs that target the Linux/Gtk/Gnome platform (though it is portable to Windows). It is also an extensive toolkit. It allows you to visually design GUIs with the Glade user interface builder. The API style is currently more low level than that of wxHaskell or FLTK. There is also a binding to FLTK which is a much simpler, more light weight portable graphics toolkit. As far as I know, these are the only actively maintained GUI toolkits for Haskell at the moment. Duncan (gtk2hs developer) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: I/O interface
Ben Rudiak-Gould [EMAIL PROTECTED] writes: Marcin 'Qrczak' Kowalczyk wrote: Ben Rudiak-Gould [EMAIL PROTECTED] writes: fileRead can be implemented in terms of OS primitives, Only if they already support reading from a fixed offset (like pread). I'm not sure if we can rely on something like this being always available, or whether it should be emulated using lseek which is safe only as long as we are the only process using the given open file. First of all, I don't think any OS shares file pointers between processes. Otherwise it would be practically impossible to safely use an inherited filehandle via any API. Different threads using the same filehandle do share a file pointer (which is a major nuisance in my experience, because of the lack of an atomic seek- read/write), but a Posix fork duplicates the file pointer along with all other state. I can't believe I'm wrong about this, but someone please correct me if I am. This may be what you wrote, but let me still put it: dup()-ed filehandles share a common file position. Handles straight from open() have independent file positions. fork() duplicates filehandles and the child inherits those = the child process shares the file position with its parent. Threads or processes doesn't make the difference; dup() or open() does. This is my interpretation of the docs, I didn't test it... :) -- Feri. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building GUIs for Haskell programs
On 12 Jan 2005, at 11:10, Matthew Roberts wrote: Can anyone attest to the sense (or otherwise) of the following programming pattern - program all back end stuff in Haskell and compile to library - program all GUI stuff in *insert imperative language of choice and link to the library for back end functionality It seems the ultimate decoupling of interface from logic. This is roughly how I handled a recent project, in a mixture of ML and Java. Frankly I regret it: if I did it again, I would do the whole thing in ML (or perhaps haskell). Once you get used to languages with real higher-order features and powerful abstraction notions, it is a real pain reverting to a language like Java (or C or C++ or perl or...) ML, despite being thought of as a primarily functional language, is still (IMO, of course) a 'better' imperative language than Java, because of features like closures and local declaration of functions. I think the same holds of haskell using an appropriate monad instead of ML's imperative features. All this is of course entirely dependent on having a suitable GUI library or set of bindings for haskell. I haven't tried wxHaskell yet so I can't comment there. (And for some applications, some languages may be too slow, but I was ignoring efficiency in the above) Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Signature of a function
Am Dienstag, 11. Januar 2005 18:45 schrieben Sie: On 11 Jan 2005, at 16:47, Daniel Fischer wrote: Am Dienstag, 11. Januar 2005 16:45 schrieb Henning Thielemann: On Tue, 11 Jan 2005, Jules Bean wrote: Hint: Don't put signatures on functions, then. Instead, let the compiler infer the type for you! If you want to know what the type is, ask GHCi with :info. And if you think it is helpful documentation, you can copy-paste the correct signature from ghci into your source code! There should always be signatures. I do almost unrestrictedly agree! Deciphering code without type signatures is -- except in fairly trivial cases -- always a nuisance, and if the author chose short names instead of telling ones, it is positively disgusting! That's not really what I meant. I meant that, especially when you are figuring out a new language, getting the types inferred for you is helpful and also instructive... I wasn't suggesting that they be left out permanently. Jules Sorry about the misunderstanding. Yes, getting the types inferred for you is helpful and instructive, however, as Stefan Holdermans wrote, giving a signature upfront has definite merits, so probably the thing to do is - write a signature first - then comment it out and see what the System infers (and of course try to understand that). Concerning Keith Wansbrough and David Roundy's remarks about wrong comments, I am miserably aware of their correctness, but I still retain the hope that what a comment says about the overall intention of a function is more often helpful than misleading (am I naive?) even if the details lag behind by several updates. Best wishes, Daniel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building GUIs for Haskell programs
On Wed, 2005-01-12 at 11:34 +, Jules Bean wrote: On 12 Jan 2005, at 11:10, Matthew Roberts wrote: All this is of course entirely dependent on having a suitable GUI library or set of bindings for haskell. I haven't tried wxHaskell yet so I can't comment there. (And for some applications, some languages may be too slow, but I was ignoring efficiency in the above) The nice thing about all the GUI binding libraries we have at the moment is that they are wrappers over C libraries so the speed of the GUI should be pretty good unless you install a really slow event handler that gets fired all the time. I'd go as far as to say that a wxHaskell or gtk2hs GUI should be faster than an equivalent Java AWT/Swing gui. :-) Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: I/O interface
Ferenc Wagner wrote: dup()-ed filehandles share a common file position. They also share the file status flags (O_NONBLOCK, O_APPEND etc). So, enabling or disabling non-blocking I/O will affect all descriptors obtained by duplication (either by dup/dup2 or by fork). OTOH, each descriptor has its own set of descriptor flags (i.e. the close-on-exec flag). A related issue is that device state (e.g. terminal settings) is a property of the device itself, and so is shared amongst all descriptors which refer to the device regardless of whether they were created by dup/dup2 or a separate open() call. For this reason, hSetBuffering shouldn't be modifying the ICANON flag, IMHO. -- Glynn Clements [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building GUIs for Haskell programs
Hello! I don't think there is a simple answer. It probably depends on your experience, your development platform, and where you want to be able to distribute your application to. My goal behind experimenting with Haskell-based GUIs is to determine whether UI development in Haskell is much better (for instance, simpler, testable, maintainable) than in an imperative language. Up to now I have the impression that there are lots of things, which one can do in Haskell easier than in an imperative language. IMO user interfaces are very hard to test in imperative language. One needs to be very disciplined in order to test the behaviour of UIs thoroughly. It is possible, for instance, using the Abbot framework in Java, but it requires so much effort that, in most cases, I a) either don't write the test case for a UI behaviour, or b) write a test case on the non-UI part, which would fail, if the UI behaviour would work in a wrong way. For instance, imagine you want to test that a table contains value X in row Y and column Z. You can display this table, then navigate to the cell in the table and look what value is displayed there. This is hard. In most cases, I test the component, which is responsible for providing data for display (in Java they are called table models). A table model is just a class, which you can test with plain JUnit without any special extensions. So I want to try to write a GUI in Haskell and then decide whether writing GUIs in Haskell is really much better than writing them in an imperative language. Best regards Dmitri Pissarenko -- Dmitri Pissarenko Software Engineer http://dapissarenko.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building GUIs for Haskell programs
Hello! I want to thank all list participants for answering my questions concerning GUIs and unit testing. Best regards Dmitri Pissarenko -- Dmitri Pissarenko Software Engineer http://dapissarenko.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Problem with wxHaskell
Hello! I've downloaded wxHaskell, ran the wxhaskell-register.bat file and now try to build a minimal wxHaskell program. For this purpose, I tried to start GHCi using following command ghci -package wx GuiTest.hs GHCi crashed with following error messages: error-messages GHC Interactive, version 6.2.2, for Haskell 98. http://www.haskell.org/ghc/ Type :? for help. Loading package base ... linking ... done. Loading package haskell98 ... linking ... done. Loading package lang ... linking ... done. Loading package concurrent ... linking ... done. Loading package QuickCheck ... linking ... done. Loading package readline ... linking ... C:/ghc/ghc-6.2.2/HSreadline.o: unknown symbol `_rl_redisplay_function' ghc.exe: unable to load package `readline' /error-messages What am I doing wrong? TIA Dmitri Pissarenko PS: Here is the code of the application module Main where import Graphics.UI.WXCore main :: IO () main = run gui gui :: IO () gui = do frame - frameCreateTopFrame Hello World windowShow frame windowRaise frame return () -- Dmitri Pissarenko Software Engineer http://dapissarenko.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building GUIs for Haskell programs
Dmitri Pissarenko wrote: My goal behind experimenting with Haskell-based GUIs is to determine whether UI development in Haskell is much better (for instance, simpler, testable, maintainable) than in an imperative language. You might also be interested in wxFruit... http://zoo.cs.yale.edu/classes/cs490/03-04b/bartholomew.robinson/ ...although still a research project, it takes a more functional approach to GUI's. Greg Buchholz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unit testing in Haskell
Matthew Roberts [EMAIL PROTECTED] writes: I find that I don't need unit testing frameworks. A few features of Haskell and the associated interpreters (ghci and hugs) combine to make unit testing as you go really easy. I just write a few tests for each function I write and then some more module wide tests once the whole module is finished. Sometimes I need a little scaffolding to be able to output complex data types (or type synonyms), but often just deriving Show does the job! It seems to me that if you're going to take the time to craft some ad-hoc tests in the interpreter, you might as well take an extra few seconds to put them into HUnit tests so you can make sure they still pass later. This gives you more confidence while you are refactoring your code. peace, isaac ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Problem with wxHaskell
Your code works fine on Linux. :-) Oh, by the way, I compiled my wxHaskell with GHC 6.2.2 I note that the windows binary on the download site was compiled with GHC 6.2.1, and apparently these are not binary compatible with GHC 6.2.2. Best, John Velman On Wed, Jan 12, 2005 at 04:16:33PM +0100, Dmitri Pissarenko wrote: Hello! I've downloaded wxHaskell, ran the wxhaskell-register.bat file and now try to build a minimal wxHaskell program. For this purpose, I tried to start GHCi using following command ghci -package wx GuiTest.hs GHCi crashed with following error messages: error-messages GHC Interactive, version 6.2.2, for Haskell 98. http://www.haskell.org/ghc/ Type :? for help. Loading package base ... linking ... done. Loading package haskell98 ... linking ... done. Loading package lang ... linking ... done. Loading package concurrent ... linking ... done. Loading package QuickCheck ... linking ... done. Loading package readline ... linking ... C:/ghc/ghc-6.2.2/HSreadline.o: unknown symbol `_rl_redisplay_function' ghc.exe: unable to load package `readline' /error-messages What am I doing wrong? TIA Dmitri Pissarenko PS: Here is the code of the application module Main where import Graphics.UI.WXCore main :: IO () main = run gui gui :: IO () gui = do frame - frameCreateTopFrame Hello World windowShow frame windowRaise frame return () -- Dmitri Pissarenko Software Engineer http://dapissarenko.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: implementation of functional languages
I am currently working my way through the tutorial book that has been online for some time. It is perhaps the most valuable book I have and I am really looking forward to reading this one. I would like to suggest we need more things like this - the Haskell cookbook is a great initiative, but I would love books on any number of other things. I find the conference papers are pitched just a little too high to be educational and are often very specific. One example of what I mean - I had looked at Haskell parser libraries and I know there were problems a, b and c and X was a solution to a, etc... However, I did not really understand how they worked - until I did the parser for the Core Language. Now it is all so clear! I am rambling a bit, but I am jut really pleased this has been made available. Matt On 11/01/2005, at 11:32 PM, Graham Klyne wrote: I think this is most welcome... I have the original printed version and have found it to be of great inspiration at various times. #g -- At 18:04 07/01/05 +, you wrote: I'm happy to announce that my out-of-print 1987 book, The Implementation of Functional Programming Languages is now available online at http://research.microsoft.com/%7Esimonpj/papers/slpj-book-1987/ index.htm Very many thanks to Marnie Montgomery, who did all the work. Happy reading Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: I/O interface
Marcin 'Qrczak' Kowalczyk wrote: Ben Rudiak-Gould [EMAIL PROTECTED] writes: The file interface in this library is only used for files, which are always seekable (by definition). What do you mean by files? What you get from open() is not always seekable [...] This was all discussed a year ago, and rather than reiterate it I'll try to expand the wiki page when I have a chance. Maybe all of this new discussion should be on the wiki also. -- Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: I/O interface
Simon Marlow wrote: I assumed that dup()'ing file descriptors would be enough to produce separate file pointers, but no. Question (for qrczak or the group at large): is there *any* way to get, without an exploitable race condition, two filehandles to the same file which don't share a file pointer? Is there any way to pass a filehandle as stdin to an untrusted/uncooperative child process in such a way that the child can't interfere with your attempts to (say) append to the same file? So you can only safely make a single stream from a File. I think we just need more kinds of streams. With regard to file-backed streams, there are three cases: 1. We open a file and use it in-process. 2. We open a file and share it with child processes. 3. We get a handle at process startup which happens to be a file. In case 1 there are no problems, and we should support multiple streams on such files. In case 2 we could avoid OS problems by creating a pipe and managing our end in-process. This would allow attaching child processes to arbitrary streams (e.g. one with a gzip filter on it, if we ever implement such a thing). In certain cases it might be possible to rely on OS support, but it seems fragile (if we create two child processes tied to two streams on the same file). Case 3 is the most interesting. In an ideal world I would argue for treating stdin/out/err simply as streams, but that's not practical. Failing that, if we have pread and pwrite, we should provide two versions of stdin/out/err, one of type InputStream/OutputStream and the other of type Maybe File. We can safely layer other streams on top of these files (if they exist) without interfering with the stream operation. The only thing we can't do with this interface is screw up the parent process by seeking the inherited handles. Can anyone come up with a case for allowing that in the high-level library? It can always be done through System.Posix. If we don't have pread and pwrite, we're screwed, but so is every other application on this badly broken OS. If we punt on the interference problem, we can implement a pread and pwrite that are atomic within our process, and go from there. We're no worse off than anyone else here. Unfortunately, Win9x lacks pread and pwrite. But anyone running Win9x is clearly willing to deal with much worse problems than this. Making multiple streams would require re-opening the file for each subsequent one, Windows Server 2003 has ReOpenFile, but no prior version of Win32 can do this, as far as I know. I don't know the *ix situation. With ReOpenFile we could implement a lot more of my original proposal, including a File type that really denoted a file (instead of a file access path). -- Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Hugs vs GHC (again)was: Re: Somerandomnewbiequestions
Marcin 'Qrczak' Kowalczyk wrote: File positions are not evil. They allow to treat files and devices in a uniform way. Indeed, file positions are exactly as evil as indices into shared memory arrays, which is to say not evil at all. But suppose each shared memory array came with a shared current index, and there was no way to create additional ones. Suppose you couldn't index the array by a local variable: instead, you had to store the local variable into the shared index register first, overwriting whatever was there before. If you only wanted to use the array as a source or sink for a single stream, that would be fine. In every other case, it would be awful. Even read-only sharing would require the invention of some sort of cooperative locking discipline, and if some process didn't respect the locking and couldn't be changed, read-only sharing would become impossible. That's just silly. The way to solve this problem is to decouple the index from the shared memory array. You can easily simulate the single-index behavior if that's what you want, but you also get a lot of additional functionality. -- Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: I/O interface
Ben Rudiak-Gould [EMAIL PROTECTED] writes: is there *any* way to get, without an exploitable race condition, two filehandles to the same file which don't share a file pointer? AFAIK it's not possible if the only thing you know is one of the descriptors. Of course independent open() calls which refer to the same file have separate file pointers (I mean the true filename, not /proc/*/fd/*). On Linux the current file position is stored in struct file in the kernel. struct file includes void *private_data whose internals depend on the nature of the file, in particular they can be reference counted. Among polymorphic operations on files in struct file_operations there is nothing which clones the struct file. This means that a device driver would have no means to specify how private_data of its files should be duplicated (e.g. by bumping the reference count). If my understanding is correct, it implies that the kernel has no way to clone an arbitrary struct file. Just don't use the current position of seekable files if you don't like it: use pread/pwrite. Is there any way to pass a filehandle as stdin to an untrusted/ uncooperative child process in such a way that the child can't interfere with your attempts to (say) append to the same file? You can set O_APPEND flag to force each write to happen at the end of file. It doesn't prevent the process from clearing the flag. If it's untrusted, how do you know that it won't truncate the file or just write garbage to it where you would have written something? If the file is seekable, you can use pread/pwrite. If it's not seekable, the concept of concurrent but non-interfering reads or writes is meaningless. I think we just need more kinds of streams. With regard to file-backed streams, there are three cases: 1. We open a file and use it in-process. 2. We open a file and share it with child processes. 3. We get a handle at process startup which happens to be a file. I disagree. IMHO the only distinction is whether we want to perform I/O at the current position (shared between processes) or explicitly specified position (possible only in case of seekable files). Neither can be emulated in terms of the other. In case 2 we could avoid OS problems by creating a pipe and managing our end in-process. It's not transparent: it translates only read and write, but not sendto/recvfrom, setsockopt, ioctl, lseek etc., and obviously it will stop working when our process finishes but the other does not. A pipe can be created when the program really wants this, but it should not be created autimatically whenever we redirect stdin/stdout/stderr of another program to a file we have opened. Case 3 is the most interesting. In an ideal world I would argue for treating stdin/out/err simply as streams, but that's not practical. Failing that, if we have pread and pwrite, we should provide two versions of stdin/out/err, one of type InputStream/OutputStream and the other of type Maybe File. We can safely layer other streams on top of these files (if they exist) without interfering with the stream operation. I'm not sure what do you mean. Haskell should not use pread/pwrite for functions like putStr, even if stdout is seekable. The current file position *should* be shared between processes by default, otherwise redirection of stdout to a file will break if the program delegates some work with corresponding output to other programs it runs. Indeed, file positions are exactly as evil as indices into shared memory arrays, which is to say not evil at all. But suppose each shared memory array came with a shared current index, and there was no way to create additional ones. Bad analogy: if you open() the file independently, the position is not shared. The position is not tied to a file with its shared contents but to the given *open* file structure. And there is pread/pwrite (on some OSes at least). It's not suitable as the basic API of all reads and writes though. -- __( Marcin Kowalczyk \__/ [EMAIL PROTECTED] ^^ http://qrnik.knm.org.pl/~qrczak/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Signature of a function
G'day all. Quoting Jules Bean [EMAIL PROTECTED]: I meant that, especially when you are figuring out a new language, getting the types inferred for you is helpful and also instructive... I strongly disagree with that. Certainly in Haskell, I found early on that putting in type signatures dramatically improved the quality of my type error messages. Cheers, Andrew Bromage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Signature of a function
Inferred types are helpful as a demonstration and exploration tool. Once you are writing programs, having the compiler infer types and check against your requirement is a fantastic bug finder. matt ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Signature of a function
Same here. I'm usually using explicit type declarations for (at least all exported) top-level functions. Michael On Thu, 13 Jan 2005 14:15:02 +1100, mattr [EMAIL PROTECTED] wrote: Inferred types are helpful as a demonstration and exploration tool. Once you are writing programs, having the compiler infer types and check against your requirement is a fantastic bug finder. matt ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
