[Caml-list] Why are arithmetic functions not polymorph?

[Caml-list] Why are arithmetic functions not polymorph?

[hermanns]

Hello,

I'm new to OCaml, so I hope my question is not to stupid.

Can anybody explain to me why the arithmetic functions ('+', '-', ...) 
are not polymorph
(in the sense that they have floating point equivalents '+.', '-.', 
...).
I don't understand this, because comparison funtions ('<', '>', ...) 
are polymorph.
So, where is the problem with arithmetic functions?

regards, Jan

-------------------
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] Why are arithmetic functions not polymorph?

[Brian Hurt]

On Fri, 23 May 2003, hermanns wrote:

> Hello,
> 
> I'm new to OCaml, so I hope my question is not to stupid.
> 
> Can anybody explain to me why the arithmetic functions ('+', '-', ...) 
> are not polymorph
> (in the sense that they have floating point equivalents '+.', '-.', 
> ...).
> I don't understand this, because comparison funtions ('<', '>', ...) 
> are polymorph.
> So, where is the problem with arithmetic functions?
> 

Type inference is the short answer.  Consider the function:

let foo a b = a + b

Without operator overloading, the type this function has is clear- + only 
operates on integers, so it's type is int->int->int.  Were I to write:

let foo a b = a +. b

now the type is clearly float->float->float.

The comparison operators call a generic- and comparitively expensive-
comparison function.  If you know that you are only going to be comparing 
(for example) ints, it's oftentimes faster to explicitly state the types 
involved, like:

let foo (a: int) (b: int) = a < b

This allows the compiler to replace the call to the expensive comparison 
function with a cheap inline integer comparison.

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] Why are arithmetic functions not polymorph?

[Nicolas Cannasse]

> I don't understand this, because comparison funtions ('<', '>', ...)
> are polymorph.
> So, where is the problem with arithmetic functions?

Because perhaps there is always a good way to compare two data structures
(with the exception of functions) since we can recursively compare their C
representations, but there is not a good way to actually add or even
multiply them.

For exemple it somehow makes sense to compare  [] with [2] ( in that case []
< [2] ) but what about [] / [2]  ?

Nicolas Cannasse

-------------------
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] Why are arithmetic functions not polymorph?

[David Monniaux]

On Fri, 23 May 2003, hermanns wrote:
> I don't understand this, because comparison funtions ('<', '>', ...) 
> are polymorph.
> So, where is the problem with arithmetic functions?

There are several reasons.

First, short of considering arithmetic types to be objects, there is no
way to write types such as: forall ('a : arithmetic type), 'a -> 'a -> 'a.
You may only write types of the form: forall 'a, 'a -> 'a -> 'a.

This is not a problem since the polymorphic comparison function has the
type: forall 'a, 'a -> 'a -> int. Polymorphic comparisons is a priori
defined on all types; if used on functional objects, it may throw an
exception.

Second, it would be inefficient. Polymorphic comparison is implemented by
traversing the memory data structures, using the run-time type information
meant for the garbage collector.

Note that if the compiler can figure at compile time that the type of the
operands of <, <= etc..., it may generate some specialized version more
efficient than calling the polymorphic comparison routine.

In short, using a similar solution for +, -, *, / would be a bad idea:
- polymorphic comparisons are inefficient compared to comparisons on
  integers and IEEE floating-point numbers;
- short of a significant change in the type system, +, -, *, / would not
  refuse non-arithmetic operands, but would throw exceptions at runtime if
  applied to non-arithmetic arguments.

SML has a kind of operator overloading, but I don't know the details.

David Monniaux            http://www.di.ens.fr/~monniaux
Laboratoire d'informatique de l'École Normale Supérieure,
Paris, France

-------------------
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] Why are arithmetic functions not polymorph?

[Ville-Pertti Keinonen]

> SML has a kind of operator overloading, but I don't know the details.

They're overloaded up to the point of type inference, after which they 
become integer operations.  I think it's better not to have something 
as inconsistent as SML.

This works:

- op +;
val it = fn : int * int -> int
- op + (1.0, 2.0);
val it = 3.0 : real

This doesn't:

- val myadd = op +;
val myadd = fn : int * int -> int
- myadd (1.0, 2.0);

-------------------
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] Why are arithmetic functions not polymorph?

[brogoff]

On Fri, 23 May 2003, David Monniaux wrote:
[... nice explanations snipped ...]
> - short of a significant change in the type system, +, -, *, / would not
>   refuse non-arithmetic operands, but would throw exceptions at runtime if
>   applied to non-arithmetic arguments.

GCaml, which will be resurrected after 3.07 is released, is just such an 
extension to the type system. It would also allow using + for string 
concatenation, or using the arithmentic operators for set operations. 

Given the ability to control syntax, it would also enable one to use array 
syntax to access hash tables or maps, or string accesses. I believe that the
desire to do this was discussed some time ago in the context of extensional 
polymorphism (i.e., GCaml generics) but the syntactic issue was ignored. 

> SML has a kind of operator overloading, but I don't know the details.

SML doesn't allow the user to define overloadings, and that is an 
abomination. Java is similarly abominable. 

-- 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] Why are arithmetic functions not polymorph?

[Brian Hurt]

On Fri, 23 May 2003 brogoff@speakeasy.net wrote:

> > SML has a kind of operator overloading, but I don't know the details.
> 
> SML doesn't allow the user to define overloadings, and that is an 
> abomination. Java is similarly abominable. 
> 

Ocaml allows you to define *new* operators to your heart's content.  You
just can't overload the meanings of old operators.  And frankly, I don't
find that abominable at all.  I don't want to turn this into a C++ 
flamefest (had one of those already this week), but in my experience 
operator overloading is *really* *really* bad.

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] Why are arithmetic functions not polymorph?

[Matt Gushee]

On Fri, May 23, 2003 at 01:02:33PM -0500, Brian Hurt wrote:
> On Fri, 23 May 2003 brogoff@speakeasy.net wrote:
> 
> > > SML has a kind of operator overloading, but I don't know the details.
> > 
> > SML doesn't allow the user to define overloadings, and that is an 
> > abomination. Java is similarly abominable. 
> > 
> 
> Ocaml allows you to define *new* operators to your heart's content.  You
> just can't overload the meanings of old operators.  And frankly, I don't
> find that abominable at all.  I don't want to turn this into a C++ 
> flamefest (had one of those already this week), but in my experience 
> operator overloading is *really* *really* bad.

Hmm, you may be right. Much of my programming experience is with Python,
where operators applied to objects are implemented as instance methods,
and can be overloaded to your heart's content. For example:

  class FunnyMoney:
      def __init__(self):
          self.balance = 0
      def __sub__(self, other):
          self.balance = self.balance + other   # BWAHAHAHAAA!

  myaccount = FunnyMoney()
  myaccount.balance
  ==> 0
  myaccount - 12000000
  myaccount.balance
  ==> 12000000

Of course, you can have a lot of fun with this feature. But it may be a
rather bad idea for real-world applications.

-- 
Matt Gushee                 When a nation follows the Way,
Englewood, Colorado, USA    Horses bear manure through
mgushee@havenrock.com           its fields;
http://www.havenrock.com/   When a nation ignores the Way,
                            Horses bear soldiers through
                                its streets.
                                
                            --Lao Tzu (Peter Merel, trans.)

-------------------
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] Why are arithmetic functions not polymorph?

[brogoff]

On Fri, 23 May 2003, Brian Hurt wrote:
> On Fri, 23 May 2003 brogoff@speakeasy.net wrote:
> 
> > > SML has a kind of operator overloading, but I don't know the details.
> > 
> > SML doesn't allow the user to define overloadings, and that is an 
> > abomination. Java is similarly abominable. 
> > 
> 
> Ocaml allows you to define *new* operators to your heart's content.  You
> just can't overload the meanings of old operators.

I understand the difference between operator redefinition, which OCaml and 
SML have, and user defined overloading, which neither has, but which can be 
found in Haskell and Clean (sort of, through type classes) and C++ and Ada. 

I actually think overloading can be *really* *really* good. The problem, or 
rather, one of the many problems, with C++ IMO is that it has overloading and 
implicit conversions of types. That's a bad combination. 

One nice thing about GCaml is that it shouldn't bother people like you who 
dislike overloading. The overloading is fairly explicit and closed world. 
It gracefully handles the most important, very simple cases, and sneaks 
in the ability to type a much wider range of functions than can be typed now. 
You should at least take a look at the README in the prototype to get an idea of 
what I mean here. 

New operators are not sufficient, and SML is more powerful in it's ability to 
define new operators than OCaml (minus CamlP4) is. 

-- 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] Why are arithmetic functions not polymorph?

[Brian Hurt]

On Fri, 23 May 2003 brogoff@speakeasy.net wrote:

> I understand the difference between operator redefinition, which OCaml and 
> SML have, and user defined overloading, which neither has, but which can be 
> found in Haskell and Clean (sort of, through type classes) and C++ and Ada. 
> 
> I actually think overloading can be *really* *really* good. The problem, or 
> rather, one of the many problems, with C++ IMO is that it has overloading and 
> implicit conversions of types. That's a bad combination. 
> 
> One nice thing about GCaml is that it shouldn't bother people like you who 
> dislike overloading. The overloading is fairly explicit and closed world. 
> It gracefully handles the most important, very simple cases, and sneaks 
> in the ability to type a much wider range of functions than can be typed now. 
> You should at least take a look at the README in the prototype to get an idea of 
> what I mean here. 

OK.  I'm reading the readme.  First off, congratulations, you're dodging a 
lot of the bullets that C++ didn't.  

Here's a question.  Consider the following code:

generic one = | int => 1 | float => 1.0

generic two = | int => 2 | float => 2.0

generic plus = | int -> int -> int = (+)
               | float -> float -> float = (+.)

plus one two;;

What's the result?  Is it the int 3, or the float 3.0?

Another problem already arises with the generic (aka overloaded)  
comparisons- you oftentimes need to arbitrarily specify types in order to
replace the expensive call to the generic compare with a much cheaper
inlined type-specific compare.  If you start having to specify types a lot 
more often, that reduces the advantage of having type inference.

> New operators are not sufficient, and SML is more powerful in it's ability to 
> define new operators than OCaml (minus CamlP4) is. 

Yeah- I'd like to be able to define accessor operators somehow.  Say being
able to define $[ ] as hashtbl lookups, so that h$[3] ==> Hashtbl.find h
3.

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] Why are arithmetic functions not polymorph?

[brogoff]

On Fri, 23 May 2003, Brian Hurt wrote:
> On Fri, 23 May 2003 brogoff@speakeasy.net wrote:
> OK.  I'm reading the readme.  First off, congratulations, you're dodging a 
> lot of the bullets that C++ didn't.  
> 
> Here's a question.  Consider the following code:
> 
> generic one = | int => 1 | float => 1.0
> 
> generic two = | int => 2 | float => 2.0
> 
> generic plus = | int -> int -> int = (+)
>                | float -> float -> float = (+.)
> 
> plus one two;;
> 
> What's the result?  Is it the int 3, or the float 3.0?

Syntax error ;-)

Fixing that, the int 3. Like pattern matching, if the first matches, 
that wins. If you reorder, you can make it return float. 

> Another problem already arises with the generic (aka overloaded)  
> comparisons- you oftentimes need to arbitrarily specify types in order to
> replace the expensive call to the generic compare with a much cheaper
> inlined type-specific compare.  If you start having to specify types a lot 
> more often, that reduces the advantage of having type inference.

I don't see that as too much of  a problem, but maybe with more experience 
my opinion will change. 

> > New operators are not sufficient, and SML is more powerful in it's ability to 
> > define new operators than OCaml (minus CamlP4) is. 
> 
> Yeah- I'd like to be able to define accessor operators somehow.  Say being
> able to define $[ ] as hashtbl lookups, so that h$[3] ==> Hashtbl.find h
> 3.

Pierre Weis alluded to this desire in an ealier discussion of generics.

-- 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] Why are arithmetic functions not polymorph?

[John Max Skaller]

brogoff@speakeasy.net wrote:

> I actually think overloading can be *really* *really* good. The problem, or 
> rather, one of the many problems, with C++ IMO is that it has overloading and 
> implicit conversions of types. That's a bad combination. 
> 
> One nice thing about GCaml is that it shouldn't bother people like you who 
> dislike overloading. The overloading is fairly explicit and closed world. 

In Felix I took the opposite approach. First, overloading
requires an exact match, and there are no implicit conversions,
so it's fairly easy to decide which overload with a closed
type is selected.

Second, unlike C++, and totally opposite to GCaml,
functions are looked up by (name,signature) which means
a function with the wrong signature doesn't hide
one further up scope. In C++ the overload
set is always in the same scope, since lookup is by name,
then tries for a match. (This tends to force all templates and 
overloadable entities into the top level scope).
GCaml requires you to package
up all the overloads in one place. So you might say:

	GCaml - explicitly constructed closed world
	C++ - implicitly constructed partially closed
	Felix - implicitly constructed fully open

Third, Felix follows the C++ rules for matching
polymorphic overloads. Matches on explicit type arguments
are done by counting the number of arguments.
For implicit arguments, all candidates whose signatures
unify with the call signature are collected, and then
the most specific one (if unique) is chosen (even if there
is a closer more general overload).

The open-ness of the Felix model does make for some
degree of fragility compared to the much more robust
GCaml model, however the GCaml technique is considerably
more verbose, and brevity and easy of naming is one of
the arguments in favour of overloading.

-- 
John Max Skaller, mailto:skaller@ozemail.com.au
snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850


-------------------
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] Why are arithmetic functions not polymorph?

[Oleg Trott]

On Monday 02 June 2003 11:42 pm, John Max Skaller wrote:
> The open-ness of the Felix model does make for some
> degree of fragility compared to the much more robust
> GCaml model, however the GCaml technique is considerably
> more verbose, and brevity and easy of naming is one of
> the arguments in favour of overloading.

However, you have to sacrifice some of the type inferencing in Felix, right?

-- 
Oleg Trott <oleg_trott@columbia.edu>

-------------------
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] Why are arithmetic functions not polymorph?

[John Max Skaller]

Oleg Trott wrote:

> On Monday 02 June 2003 11:42 pm, John Max Skaller wrote:
> 
>>The open-ness of the Felix model does make for some
>>degree of fragility compared to the much more robust
>>GCaml model, however the GCaml technique is considerably
>>more verbose, and brevity and easy of naming is one of
>>the arguments in favour of overloading.
>>
> 
> However, you have to sacrifice some of the type inferencing in Felix, right?


Yes. I mainly do bottom up 

inference, which i would call deduction or synthesis.

[Typing pattern variables is slightly different]

-- 
John Max Skaller, mailto:skaller@ozemail.com.au
snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850


-------------------
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] Why are arithmetic functions not polymorph?

[John Max Skaller]

Brian Hurt wrote:

> I don't want to turn this into a C++ 
> flamefest (had one of those already this week), but in my experience 
> operator overloading is *really* *really* bad.

Not doubt because you had to work on someone else's
stupid code.

There is a clear an obvious need for overloading
aritmetic operators in Ocaml, now it has a reasonably
rich set of arithmetic types (including Big_int etc).
Another needed overload is 'print' (to print some
representation of a value which might be used in
a diagnostic).

There are fairly obvious rules about not
*overusing* a facility. C++ programmers, alas,
are prone to stretching the meager technology
available to them to the limit. One comment I read
on Slash.dot (or was it Freshmeat) about Ocaml
was who ugly it was to write

		print_endline (string_of_int i)

compared to
		cout << i << endl;

To be truthful such longwindedness often
obscures my program logic: the case they make
isn't really sound, but it is not entirely stupid either.

Of course, there is a distinction between
convenience (+ for all arithmetic types),
and dependence (dependent name lookup in templates).
The later is an abuse the *forces* complex overloads
to be defined (so that templates work).

-- 
John Max Skaller, mailto:skaller@ozemail.com.au
snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850


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

easy print and read (was: [Caml-list] Why are arithmetic functions not polymorph?)

[Oleg Trott]

On Monday 02 June 2003 11:25 pm, John Max Skaller wrote:
> Another needed overload is 'print' (to print some
> representation of a value which might be used in
> a diagnostic).

I don't think simple overloading will solve the print/read issue to my 
personal satisfaction. In G'Caml, one will still have to define these 
functions by hand, right? As someone said, "I object to doing what computers 
can do".

-- 
Oleg Trott <oleg_trott@columbia.edu>


-------------------
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: easy print and read (was: [Caml-list] Why are arithmetic functions not polymorph?)

[Pierre Weis]

Hi Oleg,

> On Monday 02 June 2003 11:25 pm, John Max Skaller wrote:
> > Another needed overload is 'print' (to print some
> > representation of a value which might be used in
> > a diagnostic).
> 
> I don't think simple overloading will solve the print/read issue to my 
> personal satisfaction. In G'Caml, one will still have to define these 
> functions by hand, right? As someone said, "I object to doing what computers 
> can do".

You're right: simple overloading cannot solve the print/read issue.

You're wrong: in G'Caml, one will not have to define these functions
by hand.

The reason is that, in G'Caml, the underlying theory is not
overloading (neither simple or complex overloading); it is a new
polymorphic typing discipline that supports the definition of a truely
polymorphic print primitive (while maintaining the safety of a
strongly typed discipline). This primitive will not be user's defined
but would have the same ``magic'' status as a lot of other basic
primitives in Pervasives, such as ( + ), open_in, print_string, or ( =
). The read primitive will have the same status.

Interestingly enough, the extensional polymorphism will allow user's
defined extensions of the print primitive to fit specific treatments
for the data types of interest in the program.

The Extensional polymorphism has been described in a 1995 POPL article
(see [1]). I connot resist to cite its abstract since it strangely
seems to be an anticipated answer to the issue you are pointing out
today:

       We present the extensional polymorphism framework, a new kind of
   polymorphism for functions defined inductively on types. As parametric
   polymorphic functions discriminate their argument via structural
   pattern matching on values, extensionally polymorphic functions
   discriminate their argument via structural pattern matching on types.

       Extensional polymorphism is fully compatible with parametric
   polymorphism, and provides a clean way to handle primitives such as
   equality and input and output functions. In particular, our type
   system supports a polymorphic printing procedure that prints any value
   in any context.

       We give a type reconstruction algorithm for extensional
   polymorphism and a translation scheme to a language with run-time
   types. The formalism allows the definition of generic functions as a
   set of clauses, each clause associating an expression to a possible
   type of the function. This leads to a powerful overloading scheme. We
   define a large class of generic functions for which strong typing is
   decidable: a static verification algorithm checks that every generic
   function is called on a type for which it is defined. In addition, we
   prove that this checking problem for unrestricted generic functions is
   undecidable.

Since 1995, we continued to work on this; in particular Jun Furuse
wrote his thesis on the Extensional Polymorphism. He also wrote the
G'Caml extension of Caml as a proof of concept for further integration
into the main stream compiler.

All this hard work needed a long time to mature (1995 -> 2003!) and is
now in a stable and satisfying state. So please, be kind enough to
read our papers and try the system, before stating definitive (and
maybe not so well argued) opinions such has ``overloading is
dangerous'' (or worse ``overloading is useless''), G'Caml cannot solve
polymorphic printing and reading, or even ``generic functions in
G'Caml are too weak and not extensible enough''. I'm sure you would be
astonished by the additive power G'Caml could bring into Caml;
consider also that all that new features is brought to you without
sacrificing the good old strongly typed discipline and static type
inference facility that we all love so much in Caml. I would like you
to be convinced it is worth supporting the experimental introduction of
these marvels into the language!

Best regards,
-- 
Pierre Weis

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

Bibliography and further readings:
==================================

In addition to a working implementation and integration into a Caml
compiler, the G'Caml system features a lot of enhancements and new
results about the extensional type system.

In particular, the print/read problem has been covered by a detailed
paper [4] (in french) that goes way further by introducing and
discussing value I/Os and their implementation within the extensional
framework. The definition and typechecking of generic functions is
covered by Jun's paper [3].

G'Caml and new results about the type system are described in long into Jun
Furuse's PHD thesis [2].

References:

[1] Extensional polymorphism (POPL 1995)
    ftp://ftp.inria.fr/INRIA/Projects/cristal/Francois.Rouaix/generics.dvi.Z
[2] Extensional polymorphism: Theory and Application
    http://pauillac.inria.fr/~furuse/thesis/
[3] Generic polymorphism in ML
    http://pauillac.inria.fr/~furuse/publications/jfla2001.ps.gz
[4] Entree/Sorties de valeurs en Caml (in french)
    http://pauillac.inria.fr/~furuse/publications/jfla2000.ps.gz

-------------------
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: easy print and read (was: [Caml-list] Why are arithmetic functions not polymorph?)

[brogoff]

On Fri, 6 Jun 2003, Pierre Weis wrote:
[... snipped lots of good stuff I enthusiastically agree with ...]
> Bibliography and further readings:
> ==================================

Let me add that if you don't want to read lots of type theory papers even if 
it's good for you, that the GCaml implementation README at 

	http://cristal.inria.fr/~furuse/generics/README.gcaml

takes you on a quick walk through what you can do, and it's pretty cool. 

I'm really looking forward to the next version, which will hopefully include 
modules. I also wonder about how the object system will fit in with all of 
this. The interaction of generics with all of this "non-core" ML is still 
a mystery to us anxious users :-)

BTW, someone (Brian Hurt?) brought up a nice simple example of where the 
current generic polymorphism seems a bit weak

generic one = | int => 1 | float => 1.0 ;;
generic two = | int => 2 | float => 2.0 ;;
generic plus = | float -> float -> float => (+.) | int -> int -> int => (+);;

plus one two;; (* Can't determine plus without at least one type annotation *)

and it would be nice if in such situations the correct plus could be inferred. 

This is very exciting stuff! Beyond overloading, this system provides a type 
safe value IO and dynamic typing capabilities. 

-- 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: easy print and read (was: [Caml-list] Why are arithmetic functions not polymorph?)

[Stefano Zacchiroli]

On Fri, Jun 06, 2003 at 09:40:16AM -0700, brogoff@speakeasy.net wrote:
> BTW, someone (Brian Hurt?) brought up a nice simple example of where the 
> current generic polymorphism seems a bit weak
> 
> generic one = | int => 1 | float => 1.0 ;;
> generic two = | int => 2 | float => 2.0 ;;
> generic plus = | float -> float -> float => (+.) | int -> int -> int => (+);;
> 
> plus one two;; (* Can't determine plus without at least one type annotation *)
> 
> and it would be nice if in such situations the correct plus could be inferred. 

I haven't tried GCaml, I've just read the README you pointed out and it
seems to address your issue:

  How about "plus one one"? There are two possibilities: adding integer
  1's or float 1.0's? In such ambiguous situation, the type inference
  algorithm takes the first one defined as defaults: plus one one is
  typed as (plus : int -> int -> int) (one : int) (one : int)

I don't think that "plus one two" is typed differently ...

Cheers.

-- 
Stefano Zacchiroli  --  Master in Computer Science @ Uni. Bologna, Italy
zack@{cs.unibo.it,debian.org,bononia.it}  -  http://www.bononia.it/zack/
"  I know you believe you understood what you think I said, but I am not
sure you realize that what you heard is not what I meant!  " -- G.Romney

-------------------
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: easy print and read (was: [Caml-list] Why are arithmetic functions not polymorph?)

[Jun.Furuse]

Hello,

> BTW, someone (Brian Hurt?) brought up a nice simple example of where the 
> current generic polymorphism seems a bit weak
> 
> generic one = | int => 1 | float => 1.0 ;;
> generic two = | int => 2 | float => 2.0 ;;
> generic plus = | float -> float -> float => (+.) | int -> int -> int => (+);;
> 
> plus one two;; (* Can't determine plus without at least one type annotation *)
> 
> and it would be nice if in such situations the correct plus could be inferred. 

Yes, in this case, it is easy to tell that there is only one
applicable typing for plus one two, that is plus : float -> float -> float.
But in general, nubmer of type case combinations may increase quite
easily and searching applicable typing from them becomes quite inefficient.
Moreover, when we have recursive generic values, the search space may
be infinite! Therefore, we must restrict the search space of type case
combinations in some manner (otherwise, typing may never terminates). 

The restriciton in the G'Caml implementation is quite simple, 
therefore you may feel some inconvenience: the type of plus one two 
is not inferred automatically, for example.
 
--
Jun

-------------------
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: easy print and read (was: [Caml-list] Why are arithmetic functions not polymorph?)

[brogoff]

On Sat, 7 Jun 2003, Jun.Furuse@inria.fr wrote:
> Yes, in this case, it is easy to tell that there is only one
> applicable typing for plus one two, that is plus : float -> float -> float.
> But in general, nubmer of type case combinations may increase quite
> easily and searching applicable typing from them becomes quite inefficient.
> Moreover, when we have recursive generic values, the search space may
> be infinite! Therefore, we must restrict the search space of type case
> combinations in some manner (otherwise, typing may never terminates). 
> 
> The restriciton in the G'Caml implementation is quite simple, 
> therefore you may feel some inconvenience: the type of plus one two 
> is not inferred automatically, for example.

Hi,
    I understand the pragmatics. If it turns out that this is painful in 
practice for cases like linear algebra or numerics libraries where the 
generic values are not recursive, I hope that a less restrictive rule can be 
adopted. I don't think that the hacks used by other languages which have 
types which throw the type checker into a loop (setting some iteration limit) 
are so bad, and I think they can be applied here. 

    Right now we don't have any significant practice to go on, so I think the 
conservative rule is OK, since, as you point out, it is simple. It's a bit 
weird that the example I posted works if the order is switched in the 
declaration of "plus". 

-- 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: easy print and read (was: [Caml-list] Why are arithmetic functions not polymorph?)

[Chris Hecker]

At 12:46 PM 6/6/2003 +0200, Pierre Weis wrote:
>All this hard work needed a long time to mature (1995 -> 2003!) and is
>now in a stable and satisfying state.

This is great.  My concern about generics in ocaml is one of efficiency.  I 
read the paper (as much as I could understand), and the flow array stuff 
seems smart and better than type pattern matching in the case where you 
don't know the definition of the generic function at the call point, but is 
there going to be inlining with generics as well in this initial 
implementation?  In other words, if I want to define (+) for ints and 
floats, and I statically know the type at the point of call, will the 
compiler inline the add_int or add_float appropriately and do no runtime 
checks (or flow array traversals)?  For generics to be really useful for 
fine grained math operations (one of the better applications of overloading 
(especially in ocaml since the op. thing is so ugly), in my opinion) I 
think this is going to be necessary.

Chris


-------------------
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: easy print and read (was: [Caml-list] Why are arithmetic functions not polymorph?)

[Jun.Furuse]

Hello,

At Sun, 08 Jun 2003 01:49:21 -0700,
Chris Hecker wrote:
> 
> >All this hard work needed a long time to mature (1995 -> 2003!) and is
> >now in a stable and satisfying state.
> 
> This is great.  My concern about generics in ocaml is one of efficiency.  I 
> read the paper (as much as I could understand), and the flow array stuff 
> seems smart and better than type pattern matching in the case where you 
> don't know the definition of the generic function at the call point, but is 
> there going to be inlining with generics as well in this initial 
> implementation? 

This is one of the TODO items of G'Caml. 
You can hope that inlining of very simple generic values such as plus
will be available in near future, (but not in the next release, sorry.)
The inlining will occur only when:

  * The type of a generic value instance is statically known.
  * The corresponding overloaded definition is an identifier, such as
	(+) and (+.)

Inlining more complex generic values such as double 
(let double x = plus x x) will be another story...

--
Jun

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