From mboxrd@z Thu Jan  1 00:00:00 1970
Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id KAA17704 for caml-redistribution@pauillac.inria.fr; Thu, 13 Apr 2000 10:14:09 +0200 (MET DST)
Resent-Message-Id: <200004130814.KAA17704@pauillac.inria.fr>
Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id UAA02785 for <weis@pauillac.inria.fr>; Wed, 12 Apr 2000 20:06:07 +0200 (MET DST)
Received: from davidb.org (adsl-216-103-8-60.dsl.sndg02.pacbell.net [216.103.8.60])
	by nez-perce.inria.fr (8.8.7/8.8.7) with SMTP id UAA09619
	for <Pierre.Weis@inria.fr>; Wed, 12 Apr 2000 20:06:06 +0200 (MET DST)
Received: (qmail 23641 invoked by uid 1403); 12 Apr 2000 18:06:04 -0000
Date: Wed, 12 Apr 2000 11:06:04 -0700
From: David Brown <caml-list@davidb.org>
To: "Dennis \(Gang\) Chen" <Dennis.G.Chen@motorola.com>
Cc: Pierre Weis <Pierre.Weis@inria.fr>, caml-list@inria.fr
Subject: Re: When functional languages can be accepted by industry?
Message-ID: <20000412110604.A23481@davidb.org>
References: <38E7F364.5D24BB7C@motorola.com> <14572.49274.910966.673172@cylinder.csl.sri.com> <38ED71B6.30118608@motorola.com> <14574.1721.508470.790475@cylinder.csl.sri.com> <38F270CF.221F5BD0@motorola.com> <20000411195808.62154@pauillac.inria.fr> <38F3D520.9CD19485@motorola.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.1.5i
In-Reply-To: <38F3D520.9CD19485@motorola.com>; from Dennis.G.Chen@motorola.com on Wed, Apr 12, 2000 at 11:15:04AM +0930
Resent-From: weis@pauillac.inria.fr
Resent-Date: Thu, 13 Apr 2000 10:14:08 +0200
Resent-To: caml-redistribution@pauillac.inria.fr

On Wed, Apr 12, 2000 at 11:15:04AM +0930, Dennis (Gang) Chen wrote:
> > Don't forget that there is (almost) no restriction on side-effects in
> > Caml: if this is crucial for your program, you can implement lists as
> > an imperative data type of your own, and then use destructive update
> > to perform the deletion operation in the required complexity. Just be
> > aware that list sharing will be difficult as for any other imperative
> > implementation of lists.
> 
> This is true. But such an approach does not make ocaml
> more attractive than C++. In ocaml, there are arrays, structures
> and objects etc, but no such things like pointers in C.

I'm not sure I understand what features of pointers in C you want.  Yes,
arbitrary pointer arithmetic is not available.  But, when you work with
mutable data structures in ocaml, the things you assign behave a lot like
pointers in C or C++.

Dave Brown