May 2005 - Glasgow-haskell-users

RE: runInteractiveProcess, confused
by Simon Marlow 24 May '05

24 May '05

On 18 May 2005 14:47, Frederik Eaton wrote: > When I run the following line in ghci: > > Prelude System.Process Control.Concurrent System.IO> do { (inp, out, > err, ph) <- runInteractiveProcess "cat" [] Nothing Nothing; forkIO > (do hPutStr inp "this\nis\na\ntest\n"; hClose inp); waitForProcess ph > } > > ... it doesn't terminate. I'm following the example in the > System.Process documentation. But I would think that since I close > 'inp', "cat" would terminate. Also, I don't see the expected output. This example won't work inside GHCi, because GHCi isn't compiled with -threaded: the -threaded option is required to get a version of waitForProcess that doesn't block other threads in a multithreaded program. The only reason GHCi isn't compiled with -threaded is because I'm being conservative; the threaded RTS introduces a lot more complexity and hasn't been shaken down as much as the single-threaded RTS. If you compile GHC up yourself you can fix it by adding "GhcStage2HcOpts += -threaded" to mk/build.mk before building. In a future release of GHC we'll do this by default. Cheers, Simon

1 0

Re: ghc bugs
by Robert van Herk 24 May '05

24 May '05

Serge D. Mechveliani wrote: >>Hi all, >> >>A while ago I sent an email to the glasgow haskell users maillinglist to >>explain how the "Contexts differ in length" feature (or bug :-)) >>restricted me in writing a haskell application. I was hoping for a >>reply, however I didn't receive one (yet). >> >>[..] >> >> > >In my experience, glasgow-haskell-bugs(a)haskell.org > >usually replies to bug reports (maybe, within a couple of weeks). > > I see, but this was "on of them bugs" that could be called "feature" :-). Actually, I think it is a overrestrictive constraint in the Haskell 98 language definition, which I am hoping that the Simons will lift :-). Robert

1 0

RE: GHC Win32 ffi functions as implemented for Pugs
by Simon Marlow 23 May '05

23 May '05

On 22 May 2005 23:32, Max Maischein (Corion) wrote: > The file is (live version) : > > http://svn.openfoundry.org/pugs/src/Pugs/Compat.hs > > The implemented wrappers that are functional and not just stubs are > (as of r3680) : > > For System.Environment: > setEnv :: String -> String -> Bool -> IO () > getEnv :: String -> IO (Maybe String) > unsetEnv :: String -> IO () System.Environment.getEnv should work on Win32. For the others, it would possibly make sense to include these in System.Environment, with implementations for both Unix & Win32. > For Posix.Process > getProcessTimes :: IO ProcessTimes > getProcessID :: IO Int Should probably be in System.Win32 somewhere. > The code itself is dual-licensed under the Artistic License and GPL > and thus should be compatible with whatever license GHC uses. Unfortunately we can't take code under that license into our existing packages - the rule is that each package has a single license, and currently all the packages distributed with GHC have a BSD3 license, with the exception of readline. You can start new packages, of course. > Hope you find my code useful, Contributions are always welcome, even if we can't use the code directly. You've pointed out things that the standard libraries lack. Thanks! Cheers, Simon

3 2

RE: cvs commit: fptools/ghc/compiler/hsSyn HsUtils.lhs fptools/ghc/compiler/typecheck TcRnDriver.lhs TcRnMonad.lhs TcUnify.lhs
by Simon Marlow 23 May '05

23 May '05

On 22 May 2005 14:17, Jim Apple wrote: > Simon Peyton Jones wrote: > >> - For command-line 'let' and 'x<-e' forms, if exactly one variable >> is bound, we print its value if it is Showable and not () >> prompt> let x = 4 4 >> prompt> x <- return 5 >> 5 > > prompt> let ones = [1:x] > > What am I to do if I want ones set, but not printed? I think you mean let ones = 1:ones but it's a good point. At the moment you can hack around it with let ones = 1:ones; x=x (for example). Simon: I think let bindings should be exempt from the new auto-show behaviour. The docs currently say that let doesn't evaluate its rhs: An important difference between the two types of binding is that the monadic bind (p <- e) is strict (it evaluates e), whereas with the let form, the expression isn't evaluated immediately: and the example that follows that paragraph is currently wrong (the let binding will yield an exception). Cheers, Simon

1 0

RE: error in your article? about meaning of safe/unsafe in "foreignimport"
by Simon Marlow 23 May '05

23 May '05

Yes, I think that sentence in the awkward squad paper is incorrect. The "unsafe" annotation on foreign import is not related to the purity of the function being called, it is the omission of 'IO' on the return type that indicates intended purity. Cheers, Simon On 19 May 2005 16:39, Bulat Ziganshin wrote: > Hello Peter, > > Sunday, May 15, 2005, 4:07:28 PM, you wrote: > >> http://research.microsoft.com/Users/simonpj/papers/marktoberdorf/ > > this article says that > > -------------------------------------------------- > some foreign procedures may cover have purely-functional semantics. > For example, > the C sin function really is a function: it has no side effects. In > this > case it is extremely tiresome to force it to be in the IO monad. So > the Haskell FFI > allows one to use the unsafe keyword, and omit the ``IO'' from the > return type, thus: > > foreign import ccall unsafe sin :: Float -> Float > > As in the case of unsafePerformIO (Section 2.6), ``unsafe'' indicates > that the programmer > takes on a proof obligation, in this case that foreign procedure is > genuinely functional. > -------------------------------------------------- > > > > while the FFI specification state that > > -------------------------------------------------- > Optionally, an import declaration can specify, after the calling > convention, the safety level that should be used when invoking an > external entity. A safe call is less efficient, but guarantees to > leave the Haskell system in a state that allows callbacks from the > external code. In contrast, an unsafe call, while carrying less > overhead, must not trigger a callback into the Haskell system. If it > does, the system behaviour is undefined. The default for an > invocation is to be safe. Note that a callback into the Haskell > system implies that a garbage collection might be triggered after an > external entity was called, but before this call returns. > Consequently, objects other than stable pointers (cf. Section 5.6) > may be moved or garbage collected by the storage manager. > -------------------------------------------------- > > > and one more question: is it possible to download sources of http > server mentioned in this article? i want to browse the code, it's no > matter how it compiles and works

1 0

GHC Win32 ffi functions as implemented for Pugs
by Max Maischein (Corion) 22 May '05

22 May '05

Hello all, I have been working on Pugs, the current Perl6 interpreter, and have been hacking on Win32 compatibility. For that, I've written some wrappers around native Win32 API calls using the very convenient FFI that GHC 6.4 provides! I wonder if you want to include the functions in GHC, as they are missing on Win32. Autrijus Tang pointed me to this list. The file is (live version) : http://svn.openfoundry.org/pugs/src/Pugs/Compat.hs The implemented wrappers that are functional and not just stubs are (as of r3680) : For System.Environment: setEnv :: String -> String -> Bool -> IO () getEnv :: String -> IO (Maybe String) unsetEnv :: String -> IO () For some other module: statFileSize :: FilePath -> IO Integer For Posix.Process getProcessTimes :: IO ProcessTimes getProcessID :: IO Int The code implementing them is inefficient and crude, partly because I speak Haskell with a quite perlish lisp, and partly because I used the first implementation that worked, so I like to hear about implementing them in better style, or, even better that you choose to accept them into GHC so I don't have to worry about them anymore. The code itself is dual-licensed under the Artistic License and GPL and thus should be compatible with whatever license GHC uses. Hope you find my code useful, -max PS: If this message went to the wrong list, please tell me so and also tell me where the message should go to! PPS: Please CC me on the replies as I won't stay subscribed long.

1 0

Re: cvs commit: fptools/ghc/compiler/hsSyn HsUtils.lhs fptools/ghc/compiler/typecheck TcRnDriver.lhs TcRnMonad.lhs TcUnify.lhs
by Jim Apple 22 May '05

22 May '05

Simon Peyton Jones wrote: > - For command-line 'let' and 'x<-e' forms, if exactly one variable > is bound, we print its value if it is Showable and not () > prompt> let x = 4 > 4 > prompt> x <- return 5 > 5 prompt> let ones = [1:x] What am I to do if I want ones set, but not printed? Jim

1 0

Deprecate an instance
by Jon Fairbairn 20 May '05

20 May '05

Would it be possible to extend the DEPRECATED pragma to allow one to deprecate an instance of a class? I was thinking about the recent discussion of APIs on haskell-cafe, where Jérémy Bobbio complained about using Booleans as arguments to libaray functions, preferring instead sensibly named data constructors. It occurred to me that by defining a class one could allow both the old interface and a better one by using a class: module Main where -- suppose f used to be Bool -> Int -> Int, replace it -- with this: f :: Toggle t => t -> Int -> Int f t x = case enabled t of Invert -> -x DontInvert -> x data DoInvert = Invert | DontInvert class Toggle t where enabled :: t -> DoInvert instance Toggle DoInvert where enabled = id instance Toggle Bool where enabled True = Invert enabled False = DontInvert but for this to be any real use, we'd have to be able to deprecate the /instance/ Toggle Bool. -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk

1 0

MPC with fundeps: ghc-6.2.2 vs ghc-6.4
by Christian Maeder 20 May '05

20 May '05

Hi, the following (reduced) example used to go through with ghc-6.2.2 but fails with ghc-6.4. Which behaviour is correct? I compile with: ghc -fglasgow-exts Context.hs module Context where class Language a class Language a => Logic a b | a -> b class (Language a, Logic b c, Logic d e) => Comorph a b c d e | a -> b, a -> d instance (Comorph a1 b1 c1 d1 e1, Comorph a2 b2 c2 d2 e2) => Language (a1, a2) instance (Comorph a1 b1 c1 d1 e1, Comorph a2 b2 c2 d2 e2) => Comorph (a1, a2) b1 c1 d2 e2 -- end of module ghc-6.4 (or ghc-6.4.1) complains with: Context.hs:11:0: Could not deduce (Comorph a2 b2 c21 d2 e21, Comorph a1 b1 c11 d1 e11) from the context (Comorph a1 b1 c1 d1 e1, Comorph a2 b2 c2 d2 e2) arising from the superclasses of an instance declaration at Context.hs:11:0 Probable fix: add (Comorph a2 b2 c21 d2 e21, Comorph a1 b1 c11 d1 e11) to the instance declaration superclass context In the instance declaration for `Comorph (a1, a2) b1 c1 d2 e2' If I replace the first instance with "instance (Language a1, Language a2) => Language (a1, a2)" then ghc-6.4 is happy. Cheers Christian

1 0

not.hDuplicate
by Bulat Ziganshin 20 May '05

20 May '05

Hello glasgow-haskell-users, my program contaions several forkOSed threads and at one moment one thread gives to another handle of open file. i need to read some data from this file. how can i accomplish this? if i use hDuplicate, then both handles will share the same file pointer, so threads will mess each other. are there some way to duplicate handle with creating separate file pointer, or to get filename from the Handle, or (preferable) to block another thread's on attempt to access the same handle until i done with it and return to old file pointer? -- Best regards, Bulat mailto:bulatz@HotPOP.com

3 7