RE: Compiling mutually recursive modules involving instances
The best thing to do is never to put an instance declaration in an hi-boot file. I don't think you ever really need to. In contrast, mutual recursion of type declarations is often unavoidable. The manual should really say this Simon | -Original Message- | From: José Romildo Malaquias [mailto:[EMAIL PROTECTED]] | Sent: 24 October 2000 16:00 | To: [EMAIL PROTECTED] | Subject: Compiling mutually recursive modules involving instances | | | Hello. | | I am having difficulties in compiling mutually recursive | modules involving classes and instances in GHC 4.08.1. | Basicaly I am not finding how to write a .hi-boot where | I want to put classes and instances. | | Consider a program with 3 modules: M1, M2 and Main. The | sources are attached to the message. What should go | into M2.hi-boot? Would anyone write M2.hi-boot for me | so that I can learn it. | | Thanks. | | Romildo | -- | Prof. José Romildo Malaquias [EMAIL PROTECTED] | Departamento de Computação | Universidade Federal de Ouro Preto | Brasil | ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
getContents
I don't really understand getContents. (Does anyone?) I have some code here (far too large to submit). If I do (on Linux, ghc4.08.1, both with and without optimisation) -- contents - hGetContents handle seq (last contents) (hClose handle) -- the code works. However I looked at the manual and it seems that hClose should force the whole of contents to be read anyway. So I changed it to -- contents - hGetContents handle hClose handle -- and then the code doesn't work. If these are meant to be the same, then we have a GHC bug. If not, could someone explain in words of one syllable why not? PS - if you want the source code you'll have to download and compile the whole of UniForM!! ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Compiling mutually recursive modules involving instances
On Thu, Oct 26, 2000 at 01:50:30AM -0700, Simon Peyton-Jones wrote: The best thing to do is never to put an instance declaration in an hi-boot file. I don't think you ever really need to. In contrast, mutual recursion of type declarations is often unavoidable. I believe I can redesign the module structures in my project so that the instances will not need to be put in a hi-boot file. The body of some methods in these instances uses some names (type names and function names, possibly with infix status) defined in a module where the corresponding class __and__ a relevant set of its instances should be visible. Logicaly the instances do not belong to the same module as their class and the user of my library should be able to add new modules (with new instances of the class) to the system without the need to modify the source of the module containing the class definition. Particularly I am having a great difficult in find a good module design for my library, which is should be able to be extended by its user. I am missing some important features for that, like extensible data types and functions support in the language. By now I am basing it on the extensible union types shown in "Monad Transformers and Modular Interpreters", by Mark Jones and others. When I progress in that I would make some comments. The manual should really say this The manual also says a new, better, higher level way for dealing with mutually recursive modules is in the works. Is there any chance it will be ready for the next release? | From: José Romildo Malaquias [mailto:[EMAIL PROTECTED]] | | I am having difficulties in compiling mutually recursive | modules involving classes and instances in GHC 4.08.1. | Basicaly I am not finding how to write a .hi-boot where | I want to put classes and instances. | | Consider a program with 3 modules: M1, M2 and Main. The | sources are attached to the message. What should go | into M2.hi-boot? Would anyone write M2.hi-boot for me | so that I can learn it. Regards, Romildo -- Prof. José Romildo Malaquias [EMAIL PROTECTED] Departamento de Computação Universidade Federal de Ouro Preto Brasil ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: getContents
I don't really understand getContents. (Does anyone?) I have some code here (far too large to submit). If I do (on Linux, ghc4.08.1, both with and without optimisation) -- contents - hGetContents handle seq (last contents) (hClose handle) -- the code works. However I looked at the manual and it seems that hClose should force the whole of contents to be read anyway. So I changed it to -- contents - hGetContents handle hClose handle -- and then the code doesn't work. If these are meant to be the same, then we have a GHC bug. If not, could someone explain in words of one syllable why not? PS - if you want the source code you'll have to download and compile the whole of UniForM!! Using hClose on a semi-closed handle is a Bad Thing. The Haskell Report says: "Once a semi-closed handle becomes closed, the contents of the associated stream becomes fixed, and is the list of those items which were succesfully read from that handle". So I take this to mean that when you hClose a semi-closed handle, you get a random amount of data in the handle which depends on how good your compiler's strictness analyser is. yesno? Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: getContents
contents - hGetContents handle seq (last contents) (hClose handle) vs. contents - hGetContents handle hClose handle However I looked at the manual and it seems that hClose should force the whole of contents to be read anyway. If some manual says this, it is wrong. The Haskell Report says that 'hGetContents' gives the handle a special status, called "semi-closed". A semi-closed handle becomes fully closed when 'hClose' is applied to it. When this occurs, the contents of the associated stream of characters (i.e. those returned by 'hGetContents') is truncated, and is the list of characters that have already been read from that handle. Regards, Malcolm ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: getContents
Simon Marlow wrote: [snip] "Once a semi-closed handle becomes closed, the contents of the associated stream becomes fixed, and is the list of those items which were succesfully read from that handle". [snip] Ah, now I see. I had assumed that hClose'ing a semi-closed handle would result in the entire file being read till EOF, after which the file would be closed. Thanks. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
