Re: [Caml-list] duplicate record labels and modules

[briand@aracnet.com]

>>>>> "brogoff" == brogoff  <brogoff@speakeasy.net> writes:

  brogoff> On Tue, 11 May 2004 briand@aracnet.com wrote:
  >> That's useful.  I need to read the chapter on language extensions
  >> more closely.

  brogoff> Also, here's the requisite RTFM (I mean that F in the
  brogoff> nicest possible way ;)

  brogoff> 	http://caml.inria.fr/FAQ/FAQ_EXPERT-eng.html#labels_surcharge

I Just found it.
It should have occurred to me that this subject would be an FAQ.

However, my original question was more about the syntax of making
using modules to separate the field name less typing-ful :-)

  Ville-Pertti> Alternately, assuming the modules are your own, you
  Ville-Pertti> can name your record fields so that opening both
  Ville-Pertti> modules doesn't cause conflicts (e.g. using a short
  Ville-Pertti> prefix).
  >>  That's very kludgy, isn't it ?

  brogoff> IMO, it's inconvenient, and a drawback to the language, but
  brogoff> not a kludge, or even a mistake. I reserve that for the
  brogoff> undefined order of evaluation :-).  Oh well, you didn't
  brogoff> expect paradise, did you?

  >> I'm assuming the right way is to use modules, which is what
  >> started this whole exercise for me.

  brogoff> If you must share field names in the same module, your only
  brogoff> alternative is to use the OO part of Ocaml. That's
  brogoff> unfortunate, because I think objects are a bit heavyweight
  brogoff> for things like points and segments in a computational
  brogoff> geometry program. OTOH, Ocaml's object system is quite
  brogoff> powerful and principled (and sometimes complex and
  brogoff> unintuitive!) compared to lesser languages like C++ and
  brogoff> Java. I often think a class system like CLOS or Dylan's
  brogoff> would be more to my liking, but hard to reconcile with
  brogoff> ststic typing and modules.

I do _not_ need to use the same field name in the same module.
So using modules is the right way and what I will do.  

For my current application objects are, as you say, too heavyweight.

Brian

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners