ghc feature request: core notes
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| [EMAIL PROTECTED]
than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Modifying GHC to accept external Styx code
On Mon, 3 Feb 2003, Simon Peyton-Jones wrote: > > | 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. Yes, I know External Core: I'm using it as my input language. (GHC is my frontend as well.) The optimisation algorithms I want to implement need a lower-level language than Core, which is why I want to use Styx, the native generation intermediate language. Abstract C is also an option, but if I've got to hack GHC to get either of them going, I'd rather do it for Styx. Mark -- no-one takes up music to play their own instrument -- Randy Hiatt, Chalkhills list ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc/cygwin filename resolution issue.
Alex Ferguson <[EMAIL PROTECTED]> writes: > (This was all motivated, btw, by trying to build HaXml under ghc/cygwin, > which fell for me at the first hurdle of "first catch your hmake" in the > recipe. I've now gotten as far as a _build_ of hmake, but it then runs > into similar issues with its own use of the f/s (rc files and what-not). > If anyone has this one down pat already, they might save my tired brain > some pain, otherwise I'll summarise to the list if and when I get some > sort of resolution myself.) I am planning to release a new version of hmake (and other tools) very soon, and would really *really* like to get these Cygwin problems licked once and for all. To this end, I have rolled a "release candidate" of hmake-3.07, which I would implore at least one Cygwin user, preferably a couple more, to test-drive before I make a proper release. http://haskell.org/hmake Please mail me with successes as well as failures. By the way, Claus's summary of the problem + fixes was extremely helpful, and I hope it has clarified things sufficiently for me to get it nearly right this time! Regards, Malcolm ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC and C++
> "Simon" == Simon Peyton-Jones <[EMAIL PROTECTED]> writes: Simon>Would either of you like Simon> to write up some stand-alone notes that explain how to do Simon> it, and what the pitfalls are? You can make suggestions Simon> for improving GHC too! I'd be happy to take a first stab at a write-up. It's not a trivial exercise--the Microsoft, Borland, and GNU compilers do not agree on a naming scheme for symbols exported from DLL's. -- Kevin S. Millikin Architecture Technology Corporation Research Scientist Specialists in Computer Architecture (952)829-5864 x. 162 http://www.atcorp.com ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: ghc/cygwin filename resolution issue.
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:[EMAIL PROTECTED]] | Sent: 31 January 2003 00:40 | To: [EMAIL PROTECTED] | 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 | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC and C++
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:[EMAIL PROTECTED]]
| Sent: 02 February 2003 22:34
| To: Nick Name; [EMAIL PROTECTED]
| 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
| > [EMAIL PROTECTED]
| > http://www.haskell.org/mailman/listinfo/gui
| >
| >
|
|
| ___
| GUI mailing list
| [EMAIL PROTECTED]
| http://www.haskell.org/mailman/listinfo/gui
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: GHC doesn't compile under cygwin
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:[EMAIL PROTECTED]] | Sent: 28 January 2003 23:36 | To: [EMAIL PROTECTED] | 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. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Modifying GHC to accept external Styx code
| 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 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
