caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Brian Rogoff <bpr@best.com>
To: Miles Egan <miles@caddr.com>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] a reckless proposal
Date: Wed, 25 Jul 2001 08:15:49 -0700 (PDT)	[thread overview]
Message-ID: <Pine.BSF.4.21.0107250726080.27705-100000@shell5.ba.best.com> (raw)
In-Reply-To: <20010724140210.B38516@caddr.com>

On Tue, 24 Jul 2001, Miles Egan wrote:
> On Tue, Jul 24, 2001 at 12:44:52PM -0700, Brian Rogoff wrote:
> > I understand this desire to unify features and remove non-orthogonalities, 
> > but I don't like this proposal. I think it would be more interesting to
> > have a language with more polymorphism in records, as well as some more 
> > flexibility in modules. By enhancing those aspects of the language the 
> > advantages of classes would be reduced. 
> 
> Overall I agree.  I wonder if the inria folks are interested in making changes
> in this area or if they're focusing on other things at the moment?  I'll take a
> look at the SML# stuff.

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!

> > Of course, if you're really into confusing, errr, unifying concepts, I
> > suppose we could unify modules and records too? No joke, I think a few 
> > language designs do this.
> 
> As much as unifying concepts, I'm interested in identifying the "false friends"
> new programmers encounter in Ocaml.  Records are such "false friends" I believe.
> They resemble, even in syntax, C structs and are used in some fairly similar
> ways, but functionally  they are quite different.  I think this fact would be
> more obvious and less confusing if they weren't so enticingly but superficially
> familiar.  Object syntax and behavior, on the other hand, is very similar to
> that found in more mainstream languages and causes less confusion, I think.

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 don't think records are really such a false friend, it's just that if
you want type inference the whole issue of what the type of a record field 
access is is a bit more complex. 

> Modules are another of these "false friends", I think.  In most commonly-used
> languages, a module is rougly equivalent to a compilation unit and corresponds
> to a source file. 

I spent a fair bit of time learning and using Ada 95 before I hit OCaml,
since at the time C++ was achieving popularity I was doing numerics and I 
wanted templates (which were very poorly supported in the early to mid
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). 

If you are only used to C/C++/Java and Perl/Tcl then OCaml is very different. 

> In these languages, a module is essentially a collection of
> related types and functions. 

In OCaml, a structure is essentially a collection of definitions (of
types, functions, classes, modules..). So it's not too different. 

-- Brian


-------------------
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


  reply	other threads:[~2001-07-25 15:15 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-24 18:08 Miles Egan
2001-07-24 19:44 ` Brian Rogoff
2001-07-24 21:02   ` Miles Egan
2001-07-25 15:15     ` Brian Rogoff [this message]
2001-07-26 15:27       ` Miles Egan
2001-07-26 15:47         ` Brian Rogoff
2001-07-26 16:01           ` Miles Egan
2001-07-26 21:19   ` John Max Skaller
2001-07-24 20:26 ` Sven
2001-07-24 20:51   ` Miles Egan
2001-07-25  8:30 ` FabienFleutot
2001-07-25  9:30 Dave Berry
2001-07-26 15:35 ` Miles Egan
2001-07-30 12:21   ` Bruce Hoult

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.BSF.4.21.0107250726080.27705-100000@shell5.ba.best.com \
    --to=bpr@best.com \
    --cc=caml-list@inria.fr \
    --cc=miles@caddr.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).