- Glasgow-haskell-users

RE: [Haskell-cafe] GHC for .NET?
by Don Syme 05 Jan '05

05 Jan '05

> Next, you need to think about how to inter-operate with .NET > libraries. You don't really want to write "foreign import..." > for each and every import. You'd like GHC to read the CLR > meta-data directly. But there are lots of tricky issues here; > see the paper that Mark Shields and I wrote about "Object-oriented > style overloading for Haskell". >From what I've seen, .NET interoperability (i.e. API access) is too important to simply encode into a language using existing language mechanisms. Let's be honest: there isn't a single language that has succeeded in giving decent inter-operability without modifying and/or substantially extending the language (there are several faithful language implementations, e.g. OCamlIL, but these efforts have not covered interoperability). I really don't see why Haskell will be any different. Of course no design group _wants_ to change or extend their existing language, and on the whole they do not end up doing it because of limitations in the CLR. Instead they eventually come around to the fact that there are big benefits to providing .NET API access that "feels right" to the programmer, rather than forcing the programmer to use arcane encodings into existing language constructs, even if that means changing and/or extending the language. Some see this as a weakness of the .NET approach to interoperability (because it forces too much on each language, e.g. generics, classes, interfaces, properties, namespaces). Some also see it as its strength (because it gives the API designer a better set of tools, all of which will be understood by each language - at least better when compared to COM or C). Many in the first camp are language designers and/or implementers, while many in the second are working programming teams who are very happy to be able to use high-level, extensible APIs from a number of programming languages. You can argue over whether .NET has made good choices for the primitives used to express APIs (some hate classes, some hate generics), but the fundamental principle won't change: if you want rich common constructs for expressing APIs, then the language designers and implementers pay the price (by having to support a common set of non-trivial constructs), while the programmers reap the benefits. Understandably, however, there is real resistance in language communities like Haskell's to changing or even extending a language for the sake of interoperability and API access: instead people work incredibly hard to encode interoperability via existing mechanisms. In the end, whoever picks up the burden of doing Haskell.NET will face the same unenviable choice that every other .NET language design group has faced: (a) do you modify and/or extend the language to make "the nicest possible Haskell-like language in the context of .NET" or (b) do you implement Haskell faithfully without language extensions, but where using the .NET libraries is in practice somewhat arcane and unpleasant, probably sufficiently so that you'll be unable to attract .NET-savvy programmers to your language. Personally I think language designs in space (a) are more interesting, since perfectly good native implementations of Haskell are already available on most platforms. I also think you learn a lot more by trying to create something new, and you give yourself the maximum possible long-term chance of rivalling other .NET languages (which I think should be an important goal for a Haskell.NET) But people devoted to the Haskell standard will no doubt prefer (b), as may people whose main interest is in presenting .NET functionality in a Haskell-esque way (e.g. via Fran-like libraries). Finally, all this just deals with "import" interoperability. Nearly as important in practice is "export" interoperability, i.e. how is your Haskell code going to look to other .NET languages, and is it going to be usable by those languages. Just my 2c worth for the New Year :-) Cheers Don -----Original Message----- From: Simon Peyton-Jones Sent: 04 January 2005 12:18 To: Don Syme; John Goerzen; haskell-cafe(a)haskell.org Cc: GHC users Subject: RE: [Haskell-cafe] GHC for .NET? | "The GHC compiler for .NET is currently under development at | Microsoft Research, Cambridge". | | Hmm. That location sounds familiar :-) Does anyone know if this is | actually going to happen? Or if there's any code anywhere, however | experimental, to try? It'd make a lot of sense to give GHC a .NET back end, and it's a question that comes up regularly. The reason that we haven't done it here, at GHC HQ, is because it's a more substantial undertaking than might at first appear (see below). Furthermore, it'd permanently add a complete new back-end platform for us to maintain. Given our rather limited development effort (= Simon and me), we have so far not bitten the bullet, and we have no immediate plans to do so. It'd be a good, well-defined project for someone else to tackle, and there is some good groundwork already done: * Sigbjorn Finne did a simple interop implementation that allows a Haskell program to be compiled to native code (as now) but to call .NET programs via a variant of the FFI. I don't think this work is in active use, and I'd be surprised if it worked out of the box, but it could probably be revived with modest effort * Andre Santos and his colleagues at UFPE in Brazil are working on a .NET back end, that generates CLR IL, though I don't know where they are up to. * GHC.Net would be extra attractive if there was a Visual Studio integration for GHC. Substantial progress on this has been made in 2004 by Simon Marlow, Krasimir Angelov, and Andre Santos and colleagues. There may be others that I don't know of. If anyone wants to join in this effort, do contact the above folk. And please keep us informed! Simon Here's a summary of why it's a non-trivial thing to do: - The first thing is to generate native CLR Intermediate Language (IL). That's not really hard. Requires thinking about representations for thunks and functions, and it may not be particularly efficient, but it can surely be done. An open question is about whether to generate verifiable IL or not. The trouble here is that Haskell's type system is more expressive than the CLR's in some ways, notably the use of higher-kinded type variables. So, to generate verifiable IL one is bound to need some run-time casts, and it's not clear how to minimise these. At first blush this is *all* you need do. But it isn't! - Next, you need to think about how to inter-operate with .NET libraries. You don't really want to write "foreign import..." for each and every import. You'd like GHC to read the CLR meta-data directly. But there are lots of tricky issues here; see the paper that Mark Shields and I wrote about "Object-oriented style overloading for Haskell". - Now you need to figure out how to implement GHC's primitive operations: the I/O monad arbitrary precision arithmetic concurrency exceptions finalisers stable pointers software transactional memory Not all of these are necessary, of course, but many are used in the libraries. The CLR supports many of them (e.g. concurrency) but with a very different cost model. - Last, you have to figure out what to do for the libraries. GHC has a pretty large library, and you either have to implement the primops on which the library is based (see previous point), or re-implement it. For example, GHC's implementation of I/O uses mutable state, concurrency, and more besides. For each module, you need to decide either to re-implement it using .NET primitives, or to implement the stuff the module is based on. These challenges are mostly broad rather than deep. But to get a production quality implementation that runs a substantial majority of Haskell programs "out of the box" requires a decent stab at all of them.

1 0

RE: internal error: weird activation record found on stack: 9
by Simon Marlow 04 Jan '05

04 Jan '05

On 16 December 2004 16:12, Peter Simons wrote: > I'm getting this error in my software every now and then: > > postmaster: internal error: scavenge_stack: weird activation record > found on stack: 9 Please report this as a bug to > glasgow-haskell-bugs(a)haskell.org, or > http://www.sourceforge.net/projects/ghc/ > > The process runs just fine for several days, and then it > crashes with this message out of the sudden. There is no > apparent cause. I'm using a fairly recent CVS ghc to compile > the program on Linux/x86. > > Any idea what I can do to help tracking this bug down? Please compile the program with -debug, then open it with gdb. Set a breakpoint on barf() and run the program: gdb> break barf gdb> run and wait for it to hit the breakpoint. Then do gdb> signal SIGABRT to get a core dump. Send the source, binary, and core dump to us. With any luck, we'll be able to track it down without running the program. Cheers, Simon

2 3

RE: ghc for hp-ux 11.11...
by Simon Marlow 04 Jan '05

04 Jan '05

On 21 December 2004 17:38, Sven Panne wrote: > amyhr(a)spymac.com wrote: >> Okay, I've tried to follow the directions, and ran into a couple >> minor issues I was able to work through, but I got stuck at the "cd >> H/libraries && make boot && make" stage. The host system is redhat >> enterprise linux 3, the target is hp-ux >> 11.11, the output is below: [...] > > It looks like you try to get GHC 6.2.2 up and running. Could you try > the GHC from CVS HEAD instead, please? The configuration stuff has > changed quite a bit, and I'm reluctant to work on the old STABLE > branch. Could you send a log of the configuration/building plus all > config.log and config.status files, please? In ancient times, I made > GHC run on HP-UX 9, but I guess that things suffer from bit rot... Looks like he has given up and submitted a feature request :-) But anyway, the HEAD is probably not in a good state for bootstrapping right now (unless anyone has evidence to the contrary?) I plan to make sure bootstrapping works before we release 6.4. Cheers, Simon

1 0

dummy variables
by Serge D. Mechveliani 29 Dec '04

29 Dec '04

Dear Haskellers, dear GHC team, Is a variable `_x' equivalent to `_' ? I discover that ghc-6.2.2 assigns a value to _rem in the program f :: Int f = let (q, _rem ) = quotRem 5 2 (q', _rem') = quotRem 7 4 in _rem + _rem' I got used to write the programs like let (x, _remainder ) = ... (y, _remainder') = ... in x + y using _remainder as a self-commenting dummy variable. Because it is a better commentary than `_'. And now, it occurs that these are the variables taking values! And removing the quote suffix from _remainder' even leads to the report of "conflicting definitions". Does really Haskell mean this? It this reasonable? How to set self-commenting dummy variables? Or, maybe, it is a GHC bug? Thank you in advance for the explanation. ----------------- Serge Mechveliani mechvel(a)botik.ru

3 2

Emitting java bytecode?
by Tomasz Zielonka 28 Dec '04

28 Dec '04

Hello! Would be possible for GHC to emit Java bytecode? There seems to be some code in GHC's sources (in ghc/compiler/javaGen/) suggesting that it was anticipated. I suppose most of the work would be in making a java RTS and libraries. I am mainly interested in making GHC more portable. Haskell is a great application programming language, but there are some concerns about portability of applications. Perhaps I shouldn't be looking at java bytecode for a solution... Is it possible that a C-- backend will make GHC more portable? Best regards, Tomasz

6 6

Error building GHC: can't locate import `Package'
by Peter Simons 27 Dec '04

27 Dec '04

When building the current CVS HEAD with ghc-6.2.2 on Linux/x86, I get this error: [...] ==fptools== make boot - --no-print-directory -r; in /usr/local/src/ghc-current/ghc/utils/ghc-pkg -------------------------------------------------------------------- Creating Version.hs ... ghc-6.2.2 -M -optdep-f -optdep.depend -osuf o -optdep--exclude-module=Compat.RawSystem -optdep--exclude-module=Compat.Directory -optdep--exclude-module=Distribution.Compat.Error -optdep--exclude-module=Distribution.Compat.ReadP -optdep--exclude-module=Distribution.Extension -optdep--exclude-module=Distribution.InstalledPackageInfo -optdep--exclude-module=Distribution.License -optdep--exclude-module=Distribution.Package -optdep--exclude-module=Distribution.ParseUtils -optdep--exclude-module=Distribution.Setup -optdep--exclude-module=Distribution.Version -optdep--exclude-module=System.FilePath -H16m -O -optc-nopie -optc-fno-stack-protector-all -optc-fno-stack-protector -cpp -Wall -fno-warn-name-shadowing -fno-warn-unused-matches -i../../lib/compat Main.hs ParsePkgConfLite.hs Version.hs ParsePkgConfLite.hs: can't locate import `Package' It seems that ParsePkgConfLite.hs omits the "Distribution" part when importing Distribution.Package. Peter

4 7

Re: ghc for hp-ux 11.11...
by amyhr＠spymac.com 21 Dec '04

21 Dec '04

Okay, I've tried to follow the directions, and ran into a couple minor issues I was able to work through, but I got stuck at the "cd H/libraries && make boot && make" stage. The host system is redhat enterprise linux 3, the target is hp-ux 11.11, the output is below: /var/tmp/work/ghc-6.2.2/libraries 1030 $ make boot && make ------------------------------------------------------------------------ ===fptools== Recursively making `boot' in base haskell98 haskell-src network parsec QuickCheck readline unix ... PWD = /var/tmp/work/ghc-6.2.2/libraries ------------------------------------------------------------------------ ------------------------------------------------------------------------ ==fptools== make boot -r; in /var/tmp/work/ghc-6.2.2/libraries/base ------------------------------------------------------------------------ ../../ghc/utils/hsc2hs/hsc2hs-inplace -Iinclude -I../../ghc/includes -I. System/CPUTime.hsc In file included from /var/tmp/work/ghc-6.2.2/ghc/includes/HsFFI.h:21, from /var/tmp/work/ghc-6.2.2/ghc/utils/hsc2hs/template-hsc.h:4, from System/CPUTime_hsc_make.c:1: /var/tmp/work/ghc-6.2.2/ghc/includes/config.h:12:14: warning: ISO C requires whitespace after the macro name /var/tmp/work/ghc-6.2.2/ghc/includes/config.h:13:14: warning: ISO C requires whitespace after the macro name /var/tmp/work/ghc-6.2.2/ghc/includes/config.h:13:1: warning: "hppa2" redefined /var/tmp/work/ghc-6.2.2/ghc/includes/config.h:12:1: warning: this is the location of the previous definition /var/tmp/work/ghc-6.2.2/ghc/includes/config.h:14:14: warning: ISO C requires whitespace after the macro name /var/tmp/work/ghc-6.2.2/ghc/includes/config.h:14:1: warning: "hppa2" redefined /var/tmp/work/ghc-6.2.2/ghc/includes/config.h:13:1: warning: this is the location of the previous definition In file included from CPUTime.hsc:33: include/HsBase.h:64:26: sys/timers.h: No such file or directory include/HsBase.h:98:1: warning: "HAVE_GETRUSAGE" redefined In file included from /var/tmp/work/ghc-6.2.2/ghc/includes/HsFFI.h:21, from /var/tmp/work/ghc-6.2.2/ghc/utils/hsc2hs/template-hsc.h:4, from System/CPUTime_hsc_make.c:1: /var/tmp/work/ghc-6.2.2/ghc/includes/config.h:494:1: warning: this is the location of the previous definition make[1]: *** [System/CPUTime.hs] Error 1 make: *** [boot] Error 1 On Mon Dec 20 17:38 , dons(a)cse.unsw.edu.au (Donald Bruce Stewart) sent: >amyhr: >> Is it possible? Is there anyone out there who's done it and could provide advice >> or binaries? > >It should be possible. You'll have to follow the instructions from the >porting guide: > http://www.haskell.org/ghc/docs/latest/html/building/sec-porting-ghc.html > >When you run in to problems, ask on #haskell or this list. > >Good luck, > Don

2 1

RE: CVS HEAD ghc fails with "Panic!"
by Simon Peyton-Jones 21 Dec '04

21 Dec '04

I reckon I've fixed this, at last. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Peter Simons | Sent: 20 October 2004 17:10 | To: glasgow-haskell-users(a)haskell.org | Subject: CVS HEAD ghc fails with "Panic!" | | Hi, | | the GHC version from the current CVS HEAD aborts with an | internal error when doing this: | | $ darcs get http://cryp.to/hsemail | $ cd hsemail | $ ghc -O2 --make -o message-test message-test.hs | | Chasing modules from: message-test.hs | | Compiling Rfc2234 ( ./Rfc2234.hs, ./Rfc2234.o ) | | ghc-6.3: panic! (the `impossible' happened, GHC version 6.3): | | app_match: unbound tpl c{tv a1a9} | | Compiling with -O instead of -O2 works, though. | | Peter | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

ghc for hp-ux 11.11...
by amyhr＠spymac.com 20 Dec '04

20 Dec '04

Is it possible? Is there anyone out there who's done it and could provide advice or binaries?

2 1

[ ghc-Feature Requests-1088694 ] hp-ux 11.11 binaries
by SourceForge.net 20 Dec '04

20 Dec '04

Feature Requests item #1088694, was opened at 2004-12-20 16:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1088694&group_… Category: None Group: None Status: Open Priority: 5 Submitted By: Andy MyHR (amyhr) Assigned to: Nobody/Anonymous (nobody) Summary: hp-ux 11.11 binaries Initial Comment: Looks like there hasn't been a binary dist for ghc in a very long time, any chance we could see one soon? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1088694&group_…

1 0