Re: ML extension language

Re: ML extension language

[Robbert VanRenesse]

You may also wish to look at Camouflage 1.1 (from
ftp://www.cs.cornell.edu/pub/rvr/camou-1.1.tar.gz)
and camlp4 (in ftp://ftp.inria.fr/lang/chamau/).

Camouflage 1.1 is a tool that supports interfacing between C and OCaml.
Camouflage reads a .mli file and creates the necessary C interfaces to
the given module.  This way the fact that a library is written in OCaml
can be ``camouflaged.''  Camouflage also supports creating OCaml interfaces
to C functions, and generates functions that convert between OCaml and C
data structures.

For example, let say "x.mli" contains the declaration "val add: int ->
int -> int".  Then the command "camou x.mli" creates a file "x.c" that
contains the C function "int X_add(int, int)" which does all the stuff
necessary to invoke the ML function.  Vice versa, the declaration
"external add: int -> int -> int" creates an ML function to invoke
a corresponding C function called add of that same signature.

Hopefully Xavier's stuff will make all this obsolete so I don't have
to support this any more!

Robbert

At 03:03 PM 2/28/97 +0100, Xavier Leroy wrote:
>> I realize that CAML already contains facilities for creating new
>> primitives in C, but the main difference is that in a caml program,
>> the main program is the interpreter for the caml virtual machine, whereas
>> in an extension language control resides in the application.
>
>Actually, it is possible to have the main program written in C and
>calling Caml functions when needed. Release 1.03 contains very
>preliminary support for this; the forthcoming release 1.04 provides
>better support and documentation for this feature.
>
>- Xavier Leroy
>
>
>
>

Re: ML extension language

[Francois Rouaix]

> A main advantage of extension languages is that they enable a high
> degree of portability, thereby facilitating the availability of (in
> this case) functional programming tools.  More specifically, instead
> of requiring the user to install an interpreter at their site to be
> able to run their application, the application *is* an interpreter for
> its own private language.

The availability of an extension language does not mean that the application
will be portable. The application itself has to be portable in the first place.
Of course, having a portable extension language allows extensions to be
portable as well.

> but the main difference is that in a caml program,
> the main program is the interpreter for the caml virtual machine, whereas
> in an extension language control resides in the application.
Even with the current releases of Caml, it may be a little more complex:
for example, in a CamlTk application, the control is essentially in the
event loop, which belongs to Tk. Moreover, using client/server, RPCs, threads
and whatever, it's "easy" to have several co-existing control flows.

> Thus far, I plan
> to use almost the entire caml-light runtime system, and write a different
> compiler (in C) for a simpler, but (hopefully!) still powerful language.  
The advantage of Caml over Scheme, Python, Tcl or Rexx is that it is 
*statically* strongly typed. The Caml runtime system knows nothing of types;
it simply provides a reasonably efficient portable platform to execute
strict functional and imperative programs.

If you want to define a language "simpler" than Caml, but that has
basically the same operational semantics as well as a strong polymorphic
static type system, it seems to me that your problem
is essentially a syntax problem (e.g. you consider some features of Caml
as superfluous for extension languages, or that you need additionnal 
constructs (such as specific application-specific control-flow)).

You might then want to have a look at Chamau/Camlp4 and related work
in extensible syntax (http://pauillac.inria.fr/~ddr/)

--
Francois.Rouaix@inria.fr                   Projet Cristal - INRIA Rocquencourt
WWW Home Page: http://pauillac.inria.fr/~rouaix/

Re: ML extension language

[Stefan Monnier]

Lyn A Headley <laheadle@midway.uchicago.edu> writes:
> Do people see this as worthwhile project, and one that is fairly
> different from existing facilities?  It is interesting that *all*
> existing extension languages are weakly typed, and it would be neat to
> see what a polymorphically typed one could offer.  Thus far, I plan
> to use almost the entire caml-light runtime system, and write a different
> compiler (in C) for a simpler, but (hopefully!) still powerful language.  

I recently considered adding an extension language to the ctwm window-manager
in order to replace its clunky and limited .ctwmrc configuration facility. I
gave up because the only convincing (implementation) language available was
O'Caml, but it would have required to start by rewriting the event loop in
O'Caml so as to have O'Caml call C rather than the opposite.

I'd love to see an "embedded O'Caml". Rather than write a new language, it
seems that it would be easier/better to hack O'Caml directly so as to keep the
whole language and even hopefully get the changes folded in the official
distribution. From the little I know of the working of the run-time system, it
looks like the main problem with calling O'Caml from C has to do with GC, but
it seems doable. The easiest path might be to have "main" call O'Caml (just as
it already is) and then have O'Caml's main function do just the basic
initialization and then immedialtely call the main C function (so that the C
code actually runs within O'Caml).


        Stefan

Re: ML extension language

[Xavier Leroy]

> I realize that CAML already contains facilities for creating new
> primitives in C, but the main difference is that in a caml program,
> the main program is the interpreter for the caml virtual machine, whereas
> in an extension language control resides in the application.

Actually, it is possible to have the main program written in C and
calling Caml functions when needed. Release 1.03 contains very
preliminary support for this; the forthcoming release 1.04 provides
better support and documentation for this feature.

- Xavier Leroy

ML extension language

[Lyn A Headley]

dear caml-list,

I'm hoping, as a bachelor's project for my computer science degree,
to implement an extension language which is a dialect of ML.  

If you aren't familiar with extension languages, an extension language
is meant for making applications customizable to a high degree.  The
usual procedure is that one writes the core of an application in C/C++
and then adds new primitive functions and types (created by the user)
to the extension language.  Then much of the coding for the
application is done in the extension language and many opportunities
are presented to the user to radically change the innards of the
application.  Emacs Lisp is probably the most famous extension
language, but there do exist languages which can be used with any
application, such as lua(http://www.inf.puc-rio.br/~roberto/lua.html),
and elk(http://www-rn.informatik.uni-bremen.de/software/elk/,
and (kind-of) python(http://www.python.org),
and tcl.

A main advantage of extension languages is that they enable a high
degree of portability, thereby facilitating the availability of (in
this case) functional programming tools.  More specifically, instead
of requiring the user to install an interpreter at their site to be
able to run their application, the application *is* an interpreter for
its own private language.

Another nice thing about ex langs is that they increase efficiency, by
allowing time-critical functions to be coded in a low-level, compiled 
language.  But the best thing is to allow for highly customizable
applications.

I realize that CAML already contains facilities for creating new
primitives in C, but the main difference is that in a caml program,
the main program is the interpreter for the caml virtual machine, whereas
in an extension language control resides in the application.

Do people see this as worthwhile project, and one that is fairly
different from existing facilities?  It is interesting that *all*
existing extension languages are weakly typed, and it would be neat to
see what a polymorphically typed one could offer.  Thus far, I plan
to use almost the entire caml-light runtime system, and write a different
compiler (in C) for a simpler, but (hopefully!) still powerful language.  

I just wanted to post this to see what comments could be heard from
the caml light community.

Lyn Headley