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).
Maybe the word “functional” doesn’t mean anything to you except “working” but I believe it was intended here in its technical sense. Pascal (FPC) and BASIC (Yab) are procedural languages, of course you can insist on programming in functional style, but the languages don’t provide good support for that style.
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.
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’ve heard that before, but then even more people don’t use Objective CAML at all, so we may infer from this that the OO features are especially worth checking out! It’s sure a breath of fresh air after mucking around in the more popular OO languages.
The syntax problem that comes to mind is the way “;” joins statements, which becomes confusing and possibly counter-intuitive at the end of nested blocks. The alternative syntax compiler documentation gets into this and more: The revised syntax
Rumor has it that the Haiku Beta 1 will be arriving early Spring timeframe. The platform is stabilizing and we are putting together a list of supported applications, development tools, demos, to showcase Beta 1 and Haiku itself. What are the chances we could demo an early version of GHC?
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.