Hello
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-ml
Yamagata 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.aspx
Jacques 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).
:set foldmethod=expr
:set foldexpr=getline(v:lnum)=~'^=\\{78}$'?'<1':1
zM
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.