February 2003 - Glasgow-haskell-users

ghc feature request: core notes
by Hal Daume III 03 Feb '03

03 Feb '03

I'm not sure how "generally useful" this would be, but I would find it useful to be able to attach notes to core expressions from the Haskell code. The idea being something along the lines of a code annotation like a pragma. For instance, in my Haskell program I would have something like: f x y = case {-# CORE "my first note" #-} g x of ... then, the core would come out with, instead of: case g x of ... we would have case {note "my first note"} g x of ... The reason I would find this useful is somewhat obscure, but the basic idea is that I need to be able to both preprocess code and then change core based on how it was preprocessed. I'd like to send annotations like these out of the preprocessor so they can then be picked up later by my core transformer. If this sounds like a good enough idea to go in, but no one has time to implement it, I could do it myself (probably), but I thought I'd ask the experts first (or if there's anything like this in there currently)... - 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: Modifying GHC to accept external Styx code
by Simon Peyton-Jones 03 Feb '03

03 Feb '03

| I want to use GHC as a backend for my experimental compiler. | I'm trying to modify it to accept styx code from my compiler, and I'm | having some trouble working out where I need to make changes. In truth, | GHC is more haskell code than I've ever seen before in one place, and I'm | a bit lost: can anyone suggest which modules I should become familiar with | and which I should leave alone? You don't say what 'styx code' is. My advice: either translate styx to Haskell, or to External Core. (Probably the latter.) GHC can read both of these in without modification. External Core is a typed lambda calculus. Simon

2 1

RE: ghc/cygwin filename resolution issue.
by Simon Peyton-Jones 03 Feb '03

03 Feb '03

Alex As Simon M says, if you (or anyone else) felt able to write up a standalone summary of what the problem is, and what the solution is, I'd love to add it to the GHC FAQ or documentation somewhere. In my experience, simply explaining the problem clearly is quite tricky. (E.g. the cygwin vs mingw issues, described in the Building Guide, took me ages to understand well enough to write down.) Simon | -----Original Message----- | From: Alex Ferguson [mailto:abf@cs.ucc.ie] | Sent: 29 January 2003 16:29 | To: glasgow-haskell-users(a)haskell.org | Subject: Re: ghc/cygwin filename resolution issue. | | | | Thanks to all for the replies; Hal's resolution rings a | bell, now that I think about it, from Ye Olde Days when | cygwin was a ghc pre-req -- just didn't think of it when | installing more recently on a new machine. (Install in | haste, repent at leisure.) Claus' suggestion about relative | paths does the ticket, though: didn't occur to me as the | paths were being generated by a configure script, but yes, it | was possible to override them, which works as advertised. | | Cheers, | Alex. | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-| haskell-users |

4 3

GHC and C++
by Simon Peyton-Jones 03 Feb '03

03 Feb '03

Daan, Kevin, (and Mike, Sarah?) You two/three seem to be the de-facto experts when it comes to building DLLs with GHC and linking them to C++ DLLs. Would either of you like to write up some stand-alone notes that explain how to do it, and what the pitfalls are? You can make suggestions for improving GHC too! What otherwise happens is that everyone has to reinvent the wheel. And, to be honest, we're not well up on this at GHC home base, so you could do a far better job than we could. The important thing is to explain enough context that someone does not have to be a total Win 32 expert to understand what's going on. Claus's recent message explaining about Cygwin paths was an excellent example of how to do it. It'd be a real service. Simon | -----Original Message----- | From: Daan Leijen [mailto:daanleijen@xs4all.nl] | Sent: 02 February 2003 22:34 | To: Nick Name; gui(a)haskell.org | Subject: Re: [GUI] ByeDemo | | > > I have been thinkering with the wxWindows library | > > and made a small Haskell binding to it that just supports this | > > example. It was an interesting exercise since the wxWindows library | > > is a large object-oriented C++ library. (but very portable, well | > > supported, efficient and with lots of super widgets, like an openGL | > > canvas and a HTML renderer) | > | > It is really interesting. How did you bind the library? Could you make a | > tarball of the binding, the example and a makefile? It could be used as | > an "Haskell->C++" tutorial. | | (warning: rather detailed and long answer...) | | I have only done it for windows yet, both with mingw32 and visual C++. | Funny thing: the final (stripped) DLL with mingw32 was 2.8mb, while the | visual C++ DLL (with the same functionality) was just 640kb :-). | | In the end, I couldn't link it directly with a haskell application due to the | difference between the C++ and plain C runtimes, so I have made dynamic | link library (.dll) of the C++ code. This code exposes a plain C interface (with "extern | "C""). | This interface is basically a flat C view on the object oriented wxWindows library. | | This DLL is accessed with foreign imports from Haskell. Call backs are dynamically | created using dynamic exports ("wrapper"). Actually, the hardest part was to | make sure that the resource files (.rc) were properly linked in the DLL, as we don't | want to deal with those from Haskell. | | I don't know yet if this approach also works for unix's (.so files?) or MacOSX, | but there probably is a way to do this. In the end, it is good enough if there is | some way of wrapping the C++ code into a C library. Maybe someone on this list | can tell me more about how this could work on unix like platforms??? | | The part that is most challenging, and which I am still working on, is trying to fit | the event model of wxWindows into a reasonable model for Haskell (or other | languages for that matter). Somehow, I need to create "universal" widget objects | that are programmable from outside (i.e. Haskell) but normally, one derives | application | specific objects for each widget in wxWindows. There are mechanisms for more | dynamic | applications (like I want) but I am still trying to figure out the right way to do it. | | I think this is basically a universal problem when trying to interface to foreign object | oriented | (or any other paradigm for that matter) with a functional language. It is not just the | marshalling | and calling conventions, but the programming model makes a huge difference. Years | ago, when | designing H/Direct we automated the marshalling process, but it seems that that is | just a small | part of the problem. Trying to fit into an entirely different programming model is very | hard. For | an extreme example, I think that there is no reasonable way of interfacing to the Java | Swing model. | | Fortunately, it seems that the wxWindows library is much more flexible, and up till | now, I haven't | encountered any hard problems. Maybe this is actually the right way to go for a | Haskell GUI library | -- let others do the hard work of maintaining a rich,portable gui library, and we just | have to do | the hard work of interfacing to c++ once. | | All the best, | Daan. | | | > Vincenzo | > | > -- | > First they ignore you, then they laugh at you, | > then they fight you, then you win. | > [Gandhi] | > | > _______________________________________________ | > GUI mailing list | > GUI(a)haskell.org | > http://www.haskell.org/mailman/listinfo/gui | > | > | | | _______________________________________________ | GUI mailing list | GUI(a)haskell.org | http://www.haskell.org/mailman/listinfo/gui

2 1

RE: ghc/cygwin filename resolution issue.
by Simon Peyton-Jones 03 Feb '03

03 Feb '03

Thank you Claus! I've incorporated your section exactly as written. It'll be in the next release of GHC. Simon | -----Original Message----- | From: Claus Reinke [mailto:claus.reinke@talk21.com] | Sent: 31 January 2003 00:40 | To: glasgow-haskell-users(a)haskell.org | Subject: Re: ghc/cygwin filename resolution issue. | | >As Simon M says, if you (or anyone else) felt able to write up a | >standalone summary of what the problem is, and what the solution is, I'd love | >to add it to the GHC FAQ or documentation somewhere. | | Following the worse-is-better approach, here's some text for others | to fiddle with (I'd recommend to keep the result in the GHC FAQ | proper, possibly with a link from the building guide, if necessary). | I've omitted the build-ghc-with-cygwin option, lest readers in search | or solutions rush of to cause themselves even more problems;-). | | Cheers, | Claus | | Using GHC (and other GHC-compiled executables )with cygwin | ================================================ | | [background] | The cygwin tools aim to provide a unix-style API on top of the windows | libraries, to facilitate ports of unix software to windows. To this end, they | introduce a unix-style directory hierarchy under some root directory | (typically / is C:\cygwin\). Moreover, everything built against the cygwin | API (including the cygwin tools and programs compiled with cygwin's | ghc) will see / as the root of their file system, happily pretending to work | in a typical unix environment, and finding things like /bin and /usr/include | without ever explicitly bothering with their actual location on the windows | system (probably C:\cygwin\bin and C:\cygwin\usr\include). | | [the problem] | GHC, by default, no longer depends on cygwin, but is a native windows | program. It is built using mingw, and it uses mingw's ghc while compiling | your Haskell sources (even if you call it from cygwin's bash), but what | matters here is that - just like any other normal windows program - neither | GHC nor the executables it produces are aware of cygwin's pretended | unix hierarchy. GHC will happily accept either '/' or '\' as path separators, | but it won't know where to find /home/joe/Main.hs or /bin/bash or the | like. This causes all kinds of fun when GHC is used from within cygwin's | bash, or in make-sessions running under cygwin. | | [things to do] | 0) don't panic! | | 1) don't use absolute paths in make, configure & co if there is any chance | that those might be passed to GHC (or to GHC-compiled programs). Relative | paths are fine because cygwin tools are happy with them and GHC accepts | '/' as path-separator. And relative paths don't depend on where cygwin's | root directory is located, or on which partition or network drive your source | tree happens to reside, as long as you 'cd' there first. | | 2) if you have to use absolute paths (beware of the innocent-looking | ROOT=`pwd` in makefile hierarchies or configure scripts), cygwin provides | a tool called 'cygpath' that can convert cygwin's unix-style paths to their | actual windows-style counterparts. Many cygwin tools actually accept | absolute windows-style paths (remember, though, that you either need | to escape '\' or convert '\' to '/'), so you should be fine just using those | everywhere. If you need to use tools that do some kind of path-mangling | that depends on unix-style paths (one fun example is trying to interpret ':' | as a separator in path lists..), you can still try to convert paths using | cygpath just before they are passed to GHC&friends. | | 3) if you don't have cygpath, you probably don't have cygwin and hence | no problems with it.. unless you want to write one build process for several | platforms. Again, relative paths are your friend, but if you have to use | absolute paths, and don't want to use different tools on different platforms, | you can simply write a short Haskell program to print the current directory | (thanks to George Russell for this idea): compiled with GHC, this will give | you the view of the file system that GHC depends on (which will differ | depending on whether GHC is compiled with cygwin's gcc or mingw's | gcc or on a real unix system..) - that little program can also deal with | escaping '\' in paths. Apart from the banner and the startup time, | something like this would also do: | | $ echo "Directory.getCurrentDirectory >>= putStrLn . init . tail . show " | ghci | | 4) panic now. | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

RE: GHC doesn't compile under cygwin
by Simon Peyton-Jones 03 Feb '03

03 Feb '03

Did you carefully follow the steps described in the Building Guide? http://haskell.cs.yale.edu/ghc/docs/latest/html/building/winbuild.html Simon | -----Original Message----- | From: Chris Clearwater [mailto:chris@sharkzone.com] | Sent: 28 January 2003 23:36 | To: glasgow-haskell-users(a)haskell.org | Subject: GHC doesn't compile under cygwin | | Hi, today I installed cygwin and downloaded the GHC source, however | during compilation I get the errors: | | test: 504: unknown operand | test: 500: unknown operand | test: 504: unknown operand | | In addition,I get many Error [127] (ignored) and Error [1] (ignored) | before finally quiting with the unknown operand errors. Attached is the | configure output, confiure log and make output. | | Thanks in advance for any help.

1 0

Modifying GHC to accept external Styx code
by Mark Alexander Wotton 03 Feb '03

03 Feb '03

I want to use GHC as a backend for my experimental compiler. I'm trying to modify it to accept styx code from my compiler, and I'm having some trouble working out where I need to make changes. In truth, GHC is more haskell code than I've ever seen before in one place, and I'm a bit lost: can anyone suggest which modules I should become familiar with and which I should leave alone? mrak -- please don't be too gentle with me -- The Minutemen

1 0