Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Jon Harrop <jon@ffconsultancy.com>
To: Brian Hurt <bhurt@janestcapital.com>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] [OSR] OCaml Standard Recommandation Process
Date: Mon, 28 Jan 2008 15:25:12 +0000	[thread overview]
Message-ID: <200801281525.12651.jon@ffconsultancy.com> (raw)
In-Reply-To: <479DE545.9050306@janestcapital.com>

On Monday 28 January 2008 14:23:01 you wrote:
> Jon Harrop wrote:
> >There are also many features that I would like to steal from other
> > languages:
> >
> >. The IDisposable interface from .NET and F#'s "use" bindings.
>
> Is there a reason that Gc.finalise doesn't work?

Absolutely: Gc.finalise is only probabilistic whereas IDisposable is 
deterministic. IDisposable guarantees deallocation of resources by a certain 
point. (This is why you should never use Gc.finalise alone to manage the 
collection of external resources!)

So you write a "use" binding:

  let read_first_line file =
    use ch = open_in file in
    input_line ch

and it gets translated into:

  let read_first_line file =
    let ch = open_in file in
    try input_line ch finally
    ch#dispose

where the "dispose" method that was automatically inserted at the end of the 
scope of the "use" binding calls "close_in" in this case to deallocate the 
external resource (a file handle in this case but it could be anything with a 
dispose method).

This is easy to implement and will remove a world of pain when doing IO in 
OCaml.

> >and some more involved ones like operator overloading.
>
> I *hate* operator overloading.  My experience in C++ is for every time
> this feature is used legitimately (i.e. to implement complex numbers or
> whatever), it's abused 10 times- and that's ignoring C++'s use of the
> bit shift operators << and >> for I/O, and the use of + for string
> concatentation, both of which I'd argue really should be considered
> abuses, as far as I'm concerned. And this is ignoring the difficulty of type
> inference in the presence of overloaded operators.

You're looking in the wrong direction.

Look at F# to see how OCaml + overloading done right can be hugely beneficial. 
OCaml has fallen far too far behind to catch up completely but we could take 
some baby steps in this direction, just like SML's ad-hoc polymorphic 
approach but with a wider range of types (complexes, vectors, matrices).

This is fairly easy to implement and, again, will remove a world of pain when 
doing arithmetic in OCaml.

> The best way to handle this IMHO is Haskell-style type classes.  Which
> solves the whole type inference problem, and rules most of what I
> consider abuses of operator overloading (for example, if you have a '+'
> operator, you also have to have a '*' operator- and what is "foo" *
> "bar"?).  But this is a very non-trivial change to the language.

Type classes are more powerful but they also make performance less predictable 
(the dictionary may or may not be optimized away). They are also 
unachievable, as you say.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e


  parent reply	other threads:[~2008-01-28 15:30 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-27 13:23 David Teller
2008-01-27 13:52 ` [Caml-list] " Paolo Donadeo
2008-01-27 14:24 ` Yaron Minsky
2008-01-27 19:07   ` David Teller
2008-01-27 21:07     ` Jon Harrop
2008-01-27 21:47       ` Yaron Minsky
2008-01-28 11:06         ` David Teller
2008-01-28 12:04         ` Jon Harrop
2008-01-28 12:31           ` David Teller
2008-01-28 14:23           ` Brian Hurt
2008-01-28 15:15             ` Loup Vaillant
2008-01-28 15:40               ` Brian Hurt
2008-01-28 19:46                 ` Jon Harrop
2008-01-28 15:25             ` Jon Harrop [this message]
2008-01-28 16:06               ` Christophe TROESTLER
2008-01-28 16:20                 ` Nicolas Pouillard
2008-01-28 16:45                   ` Christophe TROESTLER
2008-01-28 16:51                     ` Olivier Andrieu
2008-01-28 19:58                       ` Jon Harrop
2008-01-29  7:51                   ` Gordon Henriksen
2008-01-28 20:49                 ` Jon Harrop
2008-01-28 22:05                   ` Till Varoquaux
2008-01-28 23:10                     ` Jon Harrop
2008-01-28 16:37               ` Brian Hurt
2008-01-28 17:30                 ` David Teller
2008-01-28 20:43                   ` Jon Harrop
2008-01-28 21:12                   ` Gerd Stolpmann
2008-01-28 21:39                     ` Jon Harrop
2008-01-29 16:49                       ` Edgar Friendly
2008-01-30  8:52                         ` Sylvain Le Gall
2008-01-30 10:02                           ` [Caml-list] " Jon Harrop
2008-01-30 12:12                           ` Vincent Hanquez
2008-01-28 21:43                     ` [Caml-list] " Dario Teixeira
2008-01-29  7:59                       ` Francois Pottier
2008-01-28 22:07                 ` Arnaud Spiwack
2008-01-27 14:36 ` Michaël Grünewald
2008-01-27 15:10 ` Dario Teixeira
2008-01-28 13:38   ` Sylvain Le Gall
2008-01-28 13:52     ` [Caml-list] " David Teller
2008-01-28  0:23 ` [Caml-list] " Oliver Bandel
2008-01-30  9:43 ` Sylvain Le Gall
2008-01-30 20:25   ` [Caml-list] " blue storm
2008-01-30 20:49     ` Sylvain Le Gall
2008-01-30 20:54       ` [Caml-list] " Eric Cooper

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=200801281525.12651.jon@ffconsultancy.com \
    --to=jon@ffconsultancy.com \
    --cc=bhurt@janestcapital.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