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). 
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. 
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 
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:
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
Where is the src for GHC/Haiku kept?
Can you post some simple examples of running Haskell under Haiku?
Thanks!
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.
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?
Donn,
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 
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.