GHC haskell compiler

Forum thread started by orion77 on Wed, 2006-02-15 22:01

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.

Comments

Re: GHC haskell compiler

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). ;)
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. :)

GHC haskell compiler

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 :)

Re: GHC haskell compiler

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

Re: GHC haskell compiler

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?

Re: GHC haskell compiler

Where is the src for GHC/Haiku kept?

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

Thanks!

Re: GHC haskell compiler

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
                B_TITLED_WINDOW [] B_CURRENT_WORKSPACE

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.

Re: GHC haskell compiler

I personally don't program in Haskell but I recognize it as an important language for serious development:
http://en.wikipedia.org/wiki/Haskell_(programming_language)

Would you consider calling this an Alpha release, checking it in to Haiku Ports:
http://ports.haiku-files.org/

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

Re: GHC haskell compiler

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.

Re: GHC haskell compiler

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...

Re: GHC haskell compiler

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.

Re: GHC haskell compiler

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

Re: GHC haskell compiler

Donn,

Any possibility of getting a Haskell tutorial for Haiku?

Re: GHC haskell compiler

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.

Re: GHC haskell compiler

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.

Re: GHC haskell compiler

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.

Re: GHC haskell compiler

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 ;-)

Re: GHC haskell compiler

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.

Re: GHC haskell compiler

What is the significance of waiting for an official release?

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

Re: GHC haskell compiler

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.

Re: GHC haskell compiler

It's not you who has to wait, it's US! :-)

One of the things that intrigues me about Haskell is marrying functional programming to Haiku's excellent threading and multi-core support. It has been said that one of the most difficult aspects of programming for Haiku is dealing with thread synchronization issues: race conditions, semaphores, variables in correct scope, deadlocks, etc. Haskell shows promise is addressing those difficulties, at least in theory.

But I guess we will have to wait until R1 to try it out...

Re: GHC haskell compiler

AndrewZ wrote:

One of the things that intrigues me about Haskell is marrying functional programming to Haiku's excellent threading and multi-core support. It has been said that one of the most difficult aspects of programming for Haiku is dealing with thread synchronization issues: race conditions, semaphores, variables in correct scope, deadlocks, etc. Haskell shows promise is addressing those difficulties, at least in theory.

Actually the very document you cite goes to some trouble to tell you...

Quote:

Although Haskell has different primitives for sharing data between threads than other languages, it still suffers from the same fundamental problem: writing correct concurrent programs is fiendishly difficult.

One of the most important lessons about dealing with tricky problems is that you should avoid them when possible. It is unfortunate then that Haiku chooses to preserve design choices in BeOS which force programmers to solve unnecessarily tricky problems.

Re: GHC haskell compiler

I don't know if I'm ready to give up on the BeOS concurrency model, but it really doesn't have that much to do with Haskell. If you're working with the BeOS multithreaded application library - BWindow etc. - you're using the same API, makes no difference whether you're writing in C++ or Haskell. If you're working with general purpose concurrency, as illustrated in the article cited above, I'm sure Haskell is head and shoulders above C++, but it makes no difference what platform you use, as long as it supports POSIX pthread functionality.

In fact, in that article, they're using "green" threads - forkIO spawns a control thread that's managed by the runtime, as opposed to a POSIX thread managed by the kernel (forkOS.) That's much lighter weight, and that's where all the talk about high performance concurrency in Haskell is coming from.

The runtime spawns several OS threads, but they rather discourage you from using forkOS to make your own. What Haiku brings to threads, the Haskell world has no use for. We'll be lucky as long as it even works.

Re: GHC haskell compiler

I really like Clojure's Concurrency Model. Functional Programming and immutability bring some aspects to the table. But I'm uncertain how well would that play in terms of a OS.

Re: GHC haskell compiler

NoHaikuForMe wrote:

One of the most important lessons about dealing with tricky problems is that you should avoid them when possible. It is unfortunate then that Haiku chooses to preserve design choices in BeOS which force programmers to solve unnecessarily tricky problems.

So if something has advantages "insert counter argument here" and its tricky, it shouldn't be done becuase its difficult, or maybe even gasp, requires proficiency ?

boy that sure as hell sounds like a copout to me. I don't know how the world would ever get beyond the earth is flat stage if someone didn't take on the tricky task of findings its curvature.

Or inventing algebra, or trigonometery, etc etc etc.

Sounds like you've already decided to fial, before you have begun.

Re: GHC haskell compiler

It seems like thatguy missed two vital words.

NoHaikuForMe wrote:

One of the most important lessons about dealing with tricky problems is that you should avoid them when possible.

Re: GHC haskell compiler

Let me restate my original point. My point was that Haiku is innovative for its support of multithreading in the heart of the OS. This is done through use of BLooper, bemaphores, as well as the standard support for semaphores, pthreads, and microkernel support for multiple cores.

Making good use of multiple cores is a hot topic and getting hotter with the release of AMD's BullDozer which will have 8 cores per chip. There remains a lot to be done in this field.

Haiku could be an excellent academic research tool for upper level computer science classes, PhD research, Master's thesis, and more. Adding more tools for functional programming: Haskell, Erlang, OccamPi, and MPI, Intel TBB, etc. These are just some of many tools for research in this area.

This kind of research could happen even with only an Alpha release of Haiku and Haskell.

Re: GHC haskell compiler

AndrewZ wrote:

Let me restate my original point. My point was that Haiku is innovative for its support of multithreading in the heart of the OS. This is done through use of BLooper, bemaphores, as well as the standard support for semaphores, pthreads, and microkernel support for multiple cores.

  1. Blooper - a message loop, innovative in the 1970s maybe, but today they're everywhere
  2. bemaphores - presumably a typo for "benaphores" - but benaphores are really expensive compared to something like a futex and no better for it.

Haiku doesn't have a microkernel, I guess you just meant to write "kernel" but support for multiple cores is now pretty much ubiquitous.

Re: GHC haskell compiler

NoHaikuForMe wrote:

It seems like thatguy missed two vital words.

NoHaikuForMe wrote:

One of the most important lessons about dealing with tricky problems is that you should avoid them when possible.

No, I ignored them. Most of the computing problems we face today are not untricky. Especially given the hardware in use. Its not going to change.

so put on the big boy pants Peter B and suck it up and get on with your life, crying like a girl isn't going to make you write better applications. Sitting down and writing them will however.

Re: GHC haskell compiler

thatguy wrote:

No, I ignored them. Most of the computing problems we face today are not untricky.

Well, I'm afraid Be Inc engineers didn't agree with you:

George Hoffman wrote:

What Be engineers are best at is taking some problem which is laughably easy to solve and making it complicated enough to interest us.

... and the result of this philosophy was that for example if you want to create two windows, they each require their own separate thread and message loop which means you now need to solve a tricky concurrency problem to do something which is otherwise perfectly simple.

In some places Haiku cleaned up these goofs from the BeOS days. For example by moving the network stack inside the kernel they were able to consolidate select() and avoid lots of hacks where threads exist only to block on a single resource. But not everything was cleaned up, some of that philosophy of "making it complicated" survives.

Re: GHC haskell compiler

AndrewZ wrote:

My point was that Haiku is innovative for its support of multithreading in the heart of the OS. This is done through use of BLooper, bemaphores, as well as the standard support for semaphores, pthreads, and microkernel support for multiple cores.

I agree that the BeOS/Haiku approach is interesting, if only because it's relatively uncommon, but of course (apart from someone's bizarre trolling mission here) we're talking about Haskell, where if you follow my discussion above, concurrency performance is about multiple processor cores, with approximately one POSIX thread each. Can you say more about the relevant features of Haiku's support for multiple processor cores that might be of academic interest? I know the folks who work on GH