caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Miles Egan <miles@caddr.com>
To: Brian Rogoff <bpr@best.com>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] a reckless proposal
Date: Tue, 24 Jul 2001 14:02:10 -0700	[thread overview]
Message-ID: <20010724140210.B38516@caddr.com> (raw)
In-Reply-To: <Pine.BSF.4.21.0107241211330.14503-100000@shell5.ba.best.com>; from bpr@best.com on Tue, Jul 24, 2001 at 12:44:52PM -0700

On Tue, Jul 24, 2001 at 12:44:52PM -0700, Brian Rogoff wrote:
> >  Objects seem to provide more struct-like
> > semantics, i.e. field names need only be unique within their class definition.
> > Using objects in place of records is a bit clumsy, however, because object
> > fields require accessors.  If the rules for object field access were changed,
> > however, objects would be just as convenient as records and less
> 
> No, they'd still be *much* less convenient than records, since you can't
> pattern match on objects. 

That's a big disadvantage, I agree.
 
> > This approach has, in my mind, two advantages:
> > 1. The object system becomes more generally useful.
> > 2. A confusing and non-orthogonal feature of ocaml is subsumed into
> >    another, more generally useful and flexible feature.
> 
> 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.
 
> 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.

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.  In these languages, a module is essentially a collection of
related types and functions.  Ocaml top-level modules are very analagous, but
"modules" in ML are actually a very different beast with as much in common with
C++ templates as java packages.  This convolution of function wasn't clear to me
until I'd been programming in Ocaml for a while and I still find it fairly
dissonant psychologically.  In this case, I might even advocate ADDING new
terminology to Ocaml and explicitly distinguishing compilation units from
parametric polymorphs.

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


  reply	other threads:[~2001-07-24 21:02 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 [this message]
2001-07-25 15:15     ` Brian Rogoff
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=20010724140210.B38516@caddr.com \
    --to=miles@caddr.com \
    --cc=bpr@best.com \
    --cc=caml-list@inria.fr \
    /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).