- Glasgow-haskell-users

explicit signatures and default for integer literals
by Mirko Rahn 31 May '05

31 May '05

Hi all, an explicit given signature causes ghc to choose the right types for integer literals as in {-# OPTIONS -fglasgow-exts #-} import Data.Map f :: Ord a => [a] -> Map a Int f xs = fromList $ zip xs [0..] Here the Literal 0 is threated as (0::Int). But the setting {-# OPTIONS -fglasgow-exts #-} import Data.Map class New a b where new :: a -> b instance Ord a => New [(a,b)] (Map a b) where new = fromList g :: Ord a => [a] -> Map a Int g xs = new $ zip xs [0..] causes the error message Could not deduce (New [(a, b)] (Map a Int)) from the context (Ord a) arising from use of `new' at Why.hs:10:7-9 ghc seems to be unable to threat the Literal 0 as (0::Int) this time but I do not understand why :-( Can anyone explain it? Thanks, -- -- Mirko Rahn -- Tel +49-721 608 7504 -- --- http://liinwww.ira.uka.de/~rahn/ ---

6 11

Re: Are new sequences really O(1)?
by Marcin 'Qrczak' Kowalczyk 27 May '05

27 May '05

[moved from libraries to glasgow-haskell-users] Ross Paterson <ross(a)soi.city.ac.uk> writes: > GCs that happen during this process will be more expensive, as they > have to scan the stack. I suspect that GC costs are swamping > everything else for large n. I just tweaked the implementation GC in my compiler of my language, so that minor collection doesn't scan the whole stack, but only the part up to the deepest point where the stack pointer has been since the previous collection. Deeper regions contain only old pointers so they don't need to be scanned (I have only two generations). A program which builds a list of length 270,000 non-tail-recursively, which in a strict language leads to proportional usage of the stack, and performs on average 4kB of temporary allocations for each element, so there are 9,000 GCs in total with the young heap of 128 kB, runs 10 times faster after the change. GC takes 5% of the time instead of 88%. The implementation relies on the fact that only the topmost stack frame can be mutated, so it's enough to look only one frame deeper than the stack pointer reached. Each frame contained a pointer which is used only for GC and for stack trace printing, and thus it can be marked in the lowest bit without impacting normal operations. I prefer to make non-tail recursion efficient than to have to rewrite algorithms to use a large heap instead of the stack. -- __("< Marcin Kowalczyk \__/ qrczak(a)knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/

1 0

RE: Why hIsEOF wait for completely full buffer while hGetChar doesn't ?
by Simon Marlow 27 May '05

27 May '05

On 27 May 2005 03:33, Nobuo Yamashita wrote: > I am curious about reason why in GHC hIsEOF blocks in BlockBuffering > mode while hGetChar doesn't. > > I wrote following three programs for an experiment. > > -- echo0.hs > module Main where > import System.IO > main = hSetBuffering stdin (BlockBuffering (Just 5)) >> echo > echo = getChar >>= putChar >> hFlush stdout >> echo > > -- echo1.hs > module Main where > import System.IO > main = hSetBuffering stdin (BlockBuffering (Just 5)) >> echo > echo = do eof <- isEOF > if eof then return () > else getChar >>= putChar >> hFlush stdout >> echo > > -- as.hs > module Main where > import System.IO > import Control.Concurrent > main = putChar 'a' >> hFlush stdour >> threadDelay 1000000 >> main > > And run next two commandlines > > % runghc as.hs | runghc echo0.hs > % runghc as.hs | runghc echo1.hs > > I had expected that the both behaviors were same; a character > was output a second. But the former output a character a second, and > the latter output 5 characters a time every 5 seconds. Quite right, that's a bug, or at least an inconsistency. hGetChar used to wait for a completely full buffer before returning a character, but we changed it to return as soon as any data at all was available. However, we didn't change hIsEOF to match: it still waits for a completely full buffer. I've now fixed this. As it turns out, BlockBuffering doesn't really do full block buffering on an input Handle. The BlockBuffering size does specify the maximum amount of buffering performed, but all read operations return as soon as the required amount of data is available, without waiting for the buffer to completely fill up. This seems a lot more useful than strict block buffering. Thanks for a well-researched bug report! Cheers, Simon

1 0

RE: Contexts differ in length
by Simon Peyton-Jones 27 May '05

27 May '05

| 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). It's a sensible suggestion. Until now no one has said it actually stops them writing the program they want to write. Thanks for bringing it up again. It's not too hard to implement, and I'll try to get to it soon. It's in the same patch of the compiler as Ross's specialisation request, so I'll try to do both at once. Simon

3 2

Why hIsEOF wait for completely full buffer while hGetChar doesn't ?
by Nobuo Yamashita 27 May '05

27 May '05

Hello, I am curious about reason why in GHC hIsEOF blocks in BlockBuffering mode while hGetChar doesn't. I wrote following three programs for an experiment. -- echo0.hs module Main where import System.IO main = hSetBuffering stdin (BlockBuffering (Just 5)) >> echo echo = getChar >>= putChar >> hFlush stdout >> echo -- echo1.hs module Main where import System.IO main = hSetBuffering stdin (BlockBuffering (Just 5)) >> echo echo = do eof <- isEOF if eof then return () else getChar >>= putChar >> hFlush stdout >> echo -- as.hs module Main where import System.IO import Control.Concurrent main = putChar 'a' >> hFlush stdour >> threadDelay 1000000 >> main And run next two commandlines % runghc as.hs | runghc echo0.hs % runghc as.hs | runghc echo1.hs I had expected that the both behaviors were same; a character was output a second. But the former output a character a second, and the latter output 5 characters a time every 5 seconds. Are there any explanations ? Best regards. -- Nobuo Yamashita

1 0

[ ghc-Feature Requests-1209056 ] functions without implementations
by SourceForge.net 26 May '05

26 May '05

Feature Requests item #1209056, was opened at 2005-05-26 12:53 Message generated for change (Settings changed) made by c_maeder You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1209056&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open >Priority: 2 Submitted By: C Maeder (c_maeder) Assigned to: Nobody/Anonymous (nobody) Summary: functions without implementations Initial Comment: Allow to declare a function by only supplying its type signature. This feature shall enhance rapid prototyping by fixing an interface but leaving some functions unimplemented. Currently this can be (only) simulated by supplying dummy implementations, like f :: ... f = undefined Since it is possible to supply dummy data types by "data T" (not followed by "="), allowing functions without implementations seems almost to be a logical consequence. Surely, the compiler should emit warnings for missing implementations. It would be nice if such function declarations via type signatures could be repeated at any position within a module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1209056&group_…

1 0

[ ghc-Feature Requests-1209056 ] functions without implementations
by SourceForge.net 26 May '05

26 May '05

Feature Requests item #1209056, was opened at 2005-05-26 12:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1209056&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Submitted By: C Maeder (c_maeder) Assigned to: Nobody/Anonymous (nobody) Summary: functions without implementations Initial Comment: Allow to declare a function by only supplying its type signature. This feature shall enhance rapid prototyping by fixing an interface but leaving some functions unimplemented. Currently this can be (only) simulated by supplying dummy implementations, like f :: ... f = undefined Since it is possible to supply dummy data types by "data T" (not followed by "="), allowing functions without implementations seems almost to be a logical consequence. Surely, the compiler should emit warnings for missing implementations. It would be nice if such function declarations via type signatures could be repeated at any position within a module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1209056&group_…

1 0

Contexts differ in length
by Robert van Herk 24 May '05

24 May '05

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). Therefore, I will explain the problem again: I am writing (for my master's thesis project) a webdevelopment framework in Haskell, with features somewhat comparable to Apple's WebObjects. Amongst others, session state and database interaction is transparent, etc. In my framework, functions that generate HTML are called WFComponents. These functions are monadic since they can generate IO (because they may do database interaction etc). Also, components can generate links to other components. However, since component a may generate a link to component b (so that when the user clicks that link component b will be evaluated) and component b may link to component a, there will occur errors when I try to do this, since the contexts of component a and b may not be the same. A minimal example of this will be something like: {-# OPTIONS -fglasgow-exts #-} module Main where import Data.IORef class MyReader r v | r -> v where myRead :: r -> IO v data R v = R (IORef v) instance MyReader (R v) v where myRead (R v) = do v <- readIORef v return v a :: IO () a = do r <- createReader b r b :: MyReader r Int => r -> IO () b r = do i <- myRead r if i > 10 then a else putStrLn (show i) createReader :: IO (R Int) createReader = do ref <- newIORef 0 return (R ref) A real example will be a bit more complicated, but this is basically what I need to do and currently am not able to. Of course, when needed, I can show you the real example. Somewhere in the history of this mailling list I read that people have had this program before, but only in toy programs. However, I am experincing this problem currently in something that is not a toy program. Therefore, my question is if it would be possible to lift this constraint on the language, and also, if the developers of GHC are currently planning to do this... Thanks, Robert

2 1

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