Browse thread
[Caml-list] a reckless proposal
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Miles Egan <miles@c...> |
| Subject: | Re: [Caml-list] a reckless proposal |
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