Here is the latest Caml Weekly News, for the week of 20 to 27 April, 2004.
Having learned ML and several other functional languages in a programming class, I decided that it would be nice to be able to program in a functional language on my Mac. I chose caml for various reasons, partly because of the clean foreign-function interface. To make the language useful for more than command-line apps, I'm writing a bridge between caml and Objective-C (specifically, Cocoa). I have little experience in caml itself, and so have no intuition about idiomatic programming, especially with objects (most of my functional experience is in ML). What I want to know is, what would be a clean and idiomatic interface to this bridge on the caml side? Things that I've been considering in the design: -- Except by parsing the objective-c header files, you can't know what types a function takes and returns, and in particular it may return null. This is especially the case in objective-c because types and bindings are dynamic. As a result, you can't know much about a method when calling it from caml other than the number of arguments it takes, or even if the object answers it. (if it doesn't, this should throw an exception). -- You can send messages to nil in objc, and it will return nil. -- Objective-C uses 32-bit integers, but most methods that use them accept and return small numbers. The current model is to use ints, but throw an exception if it overflows... I'll probably add an int32 type to the interface as well for those times when this is unacceptable. -- Common things that would have to go across the interface quite often would be NSArray <=> list and NSString <=> string. These may be important enough to warrant special handling. -- Memory management can be messy. I've written the core of the bridge, at least in the caml->objc direction, and it works on a hello world program. The model is to look up classes and selectors (essentially methods) by name, and then to pass messages to a class or to an object. It consists of some datatypes and foreign functions in a module: >module ObjCGlue = struct >type objcid >type objcclass >type objcsel > >type cobj = NULL > | BOOL of bool > | INT of int > | CHAR of char > | STR of string > | FLOAT of float > | ID of objcid > | SEL of objcsel > | CLASS of objcclass > > (* starts up the runtime system, allocates an autoreleasepool *) > external _start : unit -> unit = "camlGlueStartup" > > (* returns a selector of the given name. remember those colons! *) > external _selNamed : string -> objcsel = "camlGlueStrToSel" > > (* returns a class of the given name, or null if none exists. >perhaps should throw an exception instead *) > external _classNamed : string -> cobj = "camlGlueStrToClass" > > (* sends a message to an object *) > external _message : objcid -> objcsel -> cobj list -> cobj > = "camlGlueMessageSend" > > (* invokes a class method *) > external _classMethod : objcclass -> objcsel -> cobj list -> cobj > = "camlGlueClassMethod" > > (* ... lots convenience functions to make testing easier ... *) >end;; Any suggestions would be much appreciated.
GODIVA 0.9.0 has been released as GODI package godiva-0.9.0. GODIVA, the GODI Verpacken Assistant, is a tool for making GODI packages. GODI is the holy grail solution to O'Caml's package management problems, but the interface for creating packages, being based on NetBSD pkgsrc, is frequently overly complex. GODIVA provides a solution by accepting a comparatively simple package specification and transforming it into a full and proper GODI package. Version 0.9.0 is a complete rewrite with updated documentation and some interface improvements. GODIVA was previously known as GODOR. GODIVA is constantly undergoing improvement, and now is a great time to try it out and influence its future directions. Join the illustrious ranks of the O'Caml code packaging community today! GODIVA webpage: http://projects.phauna.org/GODIVA/ GODI package: godiva-0.9.0 Release tarballs: http://projects.phauna.org/GODIVA/release/godiva-0.9.0.tar.bz2 http://projects.phauna.org/GODIVA/release/godiva-0.9.0.tar.gz Enjoy! William Lovas Owen Gunden GODIVA developers
YaM 1.0 initial release, another OCaml build system... [please don't use it to feed the GODI vs. Make vs. Glou debate] YaM is a single module, for writing OCaml code builders with : * really fine dependency analysis : - file digest - compilation command digest - cmi/cmo/cmx intelligent handling * fine compilation flags tuning * support for "-pack" * "OCaml self-containment" but.. * no support for CamlIdl, CamlReport, Zoggy * not as generic as Make / OCamlMakefile / Ocamake Homepage : http://perso.ens-lyon.fr/damien.pous/shared/ocaml/YaM/
How am I supposed do do OCaML program development under Windows ? I have tried - the OCaml Workspace that came with 3.07, but it is so buggy, it doesn't even handle copy/paste correctly. - Ultraedit, but none of the executable programs in the /bin directory allow me to do get the interactive behaviour from the workspace. I recall that Caml-Light had some usable interface -- is this available for OCaML ? Please don't advise me to use emacs, I'd rather switch languages ...Wolfgang Müller answered:
> Please don't advise me to use emacs, I'd rather switch languages ... In fact, I find tuareg (the OCaml style under XEmacs) truly amazing. And if you use XEmacs under windows, you have about all the key shortcuts also as menu points. What do you find so offputting in XEmacs? I know you're Prof. and things have to go fast if you want to squeeze in a little programming, but I find tuareg is definitely worth it.Jacques Garrigue answered the OP:
You can try ocamlbrowser, it comes with both a shell and an editor. The only difficulty is to find the right version of Tcl/Tk on the internet. (I believe it is still compiled for Tcl/Tk8.3, but I hope to be wrong.)Yaron Minsky answered the OP:
I've never used it, so I can't say much about it's quality or ease of use, but there is a Visual Studio plug in: http://tech.motion-twin.com/visual-mlYamagata Yoriyuki answered the OP:
I have not used it, but there is an editor for SML and OCaml on Windows called MLEdit. http://www5a.biglobe.ne.jp/~sasagawa/MLEdit/english/home.html
> I'd like to give a try to the native Win32 port for OCaml. > > 1. Is the free (as in free beer) Visual C++ 2003 toolkit enough for > ocamlopt ? I just checked, it's not since masm.exe is not part of it :'( > 2. I'm stuck at step 0: installing MASM. Could anyone give me an exact URL > where I could find it ? It's part of the VC++6 Processor Pack : http://msdn.microsoft.com/vstudio/downloads/tools/ppack/download.aspxJacques Garrigue added:
> > It's part of the VC++6 Processor Pack : > > http://msdn.microsoft.com/vstudio/downloads/tools/ppack/download.aspx > > Which requires to have Visual Studio installed... > Actually, you can extract it without visual studio installed: http://users.easystreet.com/jkirwan/pctools.html I really wonder why microsoft makes access to masm that hard...
Some of you may remember my complaints about missing functions in the standard library. To help address those, I have started work on my own OCaml library to augment the standard functions. You can obtain it, along with online API docs covering every function, at: gopher://quux.org/1/devel/missinglib or http://quux.org/devel/missinglib [Debian users: I have uploaded it to sid, but will take a few days to appear.] Some excerpts from the README: Missinglib is a collection of OCaml-related utilities. The following modules are are provided: ConfigParser System for parsing configuration files Hashtbloper Hash table convenience operators Hashtblutil Hash table utilities Lexingutil Lexing-related utilities Listutil List-manipulation utilities Slice Underlying API for Slice operators Sliceoper Flexible subparts of arrays, lists, and strings Streamutil Stream parser utilities Strutil String-related utilities The entire library has no prerequisites save the OCaml standard library and findlib and is designed to install without complexity on a variety of systems. It could also easily be embedded within your own source trees so that users need not have it installed beforehand. ---------- I would greatly appreciate constructive criticism on any aspect of the package, especially the build system. I have tried to make it possible to "make; make install" on just about any platform, regardless of availability of ocamlopt. It took some hoop-jumping, though, so suggestions are welcome :-) Some basic info on the modules present: The ConfigParser module can read and write sectioned .INI-style files and is mostly compatible with Python's ConfigParser module. Sliceoper defines some more powerful ways of indexing arrays, lists, and strings (some of these concepts were discussed on this list). Strutil provides functions like strip, lstrip, and rstrip (removes whitespace from either end, beginning, or end, of a string). Listutil provides a "replace" that is analogous to Hashtbl.replace, but for association lists; and "sub" that is similar to String.sub or Array.sub. Hashtbloper defines some more useful ways of working with hash tables, such as: hash /> 5 is the same as: Hashtbl.find hash 5 let sections = Hashtbl.create 5;; let options = Hashtbl.create 5;; Hashtbl.replace options "option1" "value1";; Hashtbl.replace sections "section1" options;; sections /> "section1" /> "option1";; returns "value1" let newhash = hash // ("key", "value");; (Copies hash, adds the pair to the copy, and returns it -- similar in concept to :: for lists)Editor's note:
This announcement started a huge discussion on existing extensions to the standard library. You can find the start of this thread here: http://caml.inria.fr/archives/200404/msg00539.html
I've written a small patch to Ocaml-3.07 to do some memory profiling on running programs. The patch requires to recompile and install Ocaml, and to recompile your program with it. It doesn't cost anything during the execution of the program, it just requires a call to "Gc.dump_heap" at some point to dump an image of the memory on disk that will be used by the analyser, that will display the memory retained (per root) and used (per type of data), at least when it can identify them. It's just a 3-days work, thus it needs still to be improved a lot, but I could find the bug I was looking for thanks to it, so I think it is worth a first beta release... http://pauillac.inria.fr/~lefessan/src/memprof-ocaml-3.07.tar.gz
I have created a new tarball for version 1.0.6 of the Felix programming language here: http://felix.sourceforge.net/download.html http://felix.sourceforge.net/flx_1.0.6_src.tgz and would appreciate if a few people would try to build it on any Unix like platform to help iron out build bugs. So far it has built on Linux and OSX, but there are still likely to be some g++ and libc portability issues. I have one report of a Cygwin build of an earlier version. Requires: Python 1.5.2 or above, Ocaml 3.07 or current CVS version, C++ compiler (preferably recent g++). Native code version should build if available, bytecode is then optional. Bytecode should build if native code compiler isn't available. A native Windows port should be possible but would require a considerable investment of time and effort at this stage. Brief description: Felix is an Algol like strongly typed procedural programming language with a strong purely functional subsystem, including first class functions, pattern matching, variants, recursion, and (currently only) compile time parametric polymorphism. A scripting harness is used to provide convenience of rapid prototyping engines like Python, but the output is fully compiled binary not bytecode. Version 1.0.6 now supports both dynamic loading and static linkage. Felix uses arbitrary first class existing C/C++ types and functions as primitives and therefore does not require any complex library bindings. Cooperative multi-tasking is built into the system allowing code to be written in a threaded style whilst retaining the the high performance of an event-driven programming model. The target market is: middleware applications, existing C/C++ frameworks, systems which require extensive binding to existing C/C++ libraries, and those which require a high performance event driven dispatching model. Numerical programming may also benefit from the expanded typing and seamless binding technology.
You can find the version 1.1 of my Ocamljit just-in-time bytecode to machine language translator & interpreter on http://cristal.inria.fr/~starynke/ocamljitrun.tar.gz See also my homepage on http://cristal.inria.fr/~starynke/ for remarks The following bugs fixes have been made: callbacks run correctly the toplevel run correctly (both runs correctly on small tests - I did not test yet significant stuff for C callbacks and toplevel) all simple tests (those in ocaml/tests) and the ocamlc compiler itself already passed on the initial release, of course they pass again. You need the latest CVS of the Ocaml system - since I had to correct some callback code (in byterun/callback.c) and to add a routine caml_prepare_bytecode in the runtime (also called by the toplevel) If some people test the latest CVS of Ocaml, I would be delighted if they took some time to test this ocamljitrun and report bugs to me. Ocamljitrun may sometimes run slower than the bytecode interpreter: When running a very short time (eg running ocamlc on a small source file), because of the startup time needed for bytecode -> machinecode translation Callbacks (from C to ocaml) are more expensive, since every callback requires translation of a short bytecode sequence. Thanks, and hoping for some feedback.
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.