Functional programming support in Haiku

I'm fairly sure there's ocaml in haikuports. It looks as though Erlang is in there too. I suspect you might have trouble boot strapping haskell? If you like logic programming, I have ported SWI Prolog, it has almost identical syntax to Erlang (Erlang syntax is based on prolog, in fact early versions were developed in it).

Note that none of these have bindings for the haiku API, as far as I know, so GUI programming would not be easy (I guess if they have qt bindings it might work with the qt port... swipl does not, not sure about the others).

Yab is native and has all the GUI Creation stuff you need.

You are right, I have never heard of "functional" programming until now.. I know about "Procedural" and "Object Oriented." Thanks for educating me. Now I know it exists, but can't figure out how one could use it for anything. Never figured out how to use "Object Oriented" languages either, I guess I am just a "Procedural" kind or programmer.

All of these styles bring something to the table, but let me illustrate very briefly in case it's helpful.

Suppose your program needs to be able to sort movies by title or by year, and actors by name. In procedural programming the natural way to solve this is by writing three similar but separate sort procedures. They might share some utility sub-procedures, but the core algorithm must be replicated three times.

With functional style it is natural to write functions which compare two things to see if they're in the right order, resulting in three different comparison functions and a single sort function that itself takes a comparison function as a parameter, the program is less repetitive and thus can be simpler to maintain.

With object oriented style it is natural to make classes to represent the movies and actors, and give these classes methods which either implement the sort directly (like the procedural style) or compare an object to another instance of the same class (like the functional style) but in both cases the code related to a particular class is now in one place, again reducing the maintenance burden.

There are a lot more styles, I personally have a fondness for continuation passing style but you should not on the whole view them as competing alternatives but rather as different tools in a toolbox.

I ported ocaml. I develop with vim which has excellent syntax coloring.

Yes indeed, I've gotten the key parts of GHC working at a couple of different revisions. It's fragile, there have been releases where I couldn't make it work, and I've never gotten anywhere with the GHC interpreter. I have API support, which I've used to write a couple of ordinary GUI applications; it seems to work OK, but of course is only a subset of the API and it's pretty awkward syntactically.

ocaml is cool, but ... I can't remember the details, but I have a vague recollection that it wouldn't work with the API because of runtime concurrency issues. This might have changed, it was years ago - actually I believe it was BeOS 5.03, but same difference. It would be interesting to see how the API would look wrapped in the Objective CAML OO model, which seems very good. Also ... while Objective CAML's normal syntax is quite awful, there is an alternative syntax front end option - don't remember what it was or whether it solved the worst syntactical problems, but it was a real improvement.

But as I've said before, I think you'd have to be kind of a nut to use it on Haiku, anyway. I mean, unless you already have a code base waiting to port over, C++ is really the ticket for getting a Haiku application written. I'm a nut, so I don't mean anything bad by that.

Well what you said about ocaml and the API is true but not quite :
It is true that the runtime interpreter of ocaml (in its garbage collector part) is monothreaded.
But i could made an interfacing OCaml <-> C <-> BeAPI able to communicate with Be API C++ objects.

So i was able to recode in OCaml the BeOS dynadraw3! example application, which has 3 windows so at least 4 threads.Latency was low and cpu a bit more loaded but not so much as the original C++ application.
And i don't agree with you on the syntax :) It is a pretty concise syntax in the field of functional programming, and not as bloated by symbols as Lisp could be.

I was introduced to this style in a hand-rolled Lisp, as a way to think about, in essence, multi-threading.

I think you could appreciate this also from quite the other end of the abstraction telescope, writing machine code that can't touch the CPU's native stack for whatever reason.

Couldn't say, really. There seem to be a couple other people interested in working on Haskell GHC, who for one thing I guess are more interested than I have been in trying to get it integrated into the standard platform application support system. So ... there's a minor issue with no apparent resolution that's holding things up there, but maybe there's potential there for GHC to be a supported Haiku thing. At some point; probably in time for that Beta.

I don't picture it making a very interesting demo, though. Haskell's just a programming language, that runs on Intel Haiku. It can call "foreign" entry points (i.e., C), but doesn't directly support C++, so BeOS API functionality has to come through wrappers. It would be crazy to push it as some kind of solution. What's really excellent about Haiku here is that GHC could be built at all, which wasn't the case on BeOS. Mainly because Haiku supports gcc 4.

pandoc - wow

• http://johnmacfarlane.net/pandoc/

Sorry, I've been out of action for the past 6-7 weeks, including no Internet access. I've only just got back into the digital world today, and have a lot of catch-up to do with Haiku.

Once I'm back on track with everything Haiku, I'll get an updated GHC build ready.

As for pandoc, there has been some work on Cabal recently to fix an issue with building pandoc when using dynamic linking. Hopefully I'll be able to pull in these changes to Cabal and release GHC via HaikuPorts.