Re: [ ghc-Feature Requests-1104381 ] Add wxHaskell link to homepage
Simon Marlow [EMAIL PROTECTED] writes: It's intentional, but it can be easily turned off. Do people want to see feature-requests, task-list entries and so forth on this mailing list, or should they be confined to, say, [EMAIL PROTECTED] I would vote to put them in a separate list. At least in the current form, it looks like an anonymous message with various URLs and auto-generated text, and not like something I expect from a -users mailing list. Alternatively, they could perhaps be formatted to resemble a more normal e-mail? IMHO, anyway. -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: [Haskell] [ANNOUNCE] New version of unicode CWString library withextras
On 19 January 2005 05:31, John Meacham wrote: A while ago I wrote a glibc specific implementation of the CWString library. I have since made several improvements: * No longer glibc specific, should compile and work on any system with iconv (which is unix standard) (but there are still glibc specific optimizations) * general iconv library for conversion to any other supported character sets * LocaleIO, a plug in replacement for many of the standard prelude and IO calls which transparently handle locale encoding. and best of all, it now has a darcs repository. http://repetae.net/john/recent/out/HsLocale.html It could still using some fleshing out, LocaleIO is still incomplete, I add to it as I need a function, but I figure I should make it available in case the CWString stuff came in handy for implementing the FFI spec for ghc. I'd like to get a correct CString implementation into GHC's libraries. I think the CWString implementation we have now is good enough, but CString should be doing locale encoding/decoding (as you know). At the same time, we should check all the withCString calls to see whether they should really be withCAString (since withCString is about to get quite a bit slower). Would you be interested in helping with this, or even putting together a patch? It's probably too late for 6.4, though. PS. is there a way to replace the top level error handler in ghc? (from a haskell library) I'd like to be able to print the error messages with the LocaleIO library as it is the only place where the wrong encoding still can leak out. There's no way to replace the handler, I'm afraid. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: debian ghci on sparc64
On 18 January 2005 21:01, William Lee Irwin III wrote: On 15 December 2004 14:46, William Lee Irwin III wrote: There seems to be some trouble with the debian ghci on sparc64. I can dredge up more information if given an idea of what to look for. On Tue, Jan 18, 2005 at 04:41:02PM -, Simon Marlow wrote: This turned out to be relatively straightforward. Two fixes: ghc-asm.lprl needs slight modifications for new versions of gcc on sparc-*-linux, and the dynamic linker also needs to have USE_MMAP enabled due to needing to execute dynamically allocated memory. I've made these fixes in the HEAD, and also merged them into the 6.2 branch. William: there's a fixed tree in /mnt/dm0/simonmar/ghc-6.2.2 on your sparc64 box. Great, thanks for fixing it up! I can make similar arrangements for the alpha issue, if desired. Are you referring to this bug? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=232727 If so, that's quite a bit of work - not 6.4 material I'm afraid. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: self-import
Good point, thank you! I'd forgotten that the OGI modules paper, which I read carefully at the time, covered recursion (Section 5.4). But my real point wasn't that it's impossible to define a meaning, only that the meaning might be a bit unexpected to a programmer, and involves a fixpoint calculation (which the paper indeed performs). It does also require the scope-resolver to process the whole of a strongly-connnected component of modules at a time, which GHC isn't set up to do. That's an engineering issue, not a semantic one, though. Simon | -Original Message- | From: Thomas Hallgren [mailto:[EMAIL PROTECTED] | Sent: 18 January 2005 22:12 | To: Simon Peyton-Jones; glasgow-haskell-users@haskell.org | Cc: [EMAIL PROTECTED] | Subject: Re: self-import | | Simon Peyton-Jones wrote: | | I quite liked this idea until I thought of this: | | module Doc.Pretty.Long( M.f, f ) where |import qualified M( f ) |import Doc.Pretty.Long as M | |f x = x | | The second import decl imports all the things exported by | Doc.Pretty.Long. But what does it export? Well, M.f. But what is M.f. | Well, it could be the f coming from 'import M.f'. But wait! | Doc.Pretty.Long exports the locally-defined f too... and the second | import decl will make that be called M.f too. | | | Our module system paper has answers to this type of questions, since it | deals with the meaning of recursive modules: | | http://www.cse.ogi.edu/~diatchki/hsmod/ | | It is implemented in the Programatica Haskell front-end, which thus | supports modules importing themselves in particular, and mutually | recursive modules in general, without the need for boot .hi files. I | wonder when other Haskell implementations are going to catch up? :-) | | -- | Thomas H ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: package installation
On 17 January 2005 22:53, Sean Bowman wrote: I'm trying to install HUnit to use with ghci and hugs and having some trouble. It works if I use the -i option with ghci, but I'd rather not have to specify that on the command line every time. Putting it in a ~/.ghci file doesn't seem to work. How can I set the search path for 3rd party Haskell modules? You have two choices: use the -i option, or make a package. The right way to use 3rd party libraries is to make a package. We're making it easier to build packages with Cabal (http:///www.haskell.org/cabal/). Incedentally, GHC 6.4 will come with HUnit. And I believe there's a Cabal version floating around somewhere that should install with GHC 6.2.2. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Implicit parameters:
Question regarding implicit parameters... The GHC manual says: Dynamic binding constraints behave just like other type class constraints in that they are automatically propagated. But the following code produces an error: - main = do var - newIORef (0::Int) let ?global_counter = var in f f = do a - get_unique putStr (showInt a \n) b - get_unique putStr (showInt b \n) c - get_unique putStr (showInt c \n) get_unique :: (?global_counter :: IORef Int) = IO Int get_unique = readIORef ?global_counter -- If (?global_counter :: IORef Int) were a class constraint the type signature for 'f' could be derived automatically... but we get: Unbound implicit parameter (?global_counter::IORef a) arising from use of `get_unique' at Test.hs:17:13-22 Is this a bug? Is there some reason why this is not possible? (and if it is not possible shouldn't the documentation be changed to reflect this)... Keean. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC on Arm
Hello, I would like to port GHC to Arm so that I can compile Haskell programs for use on my Zaurus or in Debian's ARM port. I have talked to Ian Lynagh about this, and he believes that there was some sort of problems with floats. I don't know exactly that was, if it was in gcc or ghc, or if it has been fixed. Does anybody have some light to shed on this? Also, does anybody have any ARM binaries of ghc to ease the bootstrapping pain? Thanks! ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Implicit parameters:
Isn't it just the monomorphism restriction at work? This works fine: f () = do a - get_unique putStr (showInt a \n) b - get_unique putStr (showInt b \n) c - get_unique putStr (showInt c \n) get_unique :: (?global_counter :: IORef Int) = IO Int get_unique = readIORef ?global_counter J.A. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Implicit parameters:
Yes, adding -fno-monomorphism-restriction allows the example to compile. I guess I got confused by the error message, expecting it to mention the monomorphism restriction directly... I'm sure it does sometimes. Any chance of improving the error message for this? Jorge Adriano Aires wrote: Isn't it just the monomorphism restriction at work? This works fine: ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
