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 can't speak to specifics other than that the multi-core support is in the hybrid-microkernel, it's open source, and it's not Linux, and it mostly works on old and new PCs. This is a pretty good start for someone who has an academic project and needs an interesting platform on which to do it.
I myself have done some very rudimentary SMP programming, as proof of concept,
but am working on some more widely applicable patterns, in C++.
So, just out of curiosity, what restricts Haskell to a single thread per core? It's just designed that way?
It isn't restricted, it's just more efficient that way by a considerable margin. You can have as many OS threads as you want (or must have, to support BeOS API constructs like BWindow), but for a compute-heavy problem you would typically be advised to use "green" threads and let the runtime map them to per-processor OS threads.
I can't speak to specifics other than that the multi-core support is in the hybrid-microkernel
Haiku doesn't have a microkernel. It has a conventional monolithic kernel.
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.
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.
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.
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...
Actually the very document you cite goes to some trouble to tell you...
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.
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.
It seems like thatguy missed two vital words.
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.
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:
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.
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.
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 GHC compiler/runtime internals are keenly interested in this kind of thing, so if we're sitting on something here they might be excited to hear about it (and of course that couldn't hurt our prospects of a fully working GHC on Haiku.)
Haiku doesn't have a microkernel, I guess you just meant to write "kernel" but support for multiple cores is now pretty much ubiquitous.
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.
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.
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...
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?
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
listWin folder host title =
withCString title $ \ n -> cBWindow (Just (wcx host folder ))
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.