[cap-talk] Confessions of a C programmer

[Stiegler, Marc D]

Markm's recommendation of Emily, and Ben's recommendation of C#/DotNet, suggest that Ocaml is the place to start -- learn Ocaml, and you are already writing Emily (if you want to go to ocap guarantees) and F# (which has a subset so similar to Ocaml that it compiles Ocaml, with a couple of caveats).

Learning Ocaml from the standard texts on the web will be painful. I did actually write a draft of Emily in a Walnut that I could dig up for you if you are serious. The difference is, traditional texts focus on functional programming and mention imperative programming in passing. I, on the other hand, focus on imperative, c-style programming, and mention functional programming in passing :-) And I can give you a short course on it at a Friday meeting :-) 

Ocaml is already used for soft-real-time device drivers despite having automatic garbage collection -- the collector is really fast and pause-resistant. It was even used to write an operating system, as a graduate student exercise. As markm mentioned, it compiles to C and launches as fast as C. However, there is no way with ocaml to launch true threads, which you might care about. For concurrent Ocaml, I built a promise pipelining library that used linux processes, pretty heavyweight. There is a variant, jocaml, about which I know nothing but it's designed for concurrency, one way or another. F# has other alternatives for multithreading. The benchmark for F# I saw was so good that I'm suspicious it was incorrect. F# has a properly tricked out IDE, there are plugins with both Mono on Linux and with Visual Studio.

Ocaml's type checking is powerful enough so that null pointer exceptions are literally impossible, unless it bubbles up from a library package written in C. F# allows you to write programs that can only get null pointer exceptions from dotnet and c libraries, but to work smoothly with dotnet, reintroduced the ability for the programmer to create his own null pointer exceptions if he wants to ("you can write FORTRAN in any language" :-)

--marcs

> -----Original Message-----
> From: cap-talk-bounces at mail.eros-os.org 
> [mailto:cap-talk-bounces at mail.eros-os.org] On Behalf Of Mark Miller
> Sent: Monday, September 21, 2009 2:24 AM
> To: General discussions concerning capability systems.
> Subject: Re: [cap-talk] Confessions of a C programmer
> 
> On Sun, Sep 20, 2009 at 11:51 PM, Bill Frantz 
> <frantz at pwpconsult.com> wrote:
> > We all know a long list of reasons why writing in memory-safe 
> > languages produces safer, more reliable code than writing in 
> > memory-unsafe languages such as C. So why do I, and others, 
> continue to write in C?
> >
> > My last major project was the web-key server for CapROS. Like most 
> > real-world programming, it faced a deadline. What I needed from a 
> > language
> > was:
> 
> I suggest Emily on OCaml.
> 
> 
> >  Familarity - I learn languages slowly, and time spent 
> learning a new 
> > one
> >  needs to be justified.
> 
> -1. But you may find OCaml either excessively easy or hard to 
> learn, depending on how your brain is wired. It might help if 
> you could get a certain someone developer to write Emily in a 
> Walnut ;).
> 
> 
> >  Reliability - I don't want to spend time debugging the 
> compiler and I
> >  really don't want to debug a code generator which changes the 
> > semantics
> >  of my program.
> 
> +1.
> 
> >  Minimal environment - The compiler and runtime should not depend on
> >  anything but the non-privileged architecture of the 
> hardware platform.
> >  All privileged instructions/system calls should come from library
> >  routines[1].
> 
> +1.
> 
> >  Library routines for required subsystems - I needed a SSL/TLS
> >  implementation and ended up using OpenSSL, which is written in C. 
> > Being
> >  able to call C programs would cover a lot of this requirement.
> 
> +1?
> 
> >  Support for the target platform(s).
> 
> IIUC, OCaml is implemented by portable compilation to C, and 
> so should be supportable everywhere C is supported.
> 
> 
> > The question is, what memory-safe languages even begin to 
> meet these 
> > requirements? BitC, which is designed for formal verification and 
> > low-level system implementation might be a possibility.
> 
> Now that both Shap and Swaroop are at Microsoft, what is 
> BitC's status? I would guess that it is abandoned. Has 
> someone else picked it up?
> 
> > Are there any others? It
> > would be worth some effort to learn at least one of these languages 
> > and help it grow up to have the reliability needed for 
> deadline-driven work.
> >
> > Cheers - Bill
> >
> > [1] While GCC only generates user-mode instructions, the 
> documentation 
> > does not state which library calls generate system calls. 
> This issue 
> > was particularly difficult with OpenSSL, where I had to stub out a 
> > number of library routines which issue system calls. To 
> make it even 
> > more interesting, these routines had slightly different 
> names on the 
> > two platforms (arm and x86).
> 
> I would guess OCaml inherits this problem from C.
> 
> 
> > 
> ----------------------------------------------------------------------
> > --- Bill Frantz        | The first thing you need when  | Periwinkle
> > (408)356-8506      | using a perimeter defense is a | 16345 
> Englewood 
> > Ave www.pwpconsult.com | perimeter.                     | 
> Los Gatos, 
> > CA 95032 _______________________________________________
> > cap-talk mailing list
> > cap-talk at mail.eros-os.org
> > http://www.eros-os.org/mailman/listinfo/cap-talk
> >
> 
> 
> 
> --
> Text by me above is hereby placed in the public domain
> 
>     Cheers,
>     --MarkM
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
>