caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Brian Rogoff <bpr@best.com>
To: Mattias Waldau <mattias.waldau@tacton.se>
Cc: caml-list@inria.fr
Subject: RE: Functions must be explicitly typed, (was Same label in different types, how do people solve this?)
Date: Fri, 15 Dec 2000 15:37:43 -0800 (PST)	[thread overview]
Message-ID: <Pine.BSF.4.21.0012151005560.6804-100000@shell5.ba.best.com> (raw)
In-Reply-To: <HDEEKOMJILGEIHIMAPCDCEBJDMAA.mattias.waldau@tacton.se>

On Fri, 15 Dec 2000, Mattias Waldau wrote:
> >> Pierre Weis wrote
> >> I would like to note that type inference (i.e. code without
> >> annotations) helps a lot when developing programs: the annotation free
> >> code is not only easier to write but also easier to maintain since it
> >> is kind of ``auto-adaptative'' and resistant to reorganisations and
> >> names modifications.
> 
> If this were important, we shouldn't have different operators for * and *.

I agree. It's the same problem as with functions like print_int, output_int, 
etc., where the lack of overloading forces a type name to get attached to
a function to disambiguate. I don't like this either, and I eagerly await
a solution. Be patient, people are still working on a fix; it has come up
a few times already that the Caml developers are not happy with the status
quo but are working on something which will do quite a bit more than just 
enable you to overload a few arithmetic operators. 

> I had to change a program from integers to float recently, and it isn't fun
> at all.

Yes, I used to wonder if type classes would have been a good idea since
they do make a few of these simpler issues easier to handle. Pierre Weis 
gave some examples of what he'd like to be able to do: for instance, to
overload the .() or .[] so array and string access would be the same, and
even extend it to hash table lookup. If it takes a little while to get
these features in a type-safe way I'm willing to wait. If it turns out to
be too difficult then I suppose we can agitate for type-classes ;-). I
guess the positive side of all of this for the Caml developers is that
they'll always have lots of interesting things to work on. 

In the meantime, there are workarounds which can help you out. You may use 
the module system to bind the names of functions (like "*.") to the
name you want and localize the changes that you'll need to make when you
change representations (i.e., you'll only need to change them where you've
done the rebinding). Admittedly this is a workaround, same as the record
label fixes, but it may lessen your difficulties. 

-- Brian





  reply	other threads:[~2000-12-18 14:47 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-12-06 21:22 Same label in different types, how do people solve this? Mattias Waldau
2000-12-07 16:49 ` John Max Skaller
2000-12-07 18:34 ` Maxence Guesdon
2000-12-07 23:02 ` Gerd Stolpmann
2000-12-08  1:22 ` Jacques Garrigue
2000-12-08  9:31   ` Sven LUTHER
2000-12-08  9:36     ` Pierre Weis
2000-12-08  9:48       ` Sven LUTHER
2000-12-08 18:41       ` John Max Skaller
2000-12-08  9:40     ` Nicolas barnier
2000-12-08 16:36 ` Brian Rogoff
2000-12-11 17:19   ` Pierre Weis
2000-12-10 12:49 ` Mattias Waldau
2000-12-11 18:23   ` Chris Hecker
2000-12-11 19:17     ` Pierre Weis
2000-12-12 10:02       ` Sven LUTHER
2000-12-12  3:25     ` Chet Murthy
2000-12-12 17:43       ` John Max Skaller
2000-12-12 19:24         ` Functions must be explicitly typed, (was Same label in different types, how do people solve this?) Mattias Waldau
2000-12-13  0:51           ` John Max Skaller
2000-12-15 10:13             ` Andreas Rossberg
2000-12-15 12:50             ` Frank Atanassow
2000-12-14 18:42           ` Stefan Monnier
2000-12-15 12:47             ` Pierre Weis
2000-12-15 13:39               ` Mattias Waldau
2000-12-15 23:37                 ` Brian Rogoff [this message]
2000-12-16 14:10                 ` ROverloading John Max Skaller
2000-12-15 21:51         ` Same label in different types, how do people solve this? Bruce Hoult
2000-12-12 17:19   ` John Max Skaller

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.0012151005560.6804-100000@shell5.ba.best.com \
    --to=bpr@best.com \
    --cc=caml-list@inria.fr \
    --cc=mattias.waldau@tacton.se \
    /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).