System programming using FP

I do system programming. By this, I mean that I use quite a bit of various Posix/Unix APIs and (incidently) lots of TCP/UDP networking stuff on a daily basis to build long running apps that must be very, very solid, scalable and robust. I don't hear a lot about doing this type of programming using FPs and HOPLs. Actually, I don't think that I've heard of much serious system programming work outside of Erlang and (ocassionaly) O'Caml.

I've been using Standard ML (w/ Concurrent ML) these days and have fell in love (or at least a well regarded like) with The Standard ML Basis Library.

Alas, Standard ML doesn't seem to have generated much interest outside of academia. This is a shame, since the Basis covers a lot of practical system stuff.

What are the other higher order languages well suited for system programming? (And, no fair if you have to drop down to C/C++ for Posix, binary data manipulation or networking stuff.)

By Todd Coram at 2005年09月02日 02:01 | LtU Forum | previous forum topic | next forum topic | other blogs | 19077 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Haskell in the House

Well, given that House has been successfully implemented in Haskell, I'd assume that Haskell would fit your criteria. Admittedly, House is an experimental OS, rather than production one. But they have managed to implement everything from kernel though network stack, to a rudimentary GUI.

Postmaster is an MTA that's also written in Haskell. Don't know if an MTA counts as "system programming" in your book or not.

By Allan McInnes at Fri, 2005年09月02日 04:31 | login or register to post comments

Nice House

Nice. Experimental, true. But still nice.

If I can just pierce through the veil that stands between me and Haskell (everytime I think I "get it", I either pick up and read an app that leaves me completely puzzled or just stare at a blank Emacs buffer waiting in vain for code to pour from my fingers).

Postmaster looks interesting for what it intends to be: a very configurable MTA.

By Todd Coram at Sat, 2005年09月03日 22:26 | login or register to post comments

Hahaha!!

"everytime I think I "get it", I either pick up and read an app that leaves me completely puzzled or just stare at a blank Emacs buffer waiting in vain for code to pour from my fingers"

I know exactly what you mean. Many times when I look at Haskell code, I begin to wonder if it's possible to design a language that is *too* concise/expressive/terse. Then I think of awk/sed, and the answer is clear. ;>

A certain amount of redundancy can be a *good* thing.

By David B. Held at Mon, 2005年09月19日 19:23 | login or register to post comments

Haskell web server

If an MTA counts as "system programming", a web server also counts:
http://www.haskell.org/~simonmar/papers/web-server.ps.gz

The Yale Haskell group uses purely functional languages for things like robots and animations...
http://www.haskell.org/frp/

By Peng Li at Mon, 2005年09月05日 16:48 | login or register to post comments

Networking in SML...

...take a look at the old FoxNet Project stuff. It was a fully-functorized network stack implemented in SML, and one instantiation gave you TCP/IP. It ought to give you some ideas.

By neelk at Fri, 2005年09月02日 14:37 | login or register to post comments

Ensemble project

Have you taken a look at Ensemble ? it is a very interesting reliable group communications system written in OCaml that came out of Ken Birman's group at Cornell. It features composable protocol stacks and handily beats the performance of the earlier system (Horus), written in C.

By Sriram Srinivasan at Sat, 2005年09月03日 16:42 | login or register to post comments

OCaml and concurrency

I've heard of Ensemble and have recently bookmarked it for a deeper look. From what I can see, OCaml has become what Standard ML (along with the Basis Library) alluded to be: a general purpose programming language (suited for application and system programming as well as experimental stuff) with interests outside of academia.

I haven't played with OCaml in a couple of years. I believe the biggest feature missing (for me) was a preemptive concurrency model that didn't use OS threads (ala Concurrent ML). I think that is what has held me back from diving deep into OCaml.

Yes, beyond having an affinity for the Basis Library, I also have an affinity for Concurrent ML (or Erlang's concurrency approach for that matter).

By Todd Coram at Sat, 2005年09月03日 22:16 | login or register to post comments

Unix System Programming using SML

There's this book online which seems nice. I didn't read it, though.

By Andrei Formiga at Mon, 2005年09月05日 16:53 | login or register to post comments

ML aging?

This is a unique book. I read it a year ago and it influenced me enough to pursue using Standard ML in a system programming context.

But, like almost all of the ML literature I've stumbled across, in the past year, its a couple of years old and doesn't seem to have made any movement. That is, its been hard for me to find any current ML stuff.

By Todd Coram at Fri, 2005年09月09日 02:56 | login or register to post comments

Most of the current...

...work on SML has been in the context of compilers middle and back ends. There's been a LOT of work on typed compilation, and this is stuff that's mostly not visible to the programmer.

By neelk at Fri, 2005年09月09日 22:31 | login or register to post comments

Thesis Proposal Nitro: A low-level functional programming langua

The title says it all, found it through google:
Thesis Proposal Nitro: A low-level functional programming language

Looks interesting, not only does the author propose a functional language in which you can embed assembly code, he is planning on building an OS kernel using the language! Cool!

By shahbaz at Fri, 2005年09月09日 02:16 | login or register to post comments

Functional Programming and Embedded Systems

Malcolm Wallace at the University of York wrote his dissertation on functional programming and embedded systems back in 1995. From his abstract:
Four modifications are introduced to a test-bed purely-functional language [ed: I believe the language in question was Gofer] in order to facilitate embedded-systems programming: I/O register access; communicating processes; interrupts; and a real-time incremental garbage collector. Referential transparency is preserved. The conventional model of communicating processes is augmented by the use of type classes and constructor classes to add type security around message-passing.

Two case studies of embedded applications are programmed: a marble-sorter and a liftshaft. Both give encouraging results for the adequacy of the approach. Two important areas are identified for future research. (1) It is not clear to what extent lazy evaluation is a help or a hindrance in programming embedded systems. (2) Real-time expression and guarantees of schedulability would extend the attractiveness of functional languages still further.

Wallace's version of Embedded Gofer can be found here. The results that Wallace reported looked promising, but I'm not sure how much further work was done in this area. Might be interesting to update his ideas to a functional language that is currently popular.
By Allan McInnes at Fri, 2005年09月09日 16:46 | login or register to post comments

Timber

(1) It is not clear to what extent lazy evaluation is a help or a hindrance in programming embedded systems. (2) Real-time expression and guarantees of schedulability would extend the attractiveness of functional languages still further.

Both issues were raised in scope of Timber as well.

By Andris Birkmanis at Sat, 2005年09月10日 10:42 | login or register to post comments

Lazy evaluation in embedded systems.

(1) It is not clear to what extent lazy evaluation is a help or a hindrance in programming embedded systems.

Anyone has any pointers to research trying to answer this question?

By Peter A Jonsson at Sun, 2005年09月11日 07:16 | login or register to post comments

I suspect the answer is that

I suspect the answer is that it's both and that it would be good for a language to support both lazy and strict evaluation. Certainly I can think of enough applications where things like streams are useful, and enough situations where lazy evaluation could cause space issues.

By Philippa Cowderoy at Sun, 2005年09月11日 13:09 | login or register to post comments

Proving the correctness of reactive systems using sized types

It may be of some interest as it defines a FPL with both data and codata and they're able to prove some space properties about it. A later paper merges it with region types.

By Daniel Yokomizo at Sat, 2005年09月17日 16:44 | login or register to post comments

ocaml seems to be where it's

ocaml seems to be where it's at for ml these days (well, 6 monts/year ago when i was last using it). mlton was still active, but is not so good for large programs.

By andrew cooke at Fri, 2005年09月09日 19:31 | login or register to post comments

Threadlessly

I think system programming in a pure equational language (or even a pure declarative language that isn't equational) without threads would be interesting to know about, if anyone has done any work in that direction. I consider the actor model, Janus, and ToonTalk (without Sensors) to be concurrent "without threads". I gather that a properly chosen subset of Oz would also have those properties.

By Jack Waugh at Tue, 2010年02月02日 02:56 | login or register to post comments

AltStyle によって変換されたページ (->オリジナル) /