- Glasgow-haskell-users

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

RE: -fspecialize-all or the like?
by Simon Marlow 22 Apr '02

22 Apr '02

> Is there any way to get your overloaded functions to > basically behave like > templates in C++; i.e., by "automatically" inserting {-# SPECIALIZE > ... #-} for every function, for every instance, for each type that is > actually used in the program? Short answer: no. Sorry :) Simon

1 0

Re: ghc-pkg info
by Ashley Yakeley 22 Apr '02

22 Apr '02

At 2002-04-21 12:52, Sven Panne 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 Right. I need to find the location of Rts.h. Ideally, I would do ghc-pkg -s rts --field="include_dirs" ...and look in each one (if there were more than one). Unfortunately that just returns "$libdir/include". It would be nice if either there were an option that expanded out the $libdir in fields, or else one that just returned $libdir. In the mean time, I'll pull it out of "ghc -v"... -- Ashley Yakeley, Seattle WA

1 0

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

21 Apr '02

> It would be nice if ghc-pkg had options to display the value > of $libdir > or at least the given conf file. I'm trying to get my > Autotools configure > script to find Rts.h, and it's a bit of a pain. My current > approach is to > use "readlink -f `which ghc`" and get it from there, but that > fails with > the latest MacOS X version because it uses small shell > scripts in unusual > places instead of symlinks. 'ghc -v' will tell you the location of package.conf, which for a normal GHC install is located in $libdir. Does that help? Cheers, Simon

2 1

realloc for I/MArrays
by Hal Daume III 19 Apr '02

19 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 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? i don't know enough about how UArrays are implemented in ghc to know if this is even reasonable, but if it's possible, can we expect to see something like this? :) - 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

1 0