From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: weis
Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id TAA21424 for caml-redist; Tue, 25 Apr 2000 19:01:49 +0200 (MET DST)
Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id WAA30302 for <caml-list@pauillac.inria.fr>; Fri, 21 Apr 2000 22:44:41 +0200 (MET DST)
Received: from csc-sun.math.utah.edu (csc-sun.math.utah.edu [128.110.198.2])
	by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id WAA16030
	for <caml-list@inria.fr>; Fri, 21 Apr 2000 22:44:27 +0200 (MET DST)
Received: from sunblock.math.utah.edu (sunblock.math.utah.edu [155.99.144.57])
	by csc-sun.math.utah.edu (8.9.3/8.9.3) with ESMTP id OAA26618
	for <caml-list@inria.fr>; Fri, 21 Apr 2000 14:44:15 -0600 (MDT)
Received: (from hohn@localhost)
	by sunblock.math.utah.edu (8.9.3/8.9.3) id OAA24797;
	Fri, 21 Apr 2000 14:44:15 -0600 (MDT)
Date: Fri, 21 Apr 2000 14:44:15 -0600 (MDT)
Message-Id: <200004212044.OAA24797@sunblock.math.utah.edu>
X-Authentication-Warning: sunblock.math.utah.edu: hohn set sender to hohn@math.utah.edu using -f
From: Michael Hohn <hohn@math.utah.edu>
To: caml-list@inria.fr
In-reply-to: <200004201852.UAA20082@miss.wu-wien.ac.at> (message from Markus
	Mottl on Thu, 20 Apr 2000 20:52:34 +0200 (MET DST))
Subject: Re: When functional languages can be accepted by industry?
References:  <200004201852.UAA20082@miss.wu-wien.ac.at>
Sender: weis


>> ...
>>    From: Markus Mottl <mottl@miss.wu-wien.ac.at>
>>    Date: Thu, 20 Apr 2000 20:52:34 +0200 (MET DST)
>>    Cc: caml-list@inria.fr (OCAML)
>>    Content-Type: text/plain; charset=us-ascii
>>    Sender: Pierre.Weis@inria.fr
>> 
>>    > In another life I wrote lots of numerical linear algebra programs, and I 
>>    > find that a little overloading would make the code a lot nicer.
>> 
>>    I admit: I don't write this much numerical code so I don't have many
>>    opportunities to complain about missing operator overloading there...
>> ...

Overloading is not needed in caml:  remember that you can define your
own infix operators.  I have done this for a minimalistic complex
number type, using +: -: /: and *:  Since the first (or first 2)
characters determine both precedence and associativity, this works
well. 
This also avoids the mixed-arithmetic errors, such as 
     x = 1/2 * y
which in e.g. Python will always return 0, but give type errors in
caml (when x and y are not integers)

Cheers,
Michael