GHC haskell compiler

has anybody managed to get a port of the glasgow haskell compiler for Beos/haiku done?

im a keen haskell developer and would love to develop some applications, ive had a few goes at it myself but ive had trouble with GCC.

orion77 wrote:
has anybody managed to get a port of the glasgow haskell compiler for Beos/haiku done?

im a keen haskell developer and would love to develop some applications, ive had a few goes at it myself but ive had trouble with GCC.

I’ve tried to do this. At that time I wanted to get darcs working on BeOS to host Haiku (well, would’ve probably been too slow, but I wanted to test it), but since I failed we switched to Subversion (which was the better choice, anyway). :wink:
Really, I’ve never seen something that is so extremely difficult to port. Scripts all over the place. Perl for native compiling…WTF?

Sorry. Maybe some of my work is still in their repository (e.g.: area allocation code instead of mmap, etc.). Maybe you want to have a look at porting it? I could still need darcs. :slight_smile:

i will try my best to get it ported over, i actually tried hugs and nhc which gave better results but the lack of documentation with both is a problem. i was hoping one of the latter may make ghc easier to get going.
if im succesful i will let you know :slight_smile:

Has this moved in the last 4 1/2 years ?

Yes - I’ve been using GHC 6.12, and 7.0 release candidate seems to work. It isn’t 100% - don’t have ghci, and the run-time timer signals need to be turned off (RTS -v0) when working with BeOS API threads (BWindow.) Could be more issues, but I can write usable applications. On Haiku r37466 - haven’t tried with later revisions.

The port is ridiculously difficult, just because porting GHC is more or less broken at this point, because so much of GHC is written in Haskell. There aren’t any big Haiku issues with the compiler. The ghci interpreter is a lot more system-specific, but don’t know that it couldn’t be made to work.

What would you do with Haskell?

I personally don’t program in Haskell but I recognize it as an important language for serious development:

Would you consider calling this an Alpha release, checking it in to Haiku Ports:

Then we could make an announcement on OS News or some such. The idea of a highly functional language like Haskell on a highly threaded OS like Haiku could open up some interesting development possibilities.

  • Andrew

Where is the src for GHC/Haiku kept?

Can you post some simple examples of running Haskell under Haiku?


Inasmuch as there is any GHC/Haiku source, it’s on a hard drive here next to me, which I suppose is probably not an ideal proposition in the long term. Really the key is not the source, but build continuity, recalling that GHC is written in Haskell and we do not want to start over from scratch. Patches to the GHC compiler are very minimal, and then I have a platform support library for some minimal BeOS API functionality.

The API is an awkward fit, of course, since it’s based OO dispatch and parameter overloading. I derive a Haskell-support class from each API class, that takes a table of possible hook functions. The hook function will be invoked with the class instance and a user data parameter, along with its normal API parameters.

quitRequested this wv = do mp <- psGetMainPort msg <- hMessageToBMessage (HMessage (fromIntegral (fromEnum MsgCloseFolder)) [ ("host", HMString (wvHost wv)) , ("folder", HMString (wvFolder wv)) , ("replyTo", HMInt32 (fromIntegral mp)) ]) p <- psGetIMAPPort portPostMessage p msg cBWindowQuitRequested this

listWin folder host title =
withCString title $ \ n -> cBWindow (Just (wcx host folder []))
(nullBWindowDispatch {
windowQuitRequested = Just quitRequested
, windowMessageReceived = Just messageReceived
(BRect 520 280 1272 700) n

wcx is my constructor function. Its parameter will be the (Ptr BWindow) that was created by cBWindow - and the parameters I apply to it above where I pass it to cBWindow. The user data (wv in the example) doesn’t have to be marshalled to C, and the type system is able to sort it out, so that works OK. cBWindow’s type is
cBWindow :: Maybe (Ptr BWindow -> IO ()) -> BWindowDispatch a -> BRect -> CString -> WindowType -> [Window_flag] -> Window_workspace -> IO (Ptr BWindow)

… where cBWindowDispatch a is the hook function table, parameterized by type a.

So my way to do BeOS API programming in Haskell sure isn’t a miracle of elegance, but I’ve been looking forward to this for years anyway.

Somewhat awkward in `Ports’, don’t you think? Recalling that it can’t be built from source, without ghc already installed.

I would also prefer to steer clear of OS News et al.

It really isn’t important to Haiku at all. I do not want anyone to be confused about this - by far the best programming language for Haiku applications is C++, because that’s the API. If anyone has specific ideas about how they’d like to use Haskell on Haiku, I think that would be a very interesting discussion, but after that there should be some practical experience putting those ideas into practice, and then perhaps it will be time to bother the OS News crowd with it.

I don’t understand how you have compiled the compiler in Haiku as it is written in Haskell?
Have you cross-compiler on another OS or there is a sort of “bootstrap” compiler written in C?

For your assertion “Haskell is not important for Haiku” I don’t understand the point… more compilers (aka languages) we have the better!

The API is written in C++, but if someone like to use Haskell (as it prefer it) I think he should… maybe this permits to port some interesting software that is written only in Haskell…

I certainly agree that C++ and YAB are best suited for creating ‘standard’ Haiku applications for general distribution. I am under the impression that there is a solid base of academic work that is being done with Haskell. In particular, Haskell is being used for highly functional parallel algorithms.

The fact that Haiku is pervasively multithreaded is of great interest to me. It would seem that a marriage of Haskell and Haiku could be quite interesting for development and exploration of parallel, distributed, and threaded programming.

How about this. Would it be possible to baseline the Haskell development you have done to date so others could check it out of some repository and run it? The point of an announcement on OSNews is simply to let other Haskell developers know that they can run it on Haiku, and work towards a Haskell/Haiku community. OSNews is a friendly and receptive forum for Haiku, that’s all.

Since Haskell now has a LLVM Backend, you would ‘only’ need LLVM on Haiku these days, is this right?


Any possibility of getting a Haskell tutorial for Haiku?

A tutorial for Haskell itself? I think it’s close enough to the same for every platform, that the generic introductory texts out there are probably better than anything I could do. It isn’t easy to explain Haskell. The main difference is that ghci won’t be supported unless someone can figure out the platform object file support, so you have the ghc compiler only.

My BeOS API support mentioned above will need documentation, for sure, and some examples wouldn’t hurt.

… bearing in mind, Haiku hasn’t been released, as far as I know there is no generally available Haskell implementation for it, and my API support library is a work in progress. So we’re looking a ways out here.

Not a tutorial on Haskell itself, although references are always good, more a tutorial on what is necessary to build and program basic Haskell programs on Haiku. With the resources available now. And definitely show off some of what can be done with your examples.

Well, honestly the last thing I think we need is “advocacy”, if you know what I mean. People coming to Haiku with that kind of skill and energy will be more effective with C++. Obviously I like Haskell and see various advantages over C++, but on Haiku the overwhelming advantage goes to C++ because of the API. Even to the extent that the things you need might be supported in Haskell, you’ll have an easier time of it if you understand the underlying C++.

Of course once Haiku is released and there’s a working ghc and stuff for it, anyone is welcome to use it however they wish, and if you think it’s the greatest thing since Pascal on the P-code machine then I want to hear from you because we might have something in common. But I can’t see that it’s in anyone’s interest to promote Haskell as a solution on Haiku, to people who may not realize what a dead-end it could be as a developer strategy.

You’re the only one who has Haskell running on Haiku. If you don’t want to share it, that’s entirely up to you.

There are such things as disclaimers, so only people who realize it’s a dead-end will use it :wink:

My previous post was about a tutorial - sorry, thought that would be obvious. I shouldn’t make any promises, but I can work on making ghc available when there’s an official Haiku release to run it on.

What is the significance of waiting for an official release?

Or to rephrase, what’s wrong with releasing Alpha GHC with Alpha Haiku?

There have been issues with ghc at some versions, including r1a3. We can afford to wait, I’m sure it won’t be very long.