caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Francois Rouaix <rouaix@ephemere.inria.fr>
To: Lyn A Headley <laheadle@midway.uchicago.edu>
Cc: caml-list@inria.fr
Subject: Re: ML extension language
Date: Sat, 01 Mar 1997 13:41:12 +0100	[thread overview]
Message-ID: <199703011241.NAA04352@ephemere.inria.fr> (raw)
In-Reply-To: Your message of "Thu, 27 Feb 1997 17:14:06 CST." <199702272314.RAA18638@kimbark.uchicago.edu>

> 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/






  parent reply	other threads:[~1997-03-03  8:05 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1997-02-27 23:14 Lyn A Headley
1997-02-28 14:03 ` Xavier Leroy
1997-02-28 20:46 ` Stefan Monnier
1997-03-01 12:41 ` Francois Rouaix [this message]
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=199703011241.NAA04352@ephemere.inria.fr \
    --to=rouaix@ephemere.inria.fr \
    --cc=Francois.Rouaix@inria.fr \
    --cc=caml-list@inria.fr \
    --cc=laheadle@midway.uchicago.edu \
    /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).