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 WAA17573 for caml-red; Tue, 8 Aug 2000 22:42:15 +0200 (MET DST) 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 UAA16455 for ; Tue, 8 Aug 2000 20:23:59 +0200 (MET DST) Received: from isil.localdomain ([64.64.1.131]) by nez-perce.inria.fr (8.10.0/8.10.0) with ESMTP id e78INwX22830 for ; Tue, 8 Aug 2000 20:23:59 +0200 (MET DST) Received: by isil.localdomain (Postfix, from userid 1000) id CDE6036C17; Tue, 8 Aug 2000 14:23:43 -0400 (EDT) To: Walid Taha Cc: John Prevost , Markus Mottl , caml-list@inria.fr Subject: Re: Imperative programming in Caml References: From: John Prevost Date: 08 Aug 2000 14:23:39 -0400 In-Reply-To: Walid Taha's message of "Tue, 8 Aug 2000 20:01:53 +0200 (MET DST)" Message-ID: <87ya27vcgk.fsf@localhost.localdomain.> User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: weis@pauillac.inria.fr >>>>> "wt" == Walid Taha writes: wt> This is a great revision, and I particularly like the way that wt> you broke the task into smaller pieces. The code is certainly wt> more structured. However, you get the biggest payoff in your wt> rewrite from using the "option" type, and that is something wt> that I was trying to avoid (see "option types" below). {...} >> imperative call; >> let x = blah in >> imperative call >> >> is much less disconcerting. wt> Not quite sure what you mean here. If you write: imperative call; let x = blah in imperative call then you get a little distracted by the indentation. It's true that the expression after a let ... in is part of that let, but since let contains a single expression, keeping everything at the same indentation level makes things a little more clear. (That is, makes it clear that you're doing one thing after another, whether it's the imperative call or the binding call.) wt> Some of the choice was intentional. In particular, "option" wt> types are very appropriate here, and were the first thing that wt> came to my mind when I was thinking about writing these little wt> examples. But "option" types do, however, require introducing wt> the concept of parameteric polymorphism. For my initial wt> postulate to be answer possitively, avoiding introducing wt> concepts from function programming would be necessary. >> The thing that distressed me most was trying to figure out what >> your ref ref was doing. I understand it now. wt> I found the need for ref ref that strange too, but as you see, wt> for that "naive" imperative style, it is necessary. Mmm. I don't think you're going to have much success at showing that O'Caml is a reasonable language without using at least some polymorphism. Perhaps this restatement of my previous code would help, though: type optional_int = | No_Int | Some_Int of int module MutableIntList = struct type mcons = { mutable fore : optional_mcons; mutable v : int; mutable back : optional_mcons } and optional_mcons = | No_Mcons | Some_MCons of mcons type mlist = { mutable head : optional_mcons; mutable tail : optional_mcons } ... end type optional_bool = | No_Bool | Some_Bool of bool type mutable_bool = { mutable v : bool } ... This does everything that the previous code did, but with no parametric polymorphism. If polymorphism is difficult to explain, you might show the example in this form, then point out how the same sort of datastructure is used over and over again with no change but a different name and different types inside. Then you could introduce option and ref types as a generalized solution. John.