- Glasgow-haskell-users

strip effect
by Andre W B Furtado 23 Feb '02

23 Feb '02

What is the effect of using the "strip" command with the files generated by ghc (besides reducing the file size)? -- Andre

1 0

Does GHC simplify RULES?
by Josef Svenningsson 21 Feb '02

21 Feb '02

Hi! A question about the RULES pragma. Suppose I have the following RULES pragma: {-# RULES "foo" forall a . foo a = (\x -> bar x) a #-} Ok, it's stupid but I have examples where this is motivated, trust me. Now, it seems that GHC simplifies the rule because what I get when compiling it with -ddump-rules is the following rule: "foo" __forall {@ t_a2UD a :: t_a2UD} Test.foo @ t_a2UD a = Test.bar @ t_a2UD a ; It's \beta-reduced! Argh! Why is that? So why is this a problem? Maybe I should give some explanation. The reason is that I want to put a type signature on the (\x -> bar x) and make it more general (i.e. forcing GHC to insert a type lambda after a lambda). I then have other rules which match on higher ranked types. But in order for these rules to apply the type lambda must be in the right place. One other thing I tried in order to get the type lambdas on the right place was to use rank 1 types (is that the correct name?): xyzzy :: (a -> a) -> (forall b. b -> b) but GHC simplified the type and just put the forall quantified (and hence the type lambda) on the top level. Argh again! Is there a way around this? /Josef

1 0

RE: i368-pc-os2-emx port
by Simon Marlow 21 Feb '02

21 Feb '02

> On Wed, 20 Feb 2002, Simon Marlow wrote: > > > I don't know enough about ODIN to be able to usefully comment, apart > > from to say that extra layers of translation generally add extra > > layers of complication (we've had no end of trouble with > cygwin/mingw > > on Win32), and in this case you'd be going through 2 layers (mingw + > > ODIN) which could well be more trouble than it's worth. > > ODIN will (might) allow me to run the Win32 GHC executable under OS/2 > (ODIN implements the win32 api and comes with a PE loader) > (ODIN is Wine > for OS/2). I thought this might be useful to help bootstrap the > compalation of GHC under OS/2, because I'd wind up with a > Haskell complier > (although one that produces windows executables). Maybe I'll > hold off on > such an approach until (or if) it become clear that such a > venture would > be useful. Interesting - you might be able to bootstrap this way. The idea would be to run the Win32 compiler under ODIN but persuade it to compile via C using your EMX gcc - hence generating EMX object files. This is good because you can start by just compiling up the RTS and libraries, and test that the compiler is producing working binaries before going on to bootstrap a native compiler. I would go straight for a "registerised" port, since you're on x86 and have gcc. Some minor hacking will likely be required to the mangler (ghc/driver/mangler/ghc-asm.lprl) and one or two bits of the RTS. Cheers, Simon

1 0

RE: Congrats to Mandrake
by Simon Marlow 21 Feb '02

21 Feb '02

> Jim Farrand jim(a)farrand.net wrote: > >> > both hugs and ghc in their Linux distro *as standard*. This could > >> > significantly help Haskell takeup amongst the unwashed > masses. :-) > >> Well, same applies for FreeBSD. > > > And Debian. > > So what I mean is, can we have links to more binaries than > just Red Hat? > Debian, Mandrake, FreeBSD. (I know these's SuSE) > > It may just seem like clutter on the download page but it > would help users and > as much as anything else it shows some apreciation for the > packagers who track > the releases so well. Oops! Looks like I added the FreeBSD packages to my local copy of the web pages and forgot to copy it up to the web site. Sorry about that. I'll add links to the Mandrake packages while I'm there. Could someone who is Debian-compliant tell me where I should be pointing for Debian packages? Cheers, Simon

3 2

setting args from inside ghci
by Hal Daume III 20 Feb '02

20 Feb '02

I would like to be able to set the arguments my program will get with getArgs inside the ghci shell. Something like: Main> :setargs -f myfile -whatever-options-i-want Main> main (now, when main has l <- getArgs, l = ["-f", "myfile", "-whatever-options-i-want"]) Any change this will make it in? - 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

RE: i368-pc-os2-emx port
by Simon Marlow 20 Feb '02

20 Feb '02

> > One thing I could try would be to see if I can get a version > of GHC to run > under ODIN (ODIN is a Win32 API implementation under OS/2). > Do you think > this would be helpful? Or would it lead me down the path of making an > OS/2 complier that produced Windows Executables (that would be bad). I don't know enough about ODIN to be able to usefully comment, apart from to say that extra layers of translation generally add extra layers of complication (we've had no end of trouble with cygwin/mingw on Win32), and in this case you'd be going through 2 layers (mingw + ODIN) which could well be more trouble than it's worth. On the other hand, you'd need something like mingw for OS/2 - does such a beast exist? Cheers, Simon

2 1

Re: i368-pc-os2-emx port
by Albert Lai 20 Feb '02

20 Feb '02

"Simon Marlow" <simonmar(a)microsoft.com> writes: > On the other hand, you'd need something like mingw for OS/2 - does > such a beast exist? The substring "emx" refers to an OS/2 version of gcc and libraries that make OS/2 look really like Unix from the programmer's point of view. (It probably even pre-dates cygwin.) I have two encouraging stories to tell. First, for a school assignment, I wrote an OpenGL program on emx, then ported it to school's Solaris+Mesa ten minutes before the deadline --- where porting meant removing "#include <os2.h>". Second, I wrote a program that used tcpip sockets on Unix, then merely recompiled it on emx to use it on OS/2 as well.

1 0

Re: Congrats to Mandrake
by Albert Lai 20 Feb '02

20 Feb '02

ketil(a)ii.uib.no (Ketil Z. Malde) writes: > I'm not sure what the point would be, if they are in the > distributions anyway? Isn't it better to install them by apt-get or > up2date or whatever? (In fact, I had almost thought manually > downloading packages a thing of the past, but then the IT department > insisted on Red Hat) If I, a developer, wrote a program, and some distributions included it (while others didn't), I would want to acknowledge and thank them in public. If I, a potential customer choosing among Linux distributions, liked to use a program, and I saw on the program home page that so-and-so distributions included the program, I would arrange my preference accordingly. If I, an absent-minded user, heard about some great program from my friends, and saw on the program home page which distributions included it, I might realize "Gosh, *my* distribution CD already has it!" and save some download and install effort. Remember, I am absent-minded, so I wouldn't know what's on my CD unless someone stick it on my face. :) I probably don't need hyperlinks; I just need to know if my distribution includes it or not.

1 0

RE: Importing a reference to a non-function entity.
by Simon Marlow 20 Feb '02

20 Feb '02

> What is the politically correct way using the FFI and ghc5.03 > (which I have just managed to compile from > CVS) to import an externally defined object (not a function)? > I have a source file containing the line > > foreign label "default_options" defaultOptions :: CString.CString > > for which ghc5.03 complains about "Warning: foreign > declaration uses deprecated non-standard syntax", > but which works anyway. However in my attempt to be a good > little ghc user, I try instead > > foreign import "default_options" defaultOptions :: CString.CString > > (after deciphering with difficulty the Postscript version of > the FFI document on this screen) but > still get the deprecated warning. Then I try > > foreign import ccall "default_options" defaultOptions :: > CString.CString I believe you meant to say foreign import ccall "&default_options" defaultOptions :: CString.Cstring :-) (see the latest FFI addendum at http://www.cse.unsw.edu.au/~chak/haskell/ffi/) Cheers, Simon

2 1

RE: Data constructors and pattern matching
by Simon Marlow 20 Feb '02

20 Feb '02

> It seems to me that it might be very useful for a module to export the > pattern matching operators for a datatype without exporting the > constructors. Suppose we have > > data A = X {a::Int, b::Float} > > And we want to maintain the invariant that b is a floating-point > representation of a. So normally we would have to use a completely > abstract datatype, and provide constructors and destructors. But in > this case, it would actually make sense to provide the > pattern-matching > operator X, but not the data constructor X. So I think it > would be good > to separate these in the module export syntax. What's wrong with module M (A, a, b) where { ... } ? Simon

1 0