caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Lyn A Headley <laheadle@midway.uchicago.edu>
To: caml-list@inria.fr
Subject: ML extension language
Date: Thu, 27 Feb 1997 17:14:06 -0600	[thread overview]
Message-ID: <199702272314.RAA18638@kimbark.uchicago.edu> (raw)

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






             reply	other threads:[~1997-02-28 11:28 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1997-02-27 23:14 Lyn A Headley [this message]
1997-02-28 14:03 ` Xavier Leroy
1997-02-28 20:46 ` Stefan Monnier
1997-03-01 12:41 ` Francois Rouaix
1997-02-28 18:28 Robbert VanRenesse

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=199702272314.RAA18638@kimbark.uchicago.edu \
    --to=laheadle@midway.uchicago.edu \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).