From mboxrd@z Thu Jan  1 00:00:00 1970
Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id OAA04829 for caml-red; Thu, 4 Jan 2001 14:15:26 +0100 (MET)
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 RAA29556 for <weis@pauillac.inria.fr>; Wed, 3 Jan 2001 17:27:13 +0100 (MET)
Received: from shell5.ba.best.com (shell5.ba.best.com [206.184.139.136])
	by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id f03GRC127018;
	Wed, 3 Jan 2001 17:27:12 +0100 (MET)
Received: from localhost (bpr@localhost)
	by shell5.ba.best.com (8.9.3/8.9.2/best.sh) with ESMTP id IAA26940;
	Wed, 3 Jan 2001 08:27:03 -0800 (PST)
Date: Wed, 3 Jan 2001 08:27:02 -0800 (PST)
From: Brian Rogoff <bpr@best.com>
To: Pierre Weis <Pierre.Weis@inria.fr>
cc: Charles Martin <martin@chasm.org>, caml-list@inria.fr
Subject: Re: New Year's resolution suggestions...
In-Reply-To: <200101031314.OAA32001@pauillac.inria.fr>
Message-ID: <Pine.BSF.4.21.0101030748590.12612-100000@shell5.ba.best.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: weis@pauillac.inria.fr

On Wed, 3 Jan 2001, Pierre Weis wrote:
> > (2) explicit declarations for operator associativity and precedence
> 
> You mean that the actual implicit way of specifying associativity and
> precedence of users's defined operators is not powerful enough for your
> programs ?

I'm of the opinion that the Ocaml solution is a very good compromise
between a fixed set of reusable (pre|in)fix operators (C++, Ada) and the
more powerful Haskell/Clean/SML/Caml approach which allows arbitrary 
specification. It is certainly true that in the Haskell and Clean papers 
on parser combinators that I've read, the authors use good taste in 
choosing operators, and since the papers are of an expository nature the 
symbols are well explained. I wonder if the same holds for the average 
working Haskell or Clean program which makes heavy use of infixes. What do 
the Haskell programmers on the list think? Does the Haskell approach buy 
much more in practice? 

I think that suggestion (1) for overloading is significantly more important, 
and helps quite a bit with (2), since it reduces the need for additional 
operators. That and the mixin modules (or some other approach for recursive 
modules) are on top of my language feature wish-list. I won't hold my
breath though...

> > Happy New Year!

If you read the ML-2000 paper, you'll see that neither user defined infixes 
nor overloading were to be in ML2K. Good riddance to 2000 I say! The future 
of ML is here now.

-- Brian