From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 7E228BC84 for ; Wed, 30 Mar 2005 20:21:48 +0200 (CEST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j2UILlRY032622 for ; Wed, 30 Mar 2005 20:21:48 +0200 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 UAA07189 for ; Wed, 30 Mar 2005 20:21:47 +0200 (MET DST) Received: from cgpsrv2.cis.mcmaster.ca (cgpsrv2.CIS.McMaster.CA [130.113.64.62]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j2UILkBv032619 for ; Wed, 30 Mar 2005 20:21:47 +0200 Received: from [24.43.193.126] (account carette@univmail.cis.mcmaster.ca) by cgpsrv2.cis.mcmaster.ca (CommuniGate Pro WebUser 4.1.8) with HTTP id 87495698; Wed, 30 Mar 2005 13:21:45 -0500 From: "Jacques Carette" Subject: Re: [Caml-list] Pervasives.compare output type To: brogoff Cc: Ocaml X-Mailer: CommuniGate Pro WebUser Interface v.4.1.8 Date: Wed, 30 Mar 2005 13:21:45 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format="flowed" Content-Transfer-Encoding: 8bit X-Miltered: at nez-perce with ID 424AEE3B.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 424AEE3A.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 pervasives:01 bug:01 rewriting:01 rewriting:01 ocaml:01 langauge:01 ocaml:01 haskell:01 polymorphism:01 metaocaml:01 advancing:98 ...:98 wrote:01 precedence:01 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.2 X-Spam-Level: brogoff wrote: > Speaking as an industrial user, I don't see it as such an either/or. I'd > prefer that enhancements (thisisn't a bug) which require rewriting code > be done as few times as possible, so that each release doesn't require > rewriting code. So, let's say for example that the implementors decide to > change this, and to fix evaluation order to be left to right, I'd prefer > that it were done in one release, rather than two separate ones. If I were still in a position to decide such things, that is indeed what I would do: assuming yearly releases, then every third release would be a 'big' one where large changes would be introduced together, and with a couple of releases in between that were as backwards compatible as possible. > I think even industrial users should realize that OCaml is a research langauge, > and while we're grateful that it is generally quite stable from relase to > release, that research goals take some precedence. Maybe one day the > implementors will decide to "radically" change things, as in the move from > Caml Light to Caml Special Light/OCaml. My experience (~15 years with the one piece of software, with access to its full history) with software that is now 25 years old is that 'major' changes should be planned every 3 years, and 'radical' changes every 6-7 years. That should be sufficient to keep the softare healthy and progressing. I have seen the effect of periods of 6-9 years of relative sclerosis (ie basically only new features), and the result was a lot of bloat with questionable new features and much less progress on the 'core'. Of course, the core of OCaml is much more solid than what I was working on. It is based on very solid theory, which also helps a lot. But theory is also advancing rapidly. Haskell 6.4's inclusion of GADTs in the core language is exerting a powerful pull on me. On another front, System E looks like a promising 'replacement' for System F based polymorphism - that might be a 'radical' change ;-). But right now metaocaml is keeping me programming in ocaml... Jacques