- Glasgow-haskell-users

RE: module namespaces with "Prelude"
by Simon Marlow 25 Apr '02

25 Apr '02

> On Thursday, April 25, 2002, at 11:30 , Simon Marlow wrote: > > >> All in all, dropping all implicit directories from the search > >> path gets my vote. > > > > "me too". > > > > I wasn't aware that Hugs did this, and GHCi certainly doesn't. It's > > reasonable to leave "." in the default search path, but adding an > > implicit root for an imported module will certainly lead to > trouble - > > after all, we use hierarchical module names because the > modules at the > > leaves of the tree are expected to overlap. > > But it is this "." in the default path that is the reason GHCi > gives unexpected results, isn't it? [See Hal Daume's original > bug report] Well, that depends what you mean by unexpected - IMHO the behaviour is entirely reasonable and is well documented. Let's recap: the directory structure is something like this (using $$ to represent an arbitrary path): $$/Bar/Foo.hs contains module Bar.Foo $$/Bar/IO.hs contains module Bar.IO now if the current directory is $$, then Bar.Foo and Bar.IO map to the correct filenames/modules. However, if the current directory is $$/Bar, as it was in Hal's example, then module IO maps to both ./IO.hs and the IO module in the standard library. Clearly there's an overlap, and the solutaion is not to sit in $$/Bar, or to explicitly remove "." from the default search path (which you can do in ghc by giving a -i option without any arguments). If one root is a subdirectory of another root, then you have an overlap. Clearly, the "implicit roots" mechanism will always lead to overlap, so it can't be the right thing to do. Unfortunately it isn't easy to detect whether the user-specified roots are overlapped and issue a warning, but I think the rule is fairly straightforward to understand. It would be possible to detect whether a module maps to more than one filename though - perhaps we should do that. Cheers, Simon

2 1

RE: order of computation in 'do' notation
by Rich 25 Apr '02

25 Apr '02

Thanks very much everyone! I added the line "hFlush stdout" to the code and it works fine now - thanks for your help! Rich.

1 0

order of computation in 'do' notation
by Rich 25 Apr '02

25 Apr '02

Hi, I have to hand in my final project for my degree next week. I've been running my program through hugs most of the time, and I wanted to compile it to an executable, so I used ghc. Unfortunately ghc makes the program behave in a different, undesirable way. The code where the problem lies is shown below. Basically, in hugs, the prompt ">> " is displayed and then it waits for a command to be entered (getCommand) - which is what I want, but when I put the same code through ghc, it waits for a command first, and then when the command has been entered it displays the prompt, which is just silly. Surely the 'do' notation was designed to sequence computations, but it obviously isn't behaving quite right here! I'd be very grateful for any suggestions as to how to fix this. thanks, Rich. mainLoop :: IO TRS -> IO () mainLoop t = do putStr "\n>> " (c,a) <- getCommand 0 case c of "help" -> do putStr help mainLoop t "load" -> do trs <- load a putStr "" mainLoop (return trs) "show" -> ...and so on... And then the getCommand function is as follows: -- gets a command from the standard input getCommand :: Int -> IO (String,String) getCommand _ = do com <- getLine return (splitComm com) -- splits a command into the main command and arguments splitComm :: String -> (String,String) splitComm [] = ("","") splitComm (' ':cs) = ("",cs) splitComm (c:cs) = ((c:rest),rem) where (rest,rem) = splitComm cs

2 1

RE: misplaces SPECIALISE
by Simon Peyton-Jones 24 Apr '02

24 Apr '02

The SPECIALIZE instance pragma must be in the instance decl itself: instance (TrieKey key, Binary elem) => Binary (Trie key elem) where put_ h (Trie e arr) = put_ h e >> put_ h (assocs arr) get h = get h >>= \e -> get h >>= \a -> return (Trie e (listArray (0,255) a)) {-# SPECIALIZE instance Binary (Trie Token Double) #-} The documentation is wrong in the current web page, but it's right in the HEAD so it'll percolate to the web in due course. Simon | -----Original Message----- | From: Hal Daume III [mailto:hdaume@ISI.EDU] | Sent: 23 April 2002 15:43 | To: Simon Peyton-Jones | Cc: GHC Users Mailing List | Subject: RE: misplaces SPECIALISE | | | Here is sufficient code, using ghc5.02.1 for solaris: | | module Test where | | import Util.Binary -- this is the GHC binary distribution import | PrelWord import Array | | newtype Token = Token [Word8] | | class TrieKey key where | mkKey :: key -> [Word8] | unKey :: [Word8] -> key | | data Trie key elem = Trie !(Maybe elem) (Array Word8 (Maybe (Trie key | elem))) | | instance (TrieKey key, Binary elem) => Binary (Trie key elem) where | put_ h (Trie e arr) = put_ h e >> put_ h (assocs arr) | get h = get h >>= \e -> get h >>= \a -> return (Trie e (listArray | (0,255) a)) | {-# SPECIALIZE instance Binary (Trie Token Double) #-} | | | wherever I put the specialize pragma, it complains: | | /nfs/isd/hdaume/projects/Test.hs:18: | Misplaced SPECIALISE instance pragma: | {-# SPECIALIZE instance {Binary (Trie Token Double)} #-} | | I also tried something like (I don't have the 100% correct code but | something like): | | putTDT :: BinHandle -> Trie Token Double -> IO () | putTDT h (Trie e arr) = put_ h e' >> put_ h (assocs arr) | where e' = case e of {Nothing->0; Just x->x} | and a corresponding "getTDT" then: | | {-# SPECIALIZE put_ :: BinHandle -> Trie Token Double -> IO | () = putTDT #-} | | and the corresponding for get, but it complained with a parse error on | "=" | | - Hal | | -- | Hal Daume III | | "Computer science is no more about computers | hdaume(a)isi.edu | than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume | | On Mon, 22 Apr 2002, Simon Peyton-Jones wrote: | | > It is really hard to help you if you don't supply the | context. Which | > version of GHC? Send the code for Trie.lhs. etc. | > | > Otherwise we're all guessing. | > | > Simon | > | > | -----Original Message----- | > | From: Hal Daume III [mailto:hdaume@ISI.EDU] | > | Sent: 22 April 2002 23:46 | > | To: GHC Users Mailing List | > | Subject: misplaces SPECIALISE | > | | > | | > | /nfs/isd/hdaume/projects/NLP/Trie.lhs:162: | > | Misplaced SPECIALISE instance pragma: | > | {-# SPECIALIZE instance {Binary (Trie Token Double)} #-} | > | Failed, modules loaded: NLP.NLPPrelude, Util.BinUtil, Util.Binary, | > | NLP.HashMap, Util.ShrinkString, Util.FastMutInt, NLP.Util. | > | | > | | > | what does that mean? | > | | > | -- | > | Hal Daume III | > | | > | "Computer science is no more about computers | hdaume(a)isi.edu | > | than astronomy is about telescopes." -Dijkstra | | > | www.isi.edu/~hdaume | > | | > | _______________________________________________ | > | Glasgow-haskell-users mailing list | > | Glasgow-haskell-users(a)haskell.org | > | http://www.haskell.org/mailman/listinfo/glasgow-| haskell-users | > | | > | |

1 0

RE: module namespaces with "Prelude"
by Simon Marlow 23 Apr '02

23 Apr '02

> It happens in Hugs, too, but somewhat differently. Here's a > test case. > > Go to /foo and do mkdir Bar. In Bar, create IO.hs and make > its contents: > > module Bar.IO where > > then also in Bar create Foo.hs > > module Bar.Foo where > import IO > > Then when in directory Bar load ghci (using 5.02.1) and load > Bar.Foo and > you'll get: > > IO.hs: file name does not match module name `IO' This is the defined behaviour. I'm aware that we haven't documented the behaviour yet, but we will do for the next version of GHC. Briefly, if the search path contains directories D1..Dn, and there is an import requesting a module A.B.C, then GHC will look for the module first in D1/A/B/C.{hs,lhs}, then D2/A/B/C.{hs,lhs}, and so on. If the contents of the file is actually not the required module, then GHC issues a complaint. I think Hugs is slightly more liberal in that it also allows the module to be in a file called A.B.C.hs, but apart from that I believe that GHC, Hugs, and nhc98 will all have similar behaviour (for a change!). The advantage of the current story is that it is simple: the language specification doesn't have to mention hierarchical modules at all, apart from allowing the '.' character in a module name. There are some disadvantages to this scheme, eg. it isn't easy to move a subtree of modules from one place in the hierarchy to another, so it might be desirable to extend this to a more flexible scheme in the future. Cheers, Simon

1 0

RE: misplaces SPECIALISE
by Simon Peyton-Jones 23 Apr '02

23 Apr '02

It is really hard to help you if you don't supply the context. Which version of GHC? Send the code for Trie.lhs. etc. Otherwise we're all guessing. Simon | -----Original Message----- | From: Hal Daume III [mailto:hdaume@ISI.EDU] | Sent: 22 April 2002 23:46 | To: GHC Users Mailing List | Subject: misplaces SPECIALISE | | | /nfs/isd/hdaume/projects/NLP/Trie.lhs:162: | Misplaced SPECIALISE instance pragma: | {-# SPECIALIZE instance {Binary (Trie Token Double)} #-} | Failed, modules loaded: NLP.NLPPrelude, Util.BinUtil, | Util.Binary, NLP.HashMap, Util.ShrinkString, Util.FastMutInt, | NLP.Util. | | | what does that mean? | | -- | Hal Daume III | | "Computer science is no more about computers | hdaume(a)isi.edu | than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-| haskell-users |

2 1

misplaces SPECIALISE
by Hal Daume III 22 Apr '02

22 Apr '02

/nfs/isd/hdaume/projects/NLP/Trie.lhs:162: Misplaced SPECIALISE instance pragma: {-# SPECIALIZE instance {Binary (Trie Token Double)} #-} Failed, modules loaded: NLP.NLPPrelude, Util.BinUtil, Util.Binary, NLP.HashMap, Util.ShrinkString, Util.FastMutInt, NLP.Util. what does that mean? -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

1 0

RE: ANNOUNCE: GHC 5.03.20020410 snapshot released
by Simon Peyton-Jones 22 Apr '02

22 Apr '02

| Do I have to hoist the forall quantifiers in bla -> forall a | . blub myself? At least, the code typechecks then. Sigh. I forgot to make the forall-hoisting feature apply recursively when I added the rank-N stuff. It's a 2 line change to make it so, but it is a change. Workaround: do the forall-hoisting yourself. Sorry. Simon

1 0

RE: ghc-pkg info
by Simon Marlow 22 Apr '02

22 Apr '02

> Simon Marlow wrote: > > >>It would be nice if ghc-pkg had options to display the value > >>of $libdir or at least the given conf file. [...] > > > I had *major* pains with this for the upcoming HOpenGL > release, too. :-P Well, I must admit we didn't anticipate that folk would actually want to know what the value of $libdir was - indeed the whole point of the exercise was to abstract away from the actual value so that you could install a GHC tree wherever you like and just change one thing, $libdir (this was part of making the installation process more painless on Windows). On Windows, the value of $libdir is (I believe) not even stored anywhere - it is derived from the location of the ghc.exe binary. > > 'ghc -v' will tell you the location of package.conf, which > for a normal > > GHC install is located in $libdir. Does that help? > > Ooops, never noticed that. Since when (GHC x.y) has this been > working? Since 5.00, I think. > Is this the "official" way? Well, there isn't really an official way, but we'll continue to output this as part of ghc -v if that would help. > IMHO it's quite important, because due to the heavy > inter-module optimizations, packages are closely tied to a > specific GHC version, > so $libdir is the only sensible place for package installation. I don't think I agree that external packages should be installed in GHC's $libdir - by all means include the GHC version in the directory name, but I don't see the need to actually place the files in GHC's installation area. Cheers, Simon

1 0

RE: realloc for I/MArrays
by Simon Marlow 22 Apr '02

22 Apr '02

> Any chance IArrays (or MArrays) will some day support something like: > > resize :: (Ix ix, IArray a e) => > a ix e -> (ix,ix) -> a ix e > > that is faster than allocating a new array and then copying > value-by-value? perhaps make the result a Maybe (a ix e) in > the same way > that realloc can return null if it can't get you more memory > at the end I suspect that this would be unlikely to be much use, due to GHC's discontiguous block scheme for managing memory. The best you could hope for in most cases would be to fill up the slop in the block of memory at the end of the array. > or even just a simple memcpy like function so you could allocate a new > array with the same index and element type and then copy > directly from one > to the other, like: > > arrcopy :: (Ix ix, IArray a e) => > (ix -> ix) -> a ix e -> a ix e -> a ix e > > which can possibly fail if the indices for the destination > don't line up > with the source properly? Doing it by hand *should* result in efficient code, eg. let copyElt i = do x <- readArray a1 i witeArray a2 i x sequence_ [ copyElt i | i <- indices a1 ] should result in a memcpy (or at least a tight loop) for UArrays with Int indices. (it might not though - I recall there are some problems with optimisation of array ops at the moment). Cheers, Simon

1 0