From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id RAA26610; Thu, 26 Jul 2001 17:27:43 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id RAA26606 for ; Thu, 26 Jul 2001 17:27:42 +0200 (MET DST) Received: from www.invert.com (invert.com [209.164.21.15]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f6QFRev28432 for ; Thu, 26 Jul 2001 17:27:41 +0200 (MET DST) Received: (from miles@localhost) by www.invert.com (8.10.1/8.10.1AA) id f6QFRZS65674; Thu, 26 Jul 2001 08:27:35 -0700 (PDT) (envelope-from miles) Date: Thu, 26 Jul 2001 08:27:35 -0700 From: Miles Egan To: Brian Rogoff Cc: caml-list@inria.fr Subject: Re: [Caml-list] a reckless proposal Message-ID: <20010726082735.A65526@caddr.com> References: <20010724140210.B38516@caddr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from bpr@best.com on Wed, Jul 25, 2001 at 08:15:49AM -0700 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Wed, Jul 25, 2001 at 08:15:49AM -0700, Brian Rogoff wrote: > I don't know about records, but it appears that there is work on mixin > modules. While I agree that the record field problem is annoying, and > definitely not a feature, it's not on my top 3 list of fixes or new > features desired. Probably somewhere between a petty complaint and a > nuisance. I do work with programmers who hate Caml for this very reason > though! Rejecting ocaml over this is a tragic mistake! :) It can be very jarring to people with the wrong expectations, as you've seen. The two situations in which I find it most jarring: 1. The work-around usually suggested, to wrap the record definitions in local module definitions, is actually worse. It results in code that looks like var.Type.field, rather than Type.var.field. This gives C++/Java programmers fits. The more cumbersome, but familiar method of prefixing field names with the record type, a la var.type_field, is even preferrable. This syntax appears even in common uses of the standard library. For example, if I use the Unix stat functions, I have to access the fields of the returned record as res.Unix.st_perm, not just res.st_perm or even Unix.res.st_perm. Once the difference is clear, this isn't too annoying, but it's a big speedbump for newbies. > It also seems that you'd like to eliminate these false friends (good phrase, > especially for a bilingual French-English mailing list!) by subsuming them > into features that mainstream programmers know well. That would be a > mistake, since you'd end up with a mainstream language. I certainly wouldn't generally characterize my intentions that way. I'm more interested in re-evaluating gratuitous differences. At any rate, I agree that the loss of pattern-matching more than outweighs the benefits in this case. Ocaml is stylistically quite comfortably out of the mainstream in many ways and I'm sure it will remain so. > 90s). Ada packages correspond very closely to ML modules, and there are > even crude approximations to functors and signatures in Ada 95 (generic > formal package parameters in Ada parlance). It's not the combination of packaging and polymorphism in Ocaml that I think is confusing. In fact, I think it's one of it's most compelling features. It's the fact that compilation units are implicit top-level modules with special properties. A few paragraphs in the documentation explaining top-level modules and the relationship between source files and implicit top-level modules might clarify this a bit better for new users. Perhaps some kind of "Ocaml for Java Programmers" FAQ might be useful? -- miles "We in the past evade X, where X is something which we believe to be a lion, through the act of running." - swiftrain@geocities.com ------------------- Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr