This project brings Objective Caml into the set of tools which allow to program PIC microcontrollers.

(via Anil)

Stalin seems pretty amazing.

I diff the txt versions of the reference manual and change the html version by hand. For the grammar rule index I use a tool and manual editing.

–Hendrik Tews

Wow. What a labor of love. Be sure to give him a hand!

(via Caml-list)

For an accessible introduction to modern (>= 3.10) Camlp4, you may be interested in Jake Donham’s blog post series “Reading Camlp4″ : http://ambassadortothecomputers.blogspot.com/search/label/camlp4
You will also find valuable (though incomplete) information on the camlp4 wiki : http://brion.inria.fr/gallium/index.php/Camlp4

The older version of camlp4 (< 3.10, now called camlp5) also provides a documentation
http://caml.inria.fr/pub/docs/tutorial-camlp4/index.html , and you can also use to Martin Jambon’s tutorial
http://martin.jambon.free.fr/extend-ocaml-syntax.html (for the older camlp4).

– bluestorm

You can also see the articles in sequence at

http://ambassadortothecomputers.blogspot.com/p/reading-camlp4.html

which I recommend since later articles depend on earlier material.

– Jake Donham

Shameless self-plug, but I wrote a blog post this summer about my experience figuring out how to do it. I provide a walk-through and explanation of a minimal syntax extension which adds lazy list pattern matching support based on Batteries. The URL:

http://www.elehack.net/michael/blog/2010/06/ocaml-syntax-extension

I do assume a basic knowledge of parsing context-free grammars, but a generic tutorial on parsing with a tool such as Yacc can fill in that gap. The Wikipedia article[1] may also be helpful.

Once you’ve lept the hurdle of figuring out what pieces you need to write and build a syntax extension, the remaining tricky part is to figure out what pieces of the grammar you need to extend to accomplish your objective. For that, I consult the definition of the OCaml parser in Camlp4OCamlParser.ml in the OCaml source tree.
1. http://en.wikipedia.org/wiki/Context-free_grammar

– Michael Ekstrand

If you consider yourself as a n00b, don’t start by camlp4. This is probably the most difficult part of OCaml — and to program camlp4 you need to use OCaml standard syntax (or revised syntax, it depends if you
use antiquotations).

If you still want to follow the hard path, as suggested elsewhere, Jake Donham’s blog posts are very good:

http://ambassadortothecomputers.blogspot.com/p/reading-camlp4.html

Or if you are around, there is a tutorial session at CUFP:
http://cufp.org/conference/sessions/2010/camlp4-and-template-haskell.
(but you need to subscribe).

– Sylvain Le Gall

(via Caml-list)

(via Caml-list)

Via Sylvain via LinkedIn-Ocaml Developers.

I’m very proud to announce Ocamlnet 3.0.0, a completely overhauled version of Ocamlnet.

Wish I had some problems that needed solving with ocamlnet!

(via caml-list)

The library delimcc directly implementing delimited continuations on
OCaml now supports native code (ocamlopt) on selected platforms.

http://okmij.org/ftp/continuations/caml-shift.tar.gz

The library delimcc implements shift/reset, prompt/control, shift0,
control0 delimited continuation operators with multiple, arbitrarily
typed prompts. The delimcc implementation is direct: it copies only
the relevant fragment of the OCaml stack. The implementation is fully
integrated with OCaml exceptions: exception handlers may be captured
in delimited continuations (and re-instated when the captured
continuation is installed); exceptions remove the prompts along the
way. The implementation has no typing problems, no bizarre ‘a cont
types, and no use for magic.

The library delimcc does *no* patching of the OCaml system and is a
regular (static or dynamically-loaded) library. The library is
therefore _perfectly_ compatible with any existing OCaml code, source
or binary.

The native- and byte-code versions of the library implement the
identical interface, described in delimcc.mli. Furthermore, the OCaml
code for the two versions is identical. Only the C code files,
implementing scAPI, differ for native-code.

Using the native-code version is identical to the byte-code version of
delimcc. No source code has to be changed; it has to be compiled using
ocamlopt rather than ocamlc.

This is the first release of the library, for OCaml 3.11. It has been
tested on i386 (x86_32) platform, on FreeBSD and Linux. The library
could perhaps be used on other platforms (on which stack grows
downwards); x86_32 is the only platform available to me. At any write,
the library contains no custom-written assembly code (although I
couldn’t avoid reading a lot of assembly code).

This is the first release of the native-code version, hence stressing
correctness at the expense of performance. A notable performance drain
is emulating data types with a custom GC scanning
function. Custom-scanned data types are possible without any changes
to OCaml, thanks to the provided GC hooks. Alas, the emulation doesn’t
seem to be efficient. A co-operation from the OCaml system would be
greatly appreciated. I have a hunch that custom-scan data types could
be useful for many other applications, for heap-allocating structures
with OCaml values intermixed with unboxed data.

It should be noted that the very operation of capturing and
reinstalling a delimited continuations will always be faster in
byte-code than in the native code. First of all, the byte-code
delimited continuation is smaller. Second, it is a uniform a sequence
of values or code pointers. In contrast, the corresponding captured
native-code delimited continuation — the portion of the C stack — is
not only bigger, but also contains unboxed values. We have to use
frame tables to figure out which stack slots contain live heap
pointers. Saving native-code delimited continuation is inherently more
complex. In fact, all the complexity of the native-code delimcc was
tidying the stack to please GC.

One should keep in mind the fundamental limitation of native-code
delimited continuations — the limitation that also holds for Scheme
and other systems with delimited control. The limitation concerns
capturing continuations in the OCaml code invoked as a call-back from
C code, which was, in turn, called from OCaml. It is safe to capture a
delimited continuation in the callback _provided_ the extent of the
captured continuation is limited to the call-back. The continuation
captured in the callback may be resumed within the call-back or after
the call-back has exited. One must not capture the continuation
through the C code that invoked the call-back. In short, no C frames
may be captured in delimited continuations. The library detects C
frames in captured continuations, and throws a run-time error. Such a
behavior of delimcc is consistent with the behavior of native-code
Scheme systems.

(via Caml-list)

* Favor readers over writers
* Create uniform interfaces
* Make illegal states unrepresentable
* Code for exhaustiveness
* Open few modules
* Make common errors obvious
* Avoid boilerplate
* Avoid complex type-hackery
* Don’t be puritanical about purity

(via janestreet)

When asked how they deal with the inevitable difficulty in hiring OCaml programmers, Yaron replied something to the effect that:

If you don’t hire bad programmers, many things become easier.