Here is the latest Caml Weekly News, for the week of 30 November to 07 December, 2004.
Archive: http://caml.inria.fr/archives/200411/msg00257.htmlAs a followup to last week's discussion, Vincenzo Ciancia said:
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.Florian Hars added:
> 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.htmlRichard Jones said:
Archive: http://caml.inria.fr/archives/200412/msg00017.htmlTom Hawkins asked and Kenneth Knowles answered:
> 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...Christian Lindig added:
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.
Here is a quick trick to help you read this CWN if you are viewing it using vim (version 6 or greater).
If you know of a better way, please let me know.
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.