New Year's resolution suggestions...

New Year's resolution suggestions...

[Charles Martin]

... for the OCaml implementors :)

(1) overloading, or something with equivalent functionality

(2) explicit declarations for operator associativity and precedence

Happy New Year!

Re: New Year's resolution suggestions...

[Pierre Weis]

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

> Happy New Year!

Thanks a lot.

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis/

Re: New Year's resolution suggestions...

[Charles Martin]

>You mean that the actual implicit way of specifying associativity and
>precedence of users's defined operators is not powerful enough for your
>programs ?

It is probably powerful enough as it stands.  But it restricts me to the 
naming scheme that has been chosen for me, which I don't like.  What if 
some kind of Hungarian notation for alphanumeric identifiers was enforced 
by the compiler?  That would be awful.  This feels kind of the same.

This is not nearly as big a wish as for some kind of overloading! :)

Charles

Re: New Year's resolution suggestions...

[Brian Rogoff]

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

Re: New Year's resolution suggestions...

[Marcin 'Qrczak' Kowalczyk]

Wed, 3 Jan 2001 08:27:02 -0800 (PST), Brian Rogoff <bpr@best.com> pisze:

> 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 don't use custom infix operators much in Haskell. Parsing combinators
seem to be their most important use.

More common is forming of infix operators from identifiers, e.g.
    uri `relativeTo` baseUri
    attr0 `setBold` True `setReverse` True
    text1 `isPrefixOf` text2
    ptr `indexPtr` 1
    x `elem` list
which are also used for what OCaml uses alphanumeric operators:
    `div`, `mod`, `shift`

Their precedence can be changed too, but often it is left as default:
between function application and operator application, left associative.

-- 
 __("<  Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZASTĘPCZA
QRCZAK

RE: New Year's resolution suggestions...

[Dave Berry]

>From experience with SML, I believe that any benefit from explicit
precedence definitions is far outweighed by the cost.  It complicates the
implementation (e.g. requiring more information to be shared across
compilation boundaries), it complicates the syntax (requiring new
declaration formats), and IMO it can actually make programs harder to read
(because you can't mentally parse infix expressions without checking the
precedence declarations).

Dave.


-----Original Message-----
From: Charles Martin [mailto:martin@chasm.org]
Sent: Wednesday, January 03, 2001 15:38
To: caml-list@inria.fr
Subject: Re: New Year's resolution suggestions...



>You mean that the actual implicit way of specifying associativity and
>precedence of users's defined operators is not powerful enough for your
>programs ?

It is probably powerful enough as it stands.  But it restricts me to the 
naming scheme that has been chosen for me, which I don't like.  What if 
some kind of Hungarian notation for alphanumeric identifiers was enforced 
by the compiler?  That would be awful.  This feels kind of the same.

This is not nearly as big a wish as for some kind of overloading! :)

Charles