Hello

Here is the latest Caml Weekly News, for the week of 30 November to 07 December, 2004.

1. Functional Reactive Programming in OCaml?
2. Developing Applications with Objective CAML reviewed on Slashdot
3. Tools module for the Standard Lib

Archive: http://caml.inria.fr/archives/200411/msg00257.html

Benjamin Pierce wrote:
> The common idea in these systems is to introduce an abstraction of
> "signals" -- roughly, functions from time to "values", where the
> values can be anything from real numbers (conventional
> signal-processing-type signals) to two- or three-dimensional
> pictures, to booleans (representing events). What's special is that
> time is represented as a continuous, real-number quantity.  They do
> all kinds of work behind the scenes to actually compute with
> behaviors, but what shows through in the API is a very simple,
> elegant, and powerful set of primitives that can be combined in
> straightforward ways to achieve very complex effects.

I am surely not an expert on the subject, but I tried this at home in a 
student project at university. I wrote a library for composition of 
monomorphic signal functions. It was just a simple attempt but I found 
two things:

1. arrow composition in haskell can be very efficient - you usually 
implement your actions in terms of IO actions, and IO actions 
composition is _I suppose_ optimized somewhat by the compiler, e.g. 
inlining functions as needed to form a bigger code block. However you 
can compose as many arrows as you want without degrading performance.

Parallel or sequential arrow composition in ocaml will certainly involve 
- as in the haskell implementation - something "like" function 
composition, and this will result in efficiency proportional to the 
number of functions involved, which is unwanted. The performance gap 
between an event-based loop and "fran-like" code is discouraging for 
this reason. But you could generate bytecode at runtime and avoid this 
problem (and even beat haskell to please your language envy :)). I 
would seriously consider the second alternative if I had the time to 
work on it.

2. you are sometimes constrained to reveal implementation of your arrows 
when implementing composition, due to the value restriction - you 
certainly know this better than me, and I couldn't explain this 
anymore, the search function on the mailing list archives is not 
working or else I'd find an example I posted years ago and forgot 
about :) If you are interest I'll download the raw archives and find 
it.

Hope this helps - I would be interested in an implementation of FRAN for 
ocaml even if I am not so sure that I might be of any help.
    

> the search function on the mailing list archives is not 
> working or else I'd find an example I posted years ago and forgot 
> about :)

http://groups.google.com/groups?q=vincenzo%20caml-list%20arrow
works for me, at least if October 2003 qualifies as "years ago".
    

Archive: http://caml.inria.fr/archives/200412/msg00000.html

http://books.slashdot.org/article.pl?sid=04/11/30/2129226&tid=156&tid=6
    

Archive: http://caml.inria.fr/archives/200412/msg00017.html

> Recently I've been reorganizing my build process for Confluence -- it's 
> a hardware design language implemented in OCaml.
> 
> A few days ago a Confluence user made an interesting suggestion: why not 
> use OCaml to build OCaml applications?  He then proceeded to write an 
> OCaml script to generate the lexers and parsers, compile the interfaces 
> and implementations, then link everything together.

I did a similar thing with ocamlconf (currently don't have time to maintain it,
though), except it generates a Makefile from a high-level spec.  I think getting
the "make" logic into O'Caml is the right way to go, and it'll make it easier to
experiment with different build strategies, such as the fixpoint iteration
Skaller has brought up, or some constraint->action (a la Dijkstra's guarded
commands) approach that would subsume fixpoint and traditional make.
 
> Extrapolating on this idea, it would be advantageous to have a "Tools" 
> module in the standard library to provide an interface to ocamlc, 
> ocamlopt, ocamllex, ocamlyacc, ocamldep, and all the other tools.  Such 
> a module would provide first-class ADTs for data that is currently 
> represented in files: .ml, .mli, .mll, .cmi, .cmx, etc.  For example:
> 
>    let my_ml = Tools.ml_of_file "my.ml" in  (* or ... *)
>    let gen_ml = Tools.ml_of_string "print_string \"hello!\"" in
> 
> With such a framework, the complexity of the build process is 
> encapsulated in a program.  After your process is complete, write out 
> the final executable:
> 
>    Tools.output_exe some_channel my_compiled_application
> 
> Just an idea.

Sounds like a polyvalent program:
http://www.catb.org/~esr/writings/taoup/html/ch11s07.html#id2960228

I think this is an admirably flexible way to design tools of all sorts, but it
might force too much stability on the compiler's internals.  A user could
implement this module using tempfiles and storing whole file contents in
memory.. actually I guess there'd be a problem parsing reasonable exceptions
from the error messages...
    

In my experience, all serious projects have to deal with more than one 
kind of source language: besides OCaml there could be TeX for 
documentation, Troff for manual pages, input for special-purpose code 
generators like Burg, and so on. A build system must be able to deal 
with all of them. Therefore your proposal would not eliminate the need 
for a general build tool outside of OCaml.
    

Using folding to read the cwn in vim 6+

Here is a quick trick to help you read this CWN if you are viewing it using vim (version 6 or greater).

:set foldmethod=expr
:set foldexpr=getline(v:lnum)=~'^=\\{78}$'?'<1':1
zM

If you know of a better way, please let me know.

Old cwn

If you happen to miss a CWN, you can send me a message and I'll mail it to you, or go take a look at the archive or the RSS feed of the archives.

If you also wish to receive it every week by mail, you may subscribe online.

Alan Schmitt