RE: [Caml-list] operator overloading

RE: [Caml-list] operator overloading

[Issac Trotts]

Thanks, I looked into it.  It looks powerful, yet risky
(being in "its infancy") and intimidating compared to
the simple mechanism for overloading operators in C++.
It would be nice to see something more straightforward.

Issac


> -----Original Message-----
> From: Gurr, David (MED, self) [mailto:David.Gurr@med.ge.com]
> Sent: Friday, April 12, 2002 7:33 PM
> To: Issac Trotts; caml-list@inria.fr
> Subject: RE: [Caml-list] operator overloading
>
>
>
> Try a google search for FOC and ocaml and see if that is not
> a better solution to matrices, etc than overloading. -D
>
> > -----Original Message-----
> > From: Issac Trotts [mailto:ITrotts@IdolMinds.com]
> > Sent: Friday, April 12, 2002 12:08 PM
> > To: caml-list@inria.fr
> > Subject: [Caml-list] operator overloading
> >
> >
> > Looking at the Google results, operator overloading has come up
> > as a frequently discuseed topic.  Still I didn't find anything
> > very useful in the posts that Google brought up.  Can anyone
> > recommend a way to work around OCaml's lack of operator overloading
> > when dealing with matrices, vectors, and spinors?  Is there a
> > way to implement this with ocamlp4?
> >
> > Issac Trotts
> > Programmer
> > Idol Minds
> >
> >
> >
> >
> > -------------------
> > To unsubscribe, mail caml-list-request@inria.fr Archives:
> http://caml.inria.fr
> Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ:
> http://caml.inria.fr/FAQ/
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> -------------------
> To unsubscribe, mail caml-list-request@inria.fr Archives:
http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ:
http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] Operator overloading

[Robert Fischer]

Exactly.  If I was just going for inference and brevity, I'd still be coding in Perl.

~~ Robert.

-----Original Message-----
From: caml-list-bounces@yquem.inria.fr
[mailto:caml-list-bounces@yquem.inria.fr]On Behalf Of Ian Zimmerman
Sent: Friday, March 09, 2007 10:28 AM
To: Jon Harrop
Cc: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Operator overloading


> But aren't we all here because we like inference and brevity?

Inference: On condition it is _controlled_.  I.e. seeing operator
<foo> used on a complex type, I need to know I have seen its
definition and satisfied myself that it has the expected semantic
properties.  That's just what functors formalize.

Brevity: There's the pesky tradeoff with some type annotations being
required when you introduce overloading.

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] Operator overloading

[Jon Harrop]

On Friday 09 March 2007 16:40, Robert Fischer wrote:
> Exactly.  If I was just going for inference and brevity, I'd still be
> coding in Perl.

But this is about statically resolving overloads to get both performance and 
brevity. Perl doesn't have performance.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

Operator overloading

[oleg]

This message illustrates the translation of Haskell98 non-constructor
classes to OCaml, which gives us bounded polymorphism and a sort of
polymorphic recursion in OCaml.

It has to be remarked first that overloading is quite a complex issue:
please see `A Theory of Overloading' by Stuckey and Sulzmann (TOPLAS
2005) for many gory details.  The issue of the type of the plus
operation: 'a->'a->'a or 'a->'b->'c is not an abstract
subtlety. That's why functional dependencies where introduced in
Haskell (and quite often we need local functional dependencies to
resolve overloading). There are three main techniques of implementing
overloading: full inlining (aka C++), dictionary passing, and
the intensional type analysis. The latter is like `switch' and dictionary
passing is like a `vtable'. GHC and Hugs implement dictionary passing,
whereas JHC and Chameleon implement typeclasses via intensional type
analysis. I suspect F# might be doing something like that too, because
CLI might have run-time type tags. 

Non-constructor Haskell 98 classes (that is, overloading over parameter
of the kind *) can be implemented in OCaml in a straightforward way.

We start with a typical Haskell code

class Numb a where
    add :: a -> a -> a
    shw :: a -> String

instance Numb Int where
    add x y = x + y
    shw = show

instance Numb Float where
    add x y = x + y
    shw = show

instance Numb a => Numb [a] where
    add = zipWith add
    shw a = "[" ++ concatMap (\x -> (shw x) ++ " ") a ++ "]"

summ (h:t) = foldl add h t

test1 = shw (add [(1::Int),2,3] [4,5,6])
test2 = shw (summ (add [(1::Int),2,3] [4,5,6]))
test3 = shw (summ [(1.0::Float),2.0,3.0])
test4 = shw (summ [[(1.0::Float),2.0,3.0], [4,5,6], [7,8,9]])

We introduce a class Numb with two methods, for addition and for
showing. The latter is quite handy. The instances for Int and Float
are trivial. The instance of [a] says that if the type of list
elements is in class Numb, the list is in class Numb as well. Note the
definition for the "add" method in that case. It looks recursive: the
body of 'add' invokes 'add' itself, but on a different type.

We then define a function summ. Its inferred type is 
	summ :: (Numb a) => [a] -> a
The function is bounded polymorphic: it works on lists of any type
provided that type is in Numb. The tests test3 and test4 demonstrate
that summ can sum lists and lists of lists, etc.

Here's the OCaml translation:

(* class Numb a *)
type 'a numb = {add: 'a -> 'a -> 'a; shw: 'a -> string};;

(* instance Numb Int *)
let numb_i = {add = (+); shw = string_of_int};;
(* instance Numb Float *)
let numb_f = {add = (+.); shw = string_of_float};;

(* instance Numb a => Numb [a] *)
let numb_l numb_e = {add = List.map2 numb_e.add; 
		     shw = fun a -> 
		       "[" ^ List.fold_right 
			       (fun e z -> " " ^ numb_e.shw e ^ z) a "]"};;

(* we can define a bounded polymorphic function summ *)
let summ numb (h::t) = List.fold_left numb.add h t;;

let test1 = 
  let n = numb_l numb_i in
  n.shw (n.add [1;2;3] [4;5;6]);;

let test2 = 
  let n = numb_l numb_i in
  numb_i.shw (summ numb_i (n.add [1;2;3] [4;5;6]));;

let test3 = 
  numb_f.shw (summ numb_f [1.0;2.0;3.0]);;

let test4 = 
  let n = numb_l numb_f in
  n.shw (summ n [[1.0;2.0;3.0]; [4.0;5.0;6.0]; [7.0;8.0;9.0]]);;


The inferred type of summ in OCaml is
	val summ : 'a numb -> 'a list -> 'a = <fun>
It is instructive to compare it to the Haskell type. The only
difference is in the shape of the arrow: "Numb a =>" vs "'a numb ->".
Instead of the double arrow of Haskell we have the single arrow in
OCaml. The OCaml function summ is likewise bounded polymorphic: it
applies to arrays of any type provided that we have the _evidence_
(the dictionary) that the type is in the class numb. We must pass that
evidence as the first argument of summ. Granted, the burden of procuring
this evidence is on us; Haskell, in contrast, can, most of the time,
build that evidence by itself. As in Haskell, we can sum lists of
numbers and lists of lists of numbers, etc.


Haskell constructor classes (overloading over the parameters of 
higher kinds) do require OCaml functors. The example is a monad. With a
bit of syntactic sugar, the monadic notation and the corresponding
overloading are tolerable in OCaml.

Conversely, OCaml and SML modules (including sealing, generative and
applicative functors and recursive structures) can be emulated in
Haskell typeclasses. Chung-chieh Shan and I wrote a couple of messages
on that topic back in August and September 2004 on the Haskell mailing
list.


John Skaller wrote: ``(Haskell does this little cheat .. it makes
typeclasses very easy to explain to OO people).'' Are you sure about
that? There has been many long and recurring threads on Haskell-Cafe
about typeclasses and OO classes. I think the common advice is _not_
to think of Haskell typeclasses as of OO classes. Ralf Laemmel and I
once wanted to elaborate on the issue of OO in Haskell; we ended up
with a 79-page paper. I guess that shows that OO is never easy.

Re: [Caml-list] Operator overloading

[skaller]

On Thu, 2007-03-08 at 23:36 -0800, oleg@pobox.com wrote:

> John Skaller wrote: ``(Haskell does this little cheat .. it makes
> typeclasses very easy to explain to OO people).'' Are you sure about
> that? There has been many long and recurring threads on Haskell-Cafe
> about typeclasses and OO classes. I think the common advice is _not_
> to think of Haskell typeclasses as of OO classes. Ralf Laemmel and I
> once wanted to elaborate on the issue of OO in Haskell; we ended up
> with a 79-page paper. I guess that shows that OO is never easy.

Certainty requires at least a proof sketch, which I don't have.
However I do have a 'gut feeling' :)

It's hard to say, because in OO terms Haskell typeclasses
are so weak it's surprising they're any use at all.

If you consider your record implementation, observe
it is just a weak special case of a C++ class.
C++ classes can also provide state and inheritance.
The state looks vaguely like dependent typing to me .. :)

OK, so now we have a much more powerful model .. yet
it has known limitations, in particular the so-called
'covariance' problem prevents OO from modelling any
serious kind of system: for example a system
with binary operators doesn't admit an OO representation.

So all you need to do is elevate this model up one kinding
level to see typeclasses, even with the additional power
of 'everything C++ classes can do' are limited.

Of course it is argument by analogy and intuition, not
any kind of formal proof, that's for the experts :)

Felix currently has multi-parameter typeclasses which
use inlining because it's a whole program analyser,
so it can, however explicit objects would be required
either for separate compilation, or simply to experiment
with the 'extra power' of dynamic binding.

The 'obvious' implementation is of course a C++ class.

The difference to ordinary use is that the object doesn't
represent a type, but a typeclass, possibly with dependent
type parameters: eg a 'get' method for an array with
the length as a state variable.




-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] Operator overloading

[Andreas Rossberg]

skaller wrote:
> 
> It's hard to say, because in OO terms Haskell typeclasses
> are so weak it's surprising they're any use at all.

Not sure how you come to that conclusion. Both concepts are somewhat 
incomparable, but there are a number of axes along which type classes 
are much more expressive than OO classes.

Ignoring implementation inheritance, I claim that in combination with 
existential types, even relatively basic type classes are strictly more 
powerful than OO classes (modulo some lack of syntactic sugar).

Have a look at Oleg's paper.

> C++ classes can also provide state and inheritance.
> The state looks vaguely like dependent typing to me .. :)

I grant you (implementation) inheritance, but I don't understand the 
rest of your comment. State is orthogonal to classes. Surely you can 
define a type class that contains a, say, IORef (for per-class state). 
Likewise, you can instantiate type classes to stateful types (as the 
equivalent to per-object (mutable) state).

> OK, so now we have a much more powerful model ..

I don't think so.

> yet
> it has known limitations, in particular the so-called
> 'covariance' problem prevents OO from modelling any
> serious kind of system: for example a system
> with binary operators doesn't admit an OO representation.

Which is one of the problems type classes do not have, because qualified 
types *are* more expressive than subtyping in that respect.

AFAICS, the rest of your argument hence does not follow.

-- 
Andreas Rossberg, rossberg@ps.uni-sb.de

Re: [Caml-list] Operator overloading

[skaller]

On Fri, 2007-03-09 at 14:52 +0100, Andreas Rossberg wrote:
> skaller wrote:
> > 
> > It's hard to say, because in OO terms Haskell typeclasses
> > are so weak it's surprising they're any use at all.
> 
> Not sure how you come to that conclusion. Both concepts are somewhat 
> incomparable, but there are a number of axes along which type classes 
> are much more expressive than OO classes.

I'm sorry to write so poorly. This isn't the comparison I'm
drawing. 

Consider *implementing* typeclasses with records,
as in Oleg's Ocaml examples.

Ok, now replace the records with classes. Classes
are more powerful because they provide

(a) state
(b) inheritance etc

They also don't make the weak assumption of an 
abstraction (possibly with default methods as in Haskell)
and a single instantiation: in C++ at least you can
have sequence of more derived classes.

So the type model associated with this implementation
can do more than the one just using plain records:
records aren't typeclasses, so the class based implementation
can't be compared with them:

	records   		classes
	typeclasses		???????

Clearly ???? is more expressive than typeclasses, whatever it
is .. I am guessing the state of the classes provides dependent
typing but I don't really know.

Anyhow my ARGUMENT was actually that using classes
subsumes plain old records .. and classes are
limited by the covariance problem, so records
must be limited too.



-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] Operator overloading

[Andreas Rossberg]

skaller wrote:
> 
> I'm sorry to write so poorly. This isn't the comparison I'm
> drawing. 
> 
> Consider *implementing* typeclasses with records,
> as in Oleg's Ocaml examples.
> 
> Ok, now replace the records with classes. Classes
> are more powerful because they provide
> 
> (a) state
> (b) inheritance etc

Records and classes are not in the same category. Records and *objects* 
are. OTOH, objects *are* basically records, except that they usually 
come with more expressive typing, particularly allowing recursive types 
and subtyping. State is still orthogonal - records can have state, too.

Classes are a mechanism for *creating* objects (and in weaker languages 
than OCaml, for defining subtyping relations). Take away inheritance and 
you are basically left with fancy syntax for a function creating a 
record of mutually recursive closures over some local variables.

> They also don't make the weak assumption of an 
> abstraction (possibly with default methods as in Haskell)
> and a single instantiation: in C++ at least you can
> have sequence of more derived classes.

Please distinguish subtyping and inheritance. Type classes can express 
something akin to nominal interface subtyping, e.g.

   class C a        where m1 :: t1
   class C a => D a where m2 :: t2

But it's true that they do only provide a very weak form of inheritance 
(via default methods).

> So the type model associated with this implementation
> can do more than the one just using plain records:
> records aren't typeclasses, so the class based implementation
> can't be compared with them:
> 
> 	records   		classes
> 	typeclasses		???????

I cannot make much sense of this diagram, because of the category 
mismatch I mentioned above.

> Anyhow my ARGUMENT was actually that using classes
> subsumes plain old records .. and classes are
> limited by the covariance problem, so records
> must be limited too.

Something like the covariance problem does not occur with type classes 
(or modules, for that matter) because they decouple types from 
interfaces. A type class is merely an interface, witnessed by a record, 
the actual type is abstracted out. With OO, this is mingled together (an 
object type *is* its interface), which produces that nasty recursion 
where all the type problems originate.

So the difference is in the way these features factorise abstraction, 
rather than in the intrinsic expressiveness of the underlying 
primitives. Operationally, you can view dictionaries as detached 
"vtables". This detachment allows them to be used in more flexible ways, 
and avoid nuisances like the binary method issue.

Of course, it also makes inheritance a rather alien concept.

-- 
Andreas Rossberg, rossberg@ps.uni-sb.de

Re: [Caml-list] Operator overloading

[skaller]

On Fri, 2007-03-09 at 17:28 +0100, Andreas Rossberg wrote:
> skaller wrote:
> > 
> > I'm sorry to write so poorly. This isn't the comparison I'm
> > drawing. 
> > 
> > Consider *implementing* typeclasses with records,
> > as in Oleg's Ocaml examples.
> > 
> > Ok, now replace the records with classes. Classes
> > are more powerful because they provide
> > 
> > (a) state
> > (b) inheritance etc
> 
> Records and classes are not in the same category. Records and *objects* 
> are.

That depends on terminology. I was thinking in C++ terms:

	record = struct
	class = struct with methods

>  OTOH, objects *are* basically records, except that they usually 
> come with more expressive typing, particularly allowing recursive types 
> and subtyping. State is still orthogonal - records can have state, too.

Yes, records can have state, but usually any functions stored
in record fields are not bound to the state of the record.
Methods of an object are bound to the state of the object.

> Classes are a mechanism for *creating* objects (and in weaker languages 
> than OCaml, for defining subtyping relations). Take away inheritance and 
> you are basically left with fancy syntax for a function creating a 
> record of mutually recursive closures over some local variables.

Sure, but you're missing the point. In Haskell and in Oleg's Ocaml
implementation of typeclasses, a record object is like a C++ vtable.

A vtable contains static function pointers which can be
bound to the current object to create methods.

But I'm talking about replacing this with a class object,
so we're not talking about the methods binding against the
typeclass datatype .. we're talking about methods bound
against the typeclass itself.

> > They also don't make the weak assumption of an 
> > abstraction (possibly with default methods as in Haskell)
> > and a single instantiation: in C++ at least you can
> > have sequence of more derived classes.
> 
> Please distinguish subtyping and inheritance. 

I did. I said 'derived classes'.

> Type classes can express 
> something akin to nominal interface subtyping, e.g.
> 
>    class C a        where m1 :: t1
>    class C a => D a where m2 :: t2
> 
> But it's true that they do only provide a very weak form of inheritance 
> (via default methods).

Yes, its very weak. I don't know Haskell, but in Felix I have
typeclasses where I need to override the default method and I can't.

I don't know if Haskell suffers this restriction, but for someone
used to using C++ it shows the weakness of the 
typeclass/instance dichotomy  immediately. 
I actually need to do this:

typeclass container[bag,value] {
	virtual fold ..; // no default method
}

typeclass stl_container[bag,iterator,value] { 
   inherit container[bag,value]; // "implementation inheritance"
   fold .. // default method
}

because all STL containers have a single fold function,
implemented by using iterators. I need to instantiate
fold in the derived typeclass stl_container, but I'm
not allowed to.

So what I require is a tree:

	container --> stl_container --> vector --> vector<int>

and the distinction between typeclasses and instances is
a serious obstacle.

A C++ class has no such problems: you aren't limited to
defining an abstraction and one concrete instance class.

Roughly, my typeclasses allow adding new methods, but
you cannot override a method in a derived typeclass.

> Something like the covariance problem does not occur with type classes 
> (or modules, for that matter) because they decouple types from 
> interfaces. 

That's right.. it only occurs when you go up to the kind level.
Which occurs immediately if you want to try some dependent typing.
[I'm assuming a typeclass system with multiple type parameters
is required of course]

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

RE: [Caml-list] Operator overloading

[Robert Fischer]

I didn't realize that existed.  It's not so bad -- it lets me have my
cake and Jon eat it, too.  :D

~~ Robert.

-----Original Message-----
From: caml-list-bounces@yquem.inria.fr
[mailto:caml-list-bounces@yquem.inria.fr]On Behalf Of Fernando Alegre
Sent: Thursday, March 08, 2007 4:25 PM
To: Jon Harrop
Cc: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Operator overloading


On Thu, Mar 08, 2007 at 07:40:42PM +0000, Jon Harrop wrote:

> For me, operator overloading is about clarity. In the absence of
operator 
> overloading, you cannot regain the lost clarity using modules and
functors.


I often use the poor man's local operator overloading already built into
the core OCaml:

let result =
    let (+) = Vector.add and ( * ) (x:int) (v:Vector.t) =
Vector.scalarmul x v
    in 3 * a + 2 * b

This makes overloading local and explicit, and at the same time makes
expressions clear. I do not miss implicit overloading.

Fernando

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] Operator overloading

[Jon Harrop]

On Thursday 08 March 2007 23:20, Robert Fischer wrote:
> > let result =
> >     let (+) = Vector.add and ( * ) (x:int) (v:Vector.t) =
> > Vector.scalarmul x v
> >     in 3 * a + 2 * b
>
> I didn't realize that existed.  It's not so bad -- it lets me have my
> cake and Jon eat it, too.  :D

I've been using that style for years and it just doesn't hack it.

Firstly, note the verbosity compared to:

  let result = 3*a + 2*b

then note that many arithmetic expressions mix types, so you still end up 
needing +, +., +/, +| and +||.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

RE: [Caml-list] Operator overloading

[Robert Fischer]

> For example, I often define +| for vectors, +|| for matrices, *| for 
> scalar-matrix multiplication, *|| for vector-matrix and *||| for 
> matrix-matrix. I also want to support complex numbers and symbolic 
> expressions and I don't particularly want to remember and document 50 numeric 
> operators, nor explain their existence to my customers...
>
Which is exactly my point.  You should have to document all that, because they are genuinely different operations.  You have these operations, so why shouldn't you document them?  Or, better yet, abstract them and organize them.  By using operator overloading, you're sweeping under the rug genuine complexity -- something that my surprise later developers!

When I see "+", I want to know what that means.  With operator overloading, I don't know.  An IDE might help me out there, but that's just polishing a genuine ding on code readbility and maintainability.  Why should I have to rely on an IDE to make sense of my code?

If I have a typing issue in my code, I want the compiler balk at where the problem is.  The best I can hope for with operator overloading is that the result type is caught through a failure of duck typing shortly down the pipeline -- but that very safety would is undermined if "down the pipeline" also uses lots of operator overloading.

I'm very sure that you can code with operator overloading and be productive.  The person writing the code probably even feels like it's a productivity and readability boon.  But I see maintainability as a big problem here.  As far as I'm concerned, if two things do different things, they should have different names.  You can give them funny names like "+|", but it should still be different names.

~~ Robert.

-----Original Message-----
From: caml-list-bounces@yquem.inria.fr
[mailto:caml-list-bounces@yquem.inria.fr]On Behalf Of Jon Harrop
Sent: Thursday, March 08, 2007 1:41 PM
To: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Operator overloading


On Thursday 08 March 2007 17:54, Brian Hurt wrote:
> Roland Zumkeller wrote:
> > Wasn't there a more or less good reason for OCaml *not* to support
> > operator overloading?
>
> Yes.  Ocaml has modules and functors.  IMHO, any time you thing "boy,
> it'd be really nice to use operator overloading here", you should use a
> module and a functor instead.
> ...

For me, operator overloading is about clarity. In the absence of operator 
overloading, you cannot regain the lost clarity using modules and functors.

This is one of the two things I missed when I moved from C++ to OCaml: 
operator overloading and template metaprogramming for low-dimensional vector 
and matrix operations. The latter can be addressed by autogenerating code. 
The former cannot be addressed in the current OCaml.

For example, I often define +| for vectors, +|| for matrices, *| for 
scalar-matrix multiplication, *|| for vector-matrix and *||| for 
matrix-matrix. I also want to support complex numbers and symbolic 
expressions and I don't particularly want to remember and document 50 numeric 
operators, nor explain their existence to my customers and I certainly don't 
appreciate reading expressions written in this syntax.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] Operator overloading

[Michael Hicks]

This discussion reminds of a paper that appeared at POPL 2007 about the
relationship between ML modules and Haskell type classes.  The former are
really good for organizing your namespace and making dependencies and
operations explicit.  The latter are really good at (disciplined) operator
overloading (which is convenient as many here have argued).  The paper looks
at how the two can be combined (essentially, operator overloading is
implicit functor instantiation), so you can have the best of both worlds.

Now someone just needs to implement it for OCaml ...

Modular Type Classes.
Derek Dreyer, Robert Harper, and Manuel M.T. Chakravarty.
In 2007 ACM SIGPLAN Symposium on Principles of Programming Languages
http://ttic.uchicago.edu/~dreyer/papers/mtc/main-short.pdf
http://ttic.uchicago.edu/~dreyer/talks/popl07.ppt

-Mike

Re: [Caml-list] Operator overloading

[Brian Hurt]

Michael Hicks wrote:

>This discussion reminds of a paper that appeared at POPL 2007 about the
>relationship between ML modules and Haskell type classes.  The former are
>really good for organizing your namespace and making dependencies and
>operations explicit.  The latter are really good at (disciplined) operator
>overloading (which is convenient as many here have argued).  The paper looks
>at how the two can be combined (essentially, operator overloading is
>implicit functor instantiation), so you can have the best of both worlds.
>  
>

The reason type classes were implemented in Haskell was as a sane way to 
implement a generic equality operator.  Myself, I question the need for 
a generic equality operator.

Brian

Re: [Caml-list] Operator overloading

[Tom]

[-- Attachment #1: Type: text/plain, Size: 2257 bytes --]

On 08/03/07, Robert Fischer <RFischer@roomandboard.com> wrote:
>
>
> When I see "+", I want to know what that means.
>

I disagree and I couldn't disagree more. In mathematics, we're perfectly ?!?
using + for integer, float, complex, vector and matrix addition (and the
combinations of them) and * for integer, float, complex, vector, vector and
scalar, and matrix multiplication. One who doesn't understand what the
"code" - mathematical notation - means should blame oneself for not
understanding the algorithm, not the "designer" for making the "language" -
mathematical conventions - unappropriate.

Albeit Brian Hurt's comment about operator overloading making more harm than
good in C++, I believe that overloading simply has to be used appropriately
- it's like saying pointers are bad because they can introduce memory leaks
and null references, and division is bad because it can raise
Division_by_zero exceptions.

Like a saying for magic goes, "There is no black magic or white magic, there
is only magic. It's classification depends on the intentions of the caster!"
Any tool given to a programmer can be used either to his advantage or
disadvantage. Even in the "best" language, a stupid programmer will programm
poor algorithms, so there is no point protecting the programmer from himself
(or herself).

Hence, one can hardly say overloading (in general, not only operator
overloading) is bad in C++. If designed carefuly and mantained with a bit of
common sense, it can result in enormous productivity gain. And, how often
does it happen that you don't know what a particular operation means in a
three-lines-long numerical calculation involving vectors, floats and
matrices? Anyhow, if you DID get lost, then you would equally lose yourself
in a mess of *|, +\, %, -| and /. operators. You don't want OCaml be named
LISO - Lost In Superfluous Operators.

I believe that operator overloading an d overloading in general can result
in great productivity and readability gain. Also, they can improve
polymorphism. For example, does it matter if you can't figure out the type
of a in length a? Actually, it doesn't - it could be a list, an array, a
dynarray, a train or a snake - as long as it "fits" algorithmically, it can
be anything.

- Tom

[-- Attachment #2: Type: text/html, Size: 2787 bytes --]

Re: [Caml-list] Operator overloading

[Brian Hurt]

Tom wrote:

>
> Albeit Brian Hurt's comment about operator overloading making more 
> harm than good in C++, I believe that overloading simply has to be 
> used appropriately - it's like saying pointers are bad because they 
> can introduce memory leaks and null references, and division is bad 
> because it can raise Division_by_zero exceptions.
>
So maybe we should introduce pointers into Ocaml?

Brian

Re: [Caml-list] Operator overloading

[Michael Vanier]

Pointers were perhaps a bad example, since pointer arithmetic is incompatible 
with safe languages.  I see no such concern with respect to operator 
overloading, though there are certainly many ways in which it complicates the 
language.

This is one of those never-ending arguments that will never get settled to 
anyone's satisfaction; it's a matter of personal preference.  Why don't we start 
arguing about static versus dynamic typing while we're at it?

Mike


Brian Hurt wrote:
> Tom wrote:
> 
>>
>> Albeit Brian Hurt's comment about operator overloading making more 
>> harm than good in C++, I believe that overloading simply has to be 
>> used appropriately - it's like saying pointers are bad because they 
>> can introduce memory leaks and null references, and division is bad 
>> because it can raise Division_by_zero exceptions.
>>
> So maybe we should introduce pointers into Ocaml?
> 
> Brian
> 
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] Operator overloading

[Till Varoquaux]

Hum...

Instead of proving once again Godwin's law we might want to use
constructive criticism (even though I also tend to flame more than my
share)...

There have been many articles relating type classes and ML module
system. Lambda the Ultimate has link to quite a share of them.
Swapping type classes for modules forces you to be more explicit and
verbose. Indeed you would have to wrap your code in a functor whenever
you want ad-hoc polymorphism (aka overloading) to occur. This can
prove quite cumbersome. Haskell relies heavily on type classes, monads
would be much more painful if you had to wrap them in a functor.

Overloading, however, does come with a cost: the compiler cannot get
rid of all type information: sometime (e.g. separate compilation) the
right monomorphic function can only be done dynamically.

G'Caml brings extensional polymorphism (types as first class values)
to OCaml. Extensional polymorphism allows run time type introspection
thus allowing overloading...  whether you like it or not is a matter
of personal taste.

Till

P.S. FYI I happen to like type classes and exceptions. I do know there
are also good reasons not to and I respect other opinions.

On 3/8/07, Brian Hurt <bhurt@janestcapital.com> wrote:
> Tom wrote:
>
> >
> > Albeit Brian Hurt's comment about operator overloading making more
> > harm than good in C++, I believe that overloading simply has to be
> > used appropriately - it's like saying pointers are bad because they
> > can introduce memory leaks and null references, and division is bad
> > because it can raise Division_by_zero exceptions.
> >
> So maybe we should introduce pointers into Ocaml?
>
> Brian
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

Re: [Caml-list] Operator overloading

[Brian Hurt]

Till Varoquaux wrote:

> Hum...
>
> Instead of proving once again Godwin's law we might want to use
> constructive criticism (even though I also tend to flame more than my
> share)...


No, actually, I was making a point.  The fact that you don't like the 
point I was making doesn't make it a flame.  Disagreeing with you is not 
an insult.  Although I do find amusing the implication that bringing up 
pointer arithmetic is the equivelent to calling someone a Nazi.

Spelling the point out explicitly for those who missed it: when 
considering wether to add a feature to a language, you have to consider 
*BOTH* the valid uses of that feature *AND* the probable ways the 
feature will be misused and the problems it will cause.  You don't get 
to ignore the downsides.  Because, if you do, then there's no real 
reason why introducing pointer arithmetic into Ocaml is not a good idea.

Brian

Re: [Caml-list] Operator overloading

[skaller]

On Fri, 2007-03-09 at 11:02 -0500, Brian Hurt wrote:

> considering wether to add a feature to a language, you have to consider 
> *BOTH* the valid uses of that feature *AND* the probable ways the 
> feature will be misused and the problems it will cause.  You don't get 
> to ignore the downsides.  Because, if you do, then there's no real 
> reason why introducing pointer arithmetic into Ocaml is not a good idea.

Actually, using your criteria, it might a good idea IF it is possible
to limit abuse in a way compatible with Ocaml philosophy. For example
if you could ensure pointers always remained in bounds, or at least
threw an exception when an out of bound dereference occurred.

The latter seems acceptable because it is already what happens
with an out of bounds access to an array.

Array pointers seem easy to represent .. it's just a pair

	'a Array.t * int

Offset addition is statically safe, so you can throw that in too.
That can be implemented with composition of closures which access
record fields.

However it isn't clear any of this is worth it: pointer arithmetic
is used in C because it is fast, in Ocaml it probably wouldn't be,
an other techniques would provide the same functionality.

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] Operator overloading

[Ian Zimmerman]

On 3/8/07, Tom <tom.primozic@gmail.com> wrote:
>
>
> On 08/03/07, Robert Fischer <RFischer@roomandboard.com> wrote:
> >
> > When I see "+", I want to know what that means.
> >
>
> I disagree and I couldn't disagree more. In mathematics, we're perfectly ?!?
> using + for integer, float, complex, vector and matrix addition (and the
> combinations of them) and * for integer, float, complex, vector, vector and
> scalar, and matrix multiplication. One who doesn't understand what the
> "code" - mathematical notation - means should blame oneself for not
> understanding the algorithm, not the "designer" for making the "language" -
> mathematical conventions - unappropriate.
>

I agree with Robert and the analogy with maths notation only reinforces that:
when I was a student of maths, I frequently cursed the authors of
papers I was reading for using notation without definition.  Of
course, it was perfectly clear to someone seasoned in the area of the
paper, because the notation was conventional - but a puzzle for a
newbie.

Re: [Caml-list] Operator overloading

[Jon Harrop]

On Thursday 08 March 2007 22:14, Ian Zimmerman wrote:
> I agree with Robert and the analogy with maths notation only reinforces
> that: when I was a student of maths, I frequently cursed the authors of
> papers I was reading for using notation without definition.  Of
> course, it was perfectly clear to someone seasoned in the area of the
> paper, because the notation was conventional - but a puzzle for a
> newbie.

When I read some of Luca Cardelli's papers on type inference I found that they 
were not explicit enough and required me to infer a lot. When that inference 
went wrong the backtracking was costly and seemed unneccesary because I could 
have read a paper 4x as long that required no inference.

But aren't we all here because we like inference and brevity?

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

Re: [Caml-list] Operator overloading

[Ian Zimmerman]

> But aren't we all here because we like inference and brevity?

Inference: On condition it is _controlled_.  I.e. seeing operator
<foo> used on a complex type, I need to know I have seen its
definition and satisfied myself that it has the expected semantic
properties.  That's just what functors formalize.

Brevity: There's the pesky tradeoff with some type annotations being
required when you introduce overloading.

RE: [Caml-list] Operator overloading

[skaller]

On Thu, 2007-03-08 at 14:02 -0600, Robert Fischer wrote:

> When I see "+", I want to know what that means.  With operator overloading, I don't know. 

This argument is fallacious: When you see + you know it means addition
of whatever argument types are used.

Addition is well understood. The structure of the types is not
distinct.

The problem is that Ocaml doesn't provide sufficiently powerful
system to easily encapsulate this structure.

Addition is a bad example because it's somewhat questionable.
It is clearer if we talk of map, fold, and other such operations
which are clearly polyadic operators.

Overloading eases the burden of a weakness in the language,
not providing polyadic map and fold.

In fact Ocaml functors just provide overloading, because they
only work for finite manual instantiations.

They don't provide genunine polyadic programming.

FISh 1 is a polyadic array programming language, you can
do algorithms which are independent of rank
(number of dimensions). In that language, map and fold
only need ONE definition and then work on all data types.

BOTH Ocaml functors and overloading are just hacks to
work around the lack of ability to properly express
higher order natural transformations.

C++ provides polyadic behaviour: the whole of STL
is based on it, it just doesn't do it the right way.

The thing to understand is that a lot of programming
is experimental and/or loose: a lot of code is actually
written in dynamically typed scripting languages.

For systems like Ocaml, you need a mix of sloppiness
and heavy typing, because unless you're implementing
a well understood mathematical formalism, too much
formality and abstraction just gets in the way.

For example if you were implementing a C++ compiler in Ocaml
I'm going to bet you'd want plenty of space to fiddle with
your representations and concepts, because you don't quite
know what it is you're actually implementing.


-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] Operator overloading

[Tom]

[-- Attachment #1: Type: text/plain, Size: 1306 bytes --]

On 09/03/07, skaller <skaller@users.sourceforge.net> wrote:
>
>
> BOTH Ocaml functors and overloading are just hacks to
> work around the lack of ability to properly express
> higher order natural transformations.


 Hm... indeed, but for some operations, you cannot provide a single, general
definition - say for length operation, or for * (* is very different when it
comes to scalars, vectors and matrices - not even the same axioms hold). I
believe that the basic operations should be implemented using overloading
(actually, some smart overloading that would allow both static and
(seemingly) dynamic resolving) and then polyadic operations be built on top
of that.

For systems like Ocaml, you need a mix of sloppiness
> and heavy typing, because unless you're implementing
> a well understood mathematical formalism, too much
> formality and abstraction just gets in the way.
>
> For example if you were implementing a C++ compiler in Ocaml
> I'm going to bet you'd want plenty of space to fiddle with
> your representations and concepts, because you don't quite
> know what it is you're actually implementing.
>

I have a feeling what you say here is important, yet I don't quite
understand it... Can you clarify it ang give an example? And how (in your
opinion) can this problem be solved?

- Tom

[-- Attachment #2: Type: text/html, Size: 1811 bytes --]

Re: [Caml-list] Operator overloading

[skaller]

On Fri, 2007-03-09 at 08:23 +0100, Tom wrote:
> 
> 
> On 09/03/07, skaller <skaller@users.sourceforge.net> wrote:
>         
>         BOTH Ocaml functors and overloading are just hacks to
>         work around the lack of ability to properly express
>         higher order natural transformations.
> 
>  Hm... indeed, but for some operations, you cannot provide a single,
> general definition - say for length operation, or for * (* is very
> different when it comes to scalars, vectors and matrices - not even
> the same axioms hold). I believe that the basic operations should be
> implemented using overloading (actually, some smart overloading that
> would allow both static and (seemingly) dynamic resolving) and then
> polyadic operations be built on top of that. 

Actually, length can be defined in turns of fold:

let len x = fold (fun acc elt -> acc + 1) 0 container

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] Operator overloading

[Tom]

[-- Attachment #1: Type: text/plain, Size: 438 bytes --]

On 09/03/07, skaller <skaller@users.sourceforge.net> wrote:
>
>
> Actually, length can be defined in turns of fold:
>
> let len x = fold (fun acc elt -> acc + 1) 0 container
>

Yes, as long as x is a container. But how are you going to define a length
of a snake using fold?

Basically, I agree with you. I'm just saying that you can further increase
the "typeclass" of length-able objects to almost anything. Why limit
ourselves?

- Tom

[-- Attachment #2: Type: text/html, Size: 757 bytes --]

Re: [Caml-list] Operator overloading

[skaller]

On Fri, 2007-03-09 at 10:32 +0100, Tom wrote:
> 
> On 09/03/07, skaller <skaller@users.sourceforge.net> wrote:
>         
>         Actually, length can be defined in turns of fold:
>         
>         let len x = fold (fun acc elt -> acc + 1) 0 container
> 
> Yes, as long as x is a container. But how are you going to define a
> length of a snake using fold? 

That's a different kind of length. Now if you said 'worm'
there would be two kinds of length to define:

(a) the length in metres
(b) the number of segments

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] Operator overloading

[Jon Harrop]

On Friday 09 March 2007 09:32, Tom wrote:
> Basically, I agree with you. I'm just saying that you can further increase
> the "typeclass" of length-able objects to almost anything. Why limit
> ourselves?

Because there is a tradeoff between type inference and overloading. Operators 
are conventionally heavily overloaded (e.g. in maths) and having overloaded 
operators works well. Allowing all functions to be overloaded weakens 
inference more and doesn't buy you so much, so you must choose to draw the 
line somewhere.

I would like to have "sin" work on float and float32 in F# though... :-)

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

Re: [Caml-list] Operator overloading

[Jon Harrop]

On Thursday 08 March 2007 23:51, skaller wrote:
> On Thu, 2007-03-08 at 14:02 -0600, Robert Fischer wrote:
> > When I see "+", I want to know what that means.  With operator
> > overloading, I don't know.
>
> This argument is fallacious: When you see + you know it means addition
> of whatever argument types are used.

Not necessarily. It also means set union and string concatenation in F#, for 
example.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

Re: [Caml-list] Operator overloading

[Jon Harrop]

On Thursday 08 March 2007 20:02, Robert Fischer wrote:
> Which is exactly my point.  You should have to document all that, because
> they are genuinely different operations.  You have these operations, so why
> shouldn't you document them?  Or, better yet, abstract them and organize
> them.  By using operator overloading, you're sweeping under the rug genuine
> complexity -- something that my surprise later developers!

Because the distinction is purely incidental as it depends upon the language's 
choice of type system.

> When I see "+", I want to know what that means.  With operator overloading,
> I don't know.

The same can be said of type inference. Then you're advocating explicit type 
annotations everywhere.

> An IDE might help me out there, but that's just polishing a 
> genuine ding on code readbility and maintainability.  Why should I have to
> rely on an IDE to make sense of my code?

This is precisely why I rely so heavily on Tuareg's type throwback in Emacs.

If you sacrifice your development environment (even if it is just emacs) then 
productivity goes down. Failing to embrace a future of graphical IDEs is a 
bad idea, IMHO.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

Re: [Caml-list] Operator overloading

[Andrej Bauer]

To all who like overloading, I dearly suggest that they explain to 
themselves the following bit of Mathematica:

In[1]:= f[v_] = {{1,0}, {1,1}} . (v + {0,1});

In[2]:= f[{0,0}]

Out[2]= {{0, 0}, {1, 1}}

Firstly, if you do not think about the above, you won't even see what's 
wrong. Secondly, once you do see what is wrong, you won't know why it's 
wrong. The problem is caused by the meaning of + and Mathematica 
evaluation strategy.

Explanation of what is wrong:

1) {0,1} is a two-dimensional vector

2) {{1,0},{1,1}} is the 2x2 matrix with rows (1,0) and (1,1)

3) The operator . means, according to the help system:

  In[4]:= ?.
  a.b.c or Dot[a, b, c] gives products of vectors, matrices and tensors.

  For example, multiplying a 2x2 matrix and a 2D vector gives a 2D
  vector:

  In[5]:= {{1,0},{1,1}} . {0,1}

  Out[5]= {0, 1}

4) Clearly, + is addition :-) but in case you do not trust me:

  In[6]:= ?+
  x + y + z represents a sum of terms.

5) The definition of f then says: take v, add to it the vector {0,1}, 
then multiply by the 2x2 matrix {{1,0},{1,1}}.

6) Thus we compute f[{0,0}] by hand according to 5):

    f[{0,0}]
    = {{1,0},{1,1}} . ({0,0} + {0,1})
    = {{1,0},{1,1}} . {0,1}
    = {0,1}

7) Hmm, strange, Mathematica thinks the answer is a 2x2 matrix, and we 
think it's a 2D vector.

Have fun overloading!

I will repeat my suggestion again: when writing serious and complicated 
code, overloading can cause a lot of harm. When manipulating expressions 
such as vectors and matrices interactively, it is convenient to have 
overloaded + etc. Perhaps the right way to solve the dilemma is to have 
a "toplevel on streoids" which intelligently resolves ambiguities. The 
intelligence can then go much further than simple overloading.

Andrej

Re: [Caml-list] Operator overloading

[Jacques Carette]

Andrej Bauer wrote:
> I will repeat my suggestion again: when writing serious and 
> complicated code, overloading can cause a lot of harm. When 
> manipulating expressions such as vectors and matrices interactively, 
> it is convenient to have overloaded + etc. Perhaps the right way to 
> solve the dilemma is to have a "toplevel on streoids" which 
> intelligently resolves ambiguities. The intelligence can then go much 
> further than simple overloading.

The (heavily typed) computer algebra system Axiom tried just this.  The 
end result was that, frequently, 90% of the computation time was spent 
in the "toplevel guesser", 10% on the actual computation.  Much worse 
was that while the underlying computations were very predictable (types 
help), the toplevel was so huge and complex, that it was unpredictable 
what *it* would do.  And, worse, lots and lots of "types" now resolved 
to the catch-all 'Expression' type.

Note however that Matlab also has its share of massive overloading, and 
yet it doesn't suffer as much as Mathematica does from this.  So there 
must be something about the richness of the available data-structures 
that makes the Matlab approach 'fail'.

Jacques

Re: [Caml-list] Operator overloading

[Andreas Rossberg]

Andrej Bauer wrote:
> 
> 7) Hmm, strange, Mathematica thinks the answer is a 2x2 matrix, and we 
> think it's a 2D vector.

Now you left me puzzled. Can you explain *why* Mathematica thinks 
differently?

-- 
Andreas Rossberg, rossberg@ps.uni-sb.de

Re: [Caml-list] Operator overloading

[Daniel Andor]

[-- Attachment #1: Type: text/plain, Size: 1950 bytes --]

On 3/9/07, Andrej Bauer <Andrej.Bauer@fmf.uni-lj.si> wrote:
>
> To all who like overloading, I dearly suggest that they explain to
> themselves the following bit of Mathematica:
>
> In[1]:= f[v_] = {{1,0}, {1,1}} . (v + {0,1});
>
> In[2]:= f[{0,0}]
>
> Out[2]= {{0, 0}, {1, 1}}


If you define the function f as most people would expect a function to work,
and the way you would be taught in Mathematica to define a function, and the
way you define 95% of your functions, you get the expected answer:

In[1]:= f[v_] := {{1,0}, {1,1}} . (v + {0,1});

In[2]:= f[{0,0}]

Out[2]= {0, 1}

So I think you are a little disingenuous in your example... ;)

Lots of interesting and sophisticated reasons have been given for the pros
and cons of overloading.  As someone who programs numerical code on a daily
basis, I would just like to make a practical comment:

A reason to appreciate strong typing (and inference that makes it brief) is
that it catches a good number of bugs.  When programming mathematical
algorithms, not having overloading increases the complexity of the code and
hence introduces bugs.  Why?  Most mathematicians I know syntax highlight
with their eyes.  Complexity thwarts this process.  (Until you have a
programming language that checks the algorithm as well as computes it, this
human syntax highlighter is the best (well, only) thing you've got.)

I do occasionally get caught by the kind of error that Andrej mentions.  But
nonetheless I still reach for Mathematica, because algorithmic correctness
(which depends on my interaction with the computer) is at least as important
to me as type safety.

You know, if efficiency didn't matter, then we could all still prove our
programs with pencil and paper and then program it in assembler (or
punchcards).

Can't there be a systematic way of doing this overloading that will not
upset people while allow me (and Jon?) to `see' clearly?  There's got to be
a way!  :)

$0.0314,
Daniel.

[-- Attachment #2: Type: text/html, Size: 2394 bytes --]

Re: [Caml-list] Operator overloading

[David Thomas]

I rather like the idea proposed earlier of being able
to say Module.(expression), where operators within
that expression are drawn exclusively from Module (we
can then say that the entire program is wrapped in an
implicit Pervasives.() which seems somewhat elegant. 
It would allow cleaning up of complex mathematic
expressions while not introducing ambiguities.  It
seems the biggest downside is some possibly
unnecessary complexity.

All of that said, I was not, prior to this discussion,
aware that one could locally override operators
already defined.  I expect this to clean up a bit of
my code when I get to applying it, and having done
that I'll let you all know whether I feel it's
sufficient or would still like to see the extension,
for whatever it's worth (in which case, I'll get
around to learning camlp4, I expect... :-p).


 
____________________________________________________________________________________
Never miss an email again!
Yahoo! Toolbar alerts you the instant new Mail arrives.
http://tools.search.yahoo.com/toolbar/features/mail/

RE: [Caml-list] F#

[Robert Fischer]

> However, operator overloading (i.e. overloading symbols) makes numerical code 
> so much easier to read that it is worth sacrificing some inference for it.
>

Unless, of course, you like to know what it is you're actually doing.

It's bad enough trying to figure out what "+" means in an overloaded environment with nominal typing.  With duck typing, it's a mess, and it's a mess that both you and the compiler have to work hard to figure out.

I highly suggest checking out the Programmer-to-Programmer book on C# and their conversation about operator overloading.  They do a nice job documenting just why it's such a dangerous tool in the toolbox.

~~ Robert.

Re: [Caml-list] F#

[Roland Zumkeller]

Wasn't there a more or less good reason for OCaml *not* to support
operator overloading?

-- 
http://www.lix.polytechnique.fr/~zumkeller/

Re: [Caml-list] F#

[Brian Hurt]

Roland Zumkeller wrote:

> Wasn't there a more or less good reason for OCaml *not* to support
> operator overloading?
>
Yes.  Ocaml has modules and functors.  IMHO, any time you thing "boy, 
it'd be really nice to use operator overloading here", you should use a 
module and a functor instead.

I have a long post on this topic comming soon, but for now:
1) Functors state up front what operators need to be provided to the 
code.  This is less of a problem with purely numeric code, but I've yet 
to see a language that allowed operator overloading and then exercised 
the restraint and kept them only on numeric types.  At which point, 
having it stated in the .mli file what operators are needed, and having 
it checked that you're actually providing them, is nice.

2) Functors allow for more flexible semantics as to what operations need 
to be provided, so operations that aren't obviously operators can be 
required as well- for example, Newton's method likes having an "equals 
within epsilon" function, or norm operation, neither of which are really 
operators.

3) Functors allow for more types- for example, if you're doing Newton's 
method on complex numbers, the type of an epsilon, or the type of a 
norm, is not a complex number, but instead just a real.  Or if you're 
doing Newton's method on vectors, the type of the derivitive is a 
matrix.  These are easy to express this with functors, hard to do with 
operator overloading.

4) Functors make it easier to swap in alternate implementations of 
various operations.  For example, doing Newton's method on vectors, you 
end up needing to calculate b/A, where A is a matrix and b a vector.  
This is easy enough to translate as solving Ax=b, you standard linear 
system.  It's nice to be able to switch out which linear system solver 
you want to use with functors, rather harder with operator overloading.

Brian

Re: [Caml-list] Operator overloading

[Jon Harrop]

On Thursday 08 March 2007 17:54, Brian Hurt wrote:
> Roland Zumkeller wrote:
> > Wasn't there a more or less good reason for OCaml *not* to support
> > operator overloading?
>
> Yes.  Ocaml has modules and functors.  IMHO, any time you thing "boy,
> it'd be really nice to use operator overloading here", you should use a
> module and a functor instead.
> ...

For me, operator overloading is about clarity. In the absence of operator 
overloading, you cannot regain the lost clarity using modules and functors.

This is one of the two things I missed when I moved from C++ to OCaml: 
operator overloading and template metaprogramming for low-dimensional vector 
and matrix operations. The latter can be addressed by autogenerating code. 
The former cannot be addressed in the current OCaml.

For example, I often define +| for vectors, +|| for matrices, *| for 
scalar-matrix multiplication, *|| for vector-matrix and *||| for 
matrix-matrix. I also want to support complex numbers and symbolic 
expressions and I don't particularly want to remember and document 50 numeric 
operators, nor explain their existence to my customers and I certainly don't 
appreciate reading expressions written in this syntax.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

Re: [Caml-list] Operator overloading

[Brian Hurt]

[-- Attachment #1: Type: text/plain, Size: 1182 bytes --]

Jon Harrop wrote:

>On Thursday 08 March 2007 17:54, Brian Hurt wrote:
>  
>
>>Roland Zumkeller wrote:
>>    
>>
>>>Wasn't there a more or less good reason for OCaml *not* to support
>>>operator overloading?
>>>      
>>>
>>Yes.  Ocaml has modules and functors.  IMHO, any time you thing "boy,
>>it'd be really nice to use operator overloading here", you should use a
>>module and a functor instead.
>>...
>>    
>>
>
>For me, operator overloading is about clarity. In the absence of operator 
>overloading, you cannot regain the lost clarity using modules and functors.
>  
>
Hmm.  My experience from C++ was that operator overloading results in a 
net *loss* in clarity of the code.  For every time I've seen operator 
overloading done correctly, I've seen it abused at least twice, probably 
more often.  And this is even ignoring the use of << and >> in IO.  By 
abused, I mean "used in a way that violates the numerical implications 
of the operator".

There are also the case of bugs introduced by operator overloading.  For 
example, in C++, this sucker has bitten me:
       int i = 10;
       cout << i << 2;

The problem here is the two different meanings of <<. 

Brian


[-- Attachment #2: Type: text/html, Size: 1822 bytes --]

Re: [Caml-list] Operator overloading

[Fernando Alegre]

On Thu, Mar 08, 2007 at 07:40:42PM +0000, Jon Harrop wrote:

> For me, operator overloading is about clarity. In the absence of operator 
> overloading, you cannot regain the lost clarity using modules and functors.


I often use the poor man's local operator overloading already built into
the core OCaml:

let result =
    let (+) = Vector.add and ( * ) (x:int) (v:Vector.t) = Vector.scalarmul x v
    in 3 * a + 2 * b

This makes overloading local and explicit, and at the same time makes
expressions clear. I do not miss implicit overloading.

Fernando

RE: [Caml-list] operator overloading

[Issac Trotts]

Hello,

> > Looking at the Google results, operator overloading has come up
> > as a frequently discussed topic.  Still I didn't find anything
> > very useful in the posts that Google brought up.  Can anyone
> > recommend a way to work around OCaml's lack of operator overloading
> > when dealing with matrices, vectors, and spinors?  Is there a
> > way to implement this with ocamlp4?
>
> As already someone has mentioned, you can try G'Caml: O'Caml with
> Extensional Polymorphism Extension. You can overload values
> over identifiers (including constants and operators),
> in the style of the pattern matching on types. Its experimental
> implementation is found at
>
>    http://pauillac.inria.fr/~furuse/generics/
>
> Regards,
> --------------------------------------------------------------
> ---------
> Jun P. Furuse 					
> Jun.Furuse@inria.fr
>

This looks like a very useful variant of OCaml.  Are there any plans
to merge it with the main OCaml source after the bugs are worked out?

Cheers,
Issac Trotts
Programmer
Idol Minds




-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] operator overloading

[Issac Trotts]

I would agree that C++'s operator overloading is a little warty,
but it's easy enough use.

Maybe it would be possible to extend OCaml's odd idea of using
different looking operators for different types.  For instance,
3D vector operations could be done like this:

	a +^ b (* add *)
	a -^ b (* subtract *)
	a .^ b (* dot product *)
	a ^^ b (* cross product, or maybe wedge product *)

Matrix operations could be done with #'s after the operators.
Spinor ops could be suffixed with @s, etc.

Issac


> -----Original Message-----
> From: forsyth@caldo.demon.co.uk [mailto:forsyth@caldo.demon.co.uk]
> Sent: Saturday, April 13, 2002 2:44 AM
> To: caml-list@inria.fr
> Subject: RE: [Caml-list] operator overloading
>
>
> >>compared to
> >>the simple mechanism for overloading operators in C++.
> >>It would be nice to see something more straightforward.
>
> i think it's the first time i've seen operator overloading in
> C++ described
> as a `simple mechanism'.
>
> -------------------
> To unsubscribe, mail caml-list-request@inria.fr Archives:
http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ:
http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] operator overloading

[forsyth]

>>compared to
>>the simple mechanism for overloading operators in C++.
>>It would be nice to see something more straightforward.

i think it's the first time i've seen operator overloading in C++ described
as a `simple mechanism'.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] operator overloading

[Gurr, David (MED, self)]

Try a google search for FOC and ocaml and see if that is not
a better solution to matrices, etc than overloading. -D

> -----Original Message-----
> From: Issac Trotts [mailto:ITrotts@IdolMinds.com]
> Sent: Friday, April 12, 2002 12:08 PM
> To: caml-list@inria.fr
> Subject: [Caml-list] operator overloading
> 
> 
> Looking at the Google results, operator overloading has come up 
> as a frequently discuseed topic.  Still I didn't find anything 
> very useful in the posts that Google brought up.  Can anyone 
> recommend a way to work around OCaml's lack of operator overloading
> when dealing with matrices, vectors, and spinors?  Is there a 
> way to implement this with ocamlp4?
> 
> Issac Trotts 
> Programmer
> Idol Minds
> 
> 
> 
> 
> -------------------
> To unsubscribe, mail caml-list-request@inria.fr Archives: 
http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ:
http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] operator overloading

[Issac Trotts]

Looking at the Google results, operator overloading has come up
as a frequently discuseed topic.  Still I didn't find anything
very useful in the posts that Google brought up.  Can anyone
recommend a way to work around OCaml's lack of operator overloading
when dealing with matrices, vectors, and spinors?  Is there a
way to implement this with ocamlp4?

Issac Trotts
Programmer
Idol Minds




-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] operator overloading

[William Chesters]

Issac Trotts writes:
 > Looking at the Google results, operator overloading has come up 
 > as a frequently discuseed topic.  Still I didn't find anything 
 > very useful in the posts that Google brought up.  Can anyone 
 > recommend a way to work around OCaml's lack of operator overloading
 > when dealing with matrices, vectors, and spinors?  Is there a 
 > way to implement this with ocamlp4?

Do you really want overloading for this purpose?  If it's just for
cosmetic purposes, like being able to write

      z := A * x + y

where x y z are vectors and A a matrix, then I for one am happy with

      z |:=| A %*| x |+| y

(where %*| means matrix-times-vector, etc.).  At least you get to see
what's really going on.  And in practice the cosmetics at this level
are unimportant compared with all the other things you have to worry
about.  In my experience, few real algorithms can be coded using
uniform, pretty, matrix algebra, especially if you care about
speed.  If yours can and you don't, then why not use matlab? ;)

   To my mind a more important limitation of ocaml is that it can't
do inlining across module boundaries, which means that the
possibilities for coding generic (as opposed to overloaded!)
algorithms using the functor/module system are often made less
attractive by slowness.  It's the inlining, not the overloading,
which makes C++ templates useful for this purpose.
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] operator overloading

[Brian Rogoff]

On Sat, 13 Apr 2002, William Chesters wrote:
> Issac Trotts writes:
>  > Looking at the Google results, operator overloading has come up
>  > as a frequently discuseed topic.

Overloading has been discussed frequently, and it is a very desired
feature by some (including me!) and a much less desired feature by others.
"Operator overloading" is a funny term. You can rebind infix operators
but you don't get overloading. Try out G'Caml if you want to get the
flavor of the proposed Caml approach. It's experimental, and I doubt it
will be merged in the main branch anyime soon.

>  > Still I didn't find anything
>  > very useful in the posts that Google brought up.  Can anyone
>  > recommend a way to work around OCaml's lack of operator overloading
>  > when dealing with matrices, vectors, and spinors?  Is there a
>  > way to implement this with ocamlp4?
>
> Do you really want overloading for this purpose?  If it's just for
> cosmetic purposes, like being able to write
>
>       z := A * x + y
>
> where x y z are vectors and A a matrix, then I for one am happy with
>
>       z |:=| A %*| x |+| y
>
> (where %*| means matrix-times-vector, etc.).

I guess there really is no accounting for taste! ;-)

> At least you get to see what's really going on.

The whole point of abstraction is to forget about what's really going on.

Anyways, there are a number of places, besides linear algebra, where
some kind of overloading is (arguably of course) desirable. In the FP
world, you'll have to go to Haskell or Clean if this kind of thing
is what you desire. Personally, I do desire it, but I think strict
languages are better than lazy ones, and that that is a more important
criteria than overloading.

Certainly, C++ is not what I'm thinking about when I'm thinking nice
thoughts about overloading. Implicit coercion and overloading shouldn't be
mixed.

>    To my mind a more important limitation of ocaml is that it can't
> do inlining across module boundaries, which means that the
> possibilities for coding generic (as opposed to overloaded!)
> algorithms using the functor/module system are often made less
> attractive by slowness.  It's the inlining, not the overloading,
> which makes C++ templates useful for this purpose.

Yes, this is a real problem too. The implementors will be employed for a
long time to come!

-- Brian
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] operator overloading

[William Chesters]

Brian Rogoff writes:
 > > Do you really want overloading for this purpose?  If it's just for
 > > cosmetic purposes, like being able to write
 > >
 > >       z := A * x + y
 > >
 > > where x y z are vectors and A a matrix, then I for one am happy with
 > >
 > >       z |:=| A %*| x |+| y
 > >
 > > (where %*| means matrix-times-vector, etc.).
 > >
 > > At least you get to see what's really going on.
 > 
 > The whole point of abstraction is to forget about what's really going on.

Is it?

Sometimes, as with linear algebra, the point is just to express what's
going on more concisely and maintainably.

Sometimes the point is to leave what's really going on *undefined*,
e.g. using a functor.  It's precisely in this case that it's really
essential not to elide distinctions between operators, because that
will make it harder for people to recover "what is going to happen" in
any particular application.  I.e. they simply don't have the faintest
idea how or why your program actually works.  That's one of the
downsides of abstraction: it's all too easy to end up with a system
which is harder to maintain rather than easier, and with libraries
which have narrower applicablity (because they are very obscure)
rather than broader.

C++'s abstraction mechanism is wonderful on paper: it does the same as
ML functors but is actually efficient (if you use the right compiler).
In practice, though, it's awfully hard to do anything ambitious with
it, because you can't specify signatures and because there are too
many opportunities for ambiguity, so that you end up with an unwieldy
mess which it's impossible for the reader to "find an end of" and
begin unravelling.  If ocaml could inline functors it would be a much
better vehicle for building abstract numerical libraries than C++.
The fact that it _doesn't_ have overloading and _does_ force you to
specify everything transparently is a strength, not a weakness, to my
mind.
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] operator overloading

[Brian Rogoff]

On Sat, 13 Apr 2002, William Chesters wrote:
> C++'s abstraction mechanism is wonderful on paper: it does the same as
> ML functors but is actually efficient (if you use the right compiler).
> In practice, though, it's awfully hard to do anything ambitious with
> it, because you can't specify signatures and because there are too
> many opportunities for ambiguity, so that you end up with an unwieldy
> mess which it's impossible for the reader to "find an end of" and
> begin unravelling.  If ocaml could inline functors it would be a much
> better vehicle for building abstract numerical libraries than C++.

I agree with the comment about C++, but this is completely unrelated to
the issue of overloading. Ada generics behave like functors in this
case (Ada 95 generic formal package parameters and null bodied generic
packages get you a lot closer than Ada 83 ever did) and the typical
implementation strategy is like that of C++. You never get that avalanche
of link time errors with Ada 95, and it does have overloading (even
overloading based on function return types!).

I also agree that some some sort of defunctorizer or even whole program
compiler would be a big win in that we could adopt a more  heavily
functorized style without worrying about performance.

> The fact that it _doesn't_ have overloading and _does_ force you to
> specify everything transparently is a strength, not a weakness, to my
> mind.

This seems like trying to make a virtue out of an annoying situation. In
languages without type inference, you have to specify more too (separate
rant: some explicit typing is good!). I doubt we'll agree on this issue,
but let me point out that the proposed overloading mechanism for Caml
appears to be "orthogonal", like the object system, so if it is ever added
you wouldn't be forced into using it.

-- Brian
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] operator overloading

[Daniel de Rauglaudre]

Hi,

On Fri, Apr 12, 2002 at 01:08:15PM -0600, Issac Trotts wrote:

> Can anyone recommend a way to work around OCaml's lack of operator
> overloading when dealing with matrices, vectors, and spinors?  Is
> there a way to implement this with ocamlp4?

Camlp4 cannot help: overloading is not just syntax. Camlp4 can sometimes
extend the typing, but not in this case.

-- 
Daniel de RAUGLAUDRE
daniel.de_rauglaudre@inria.fr
http://cristal.inria.fr/~ddr/
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] operator overloading

[Johan Georg Granström]

> Looking at the Google results, operator overloading has come up
> as a frequently discuseed topic.  Still I didn't find anything
> very useful in the posts that Google brought up.  Can anyone
> recommend a way to work around OCaml's lack of operator overloading
> when dealing with matrices, vectors, and spinors?  Is there a
> way to implement this with ocamlp4?

I had a way of working around lack of overloading, which is
actually pretty nice, when working with LISP a couple of years
ago. You simply define a macro which creates local bindings
for the arithmetic functions: then you can write for example

(let ((A (make-van-der-monde 3))
      (B (make-matrix '((4 2 1) (7 4 1) (8 5 2)))))
 (with-matrix-arithmetic
    (* (+ B A) (- B A))))

where make-van-der-monde and make-matrix are made up functions
and with-matrix-arithmetic is the macro you define. In ocaml
I guess this would become something like:

let a = make_van_der_monde 3
and b = make_matrix [|...|] in
  matrix_arithmetic
    (B + A) * (B - A)

By defining the proper macro (using camlp4 I guess), this would
expand to something like:

let a = make_van_der_monde 3
and b = make_matrix [|...|] in
  let (+) = (Matrix.+)
  and (-) = (Matrix.-)
  and (*) = (Matrix.*) in
    (B + A) * (B - A)

Similar macros could be defined for computation in whatever
ring/field/group or whatever, you like...


This is just an idea...

Yours,

- Johan Granström

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] operator overloading

[Jacques Garrigue]

From: Johan Georg Granström <georg.g@home.se>

> I had a way of working around lack of overloading, which is
> actually pretty nice, when working with LISP a couple of years
> ago. You simply define a macro which creates local bindings
> for the arithmetic functions: then you can write for example
[...]
> let a = make_van_der_monde 3
> and b = make_matrix [|...|] in
>   matrix_arithmetic
>     (B + A) * (B - A)
> 
> By defining the proper macro (using camlp4 I guess), this would
> expand to something like:
> 
> let a = make_van_der_monde 3
> and b = make_matrix [|...|] in
>   let (+) = (Matrix.+)
>   and (-) = (Matrix.-)
>   and (*) = (Matrix.*) in
>     (B + A) * (B - A)

Note that if we had a let open ... in ... construct, you wouldn't even
need camlp4 for that:

  let a = make_van_der_monde 3
  and b = make_matrix [|...|] in
  let open Matrix in
     (b + a) * (b - a)

By the way, this construct can already be simulated with camlp4.

Note of course that this is not as powerful as overloading, since you
often want to mix different instance of arithmetic operations in the
same formula.

Cheers,

        Jacques-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] operator overloading

[Jun P.FURUSE]

Hello,

> Looking at the Google results, operator overloading has come up 
> as a frequently discuseed topic.  Still I didn't find anything 
> very useful in the posts that Google brought up.  Can anyone 
> recommend a way to work around OCaml's lack of operator overloading
> when dealing with matrices, vectors, and spinors?  Is there a 
> way to implement this with ocamlp4?

As already someone has mentioned, you can try G'Caml: O'Caml with
Extensional Polymorphism Extension. You can overload values
over identifiers (including constants and operators),
in the style of the pattern matching on types. Its experimental
implementation is found at 

   http://pauillac.inria.fr/~furuse/generics/

Regards,
-----------------------------------------------------------------------
Jun P. Furuse 					 Jun.Furuse@inria.fr
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners