[Caml-list] subtyping, polymorphism, higher order types.....

[Caml-list] subtyping, polymorphism, higher order types.....

[Shaddin Doghmi]

In my experiences with ocaml, one of the major frustrations i constantly
run into is the lack of subtyping. Polymorphic variants partially fix
that problem, by allowing one to define types as immediate unions (i.e.
without constructors) of other types, hence allowing a value to belong
to both the subtype and the supertype, not to mention multiple unrelated
types.

However, there is still the issue of defining stuff such as "equality
types", "comparables", and such, allowing overloading of functions on
those. For example, when writing a large system with many datatypes, i
tend to find myself commenting each type definition with stuff like
"(*equality type*)",  to indicate to myself whether or not im allowed to
use the default = operator on that type(for example, a set type would
not get that annotation).  Haskell solves that problem through the use
of type classes.

Another problem i run into is the inability to define parametric higher
order polymorphic types (is this the correct terminology?).. for
example. lets say i want to define the following type:

type 'a identifier = I of 'a *int | S of 'a*int

but, what if i want to restrict 'a to a narrower class of types (as
opposed to ad hoc types)... i would wish to say something like:

type 'identifiable identifier = I of 'a*int | S of 'a*int

where 'identifiable is a type class of some sort. I am not sure if
Haskell solves this problem using type classes(seems like it could),
Someone experienced in Haskell would probably know.

I wonder if there are any plans to implement such a system in ocaml? if
so, what approach would be taken?

just a few thoughts.....



-------------------
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] subtyping, polymorphism, higher order types.....

[brogoff]

On Thu, 3 Jul 2003, Shaddin Doghmi wrote:
> In my experiences with ocaml, one of the major frustrations i constantly
> run into is the lack of subtyping.

I don't find that a frustration, but you may have been doing OO for a long 
time. I tend to prefer non OO approaches now. 

> However, there is still the issue of defining stuff such as "equality
> types", "comparables", and such, allowing overloading of functions on
> those. 

You'll be interested in G'Caml

	http://cristal.inria.fr/~furuse/generics/index.html

which will be updated after the release of 3.07. 

> For example, when writing a large system with many datatypes, i
> tend to find myself commenting each type definition with stuff like
> "(*equality type*)",  to indicate to myself whether or not im allowed to
> use the default = operator on that type(for example, a set type would
> not get that annotation). 

You're always allowed to use default equality (inequality, comparison, hashing) 
so you may want to adopt a coding style that by default uses a module specific 
comparison. 

> Another problem i run into is the inability to define parametric higher
> order polymorphic types (is this the correct terminology?).. for
> example. lets say i want to define the following type:
> 
> type 'a identifier = I of 'a *int | S of 'a*int
> 
> but, what if i want to restrict 'a to a narrower class of types (as
> opposed to ad hoc types)... i would wish to say something like:
> 
> type 'identifiable identifier = I of 'a*int | S of 'a*int
> 
> where 'identifiable is a type class of some sort. I am not sure if
> Haskell solves this problem using type classes(seems like it could),
> Someone experienced in Haskell would probably know.

The workaround for higher-order type constructors is described here 

http://caml.inria.fr/archives/200302/msg00021.html

and a very simple modification of this idea (think module type Identifiable) 
gets pretty close to what I think you want. 

-- 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] subtyping, polymorphism, higher order types.....

[Daniel Weil]

I've spent these last week some time reading stuff on type classes and
Hashkell and I was going to raise the same question :
Is it possible to implement Type Classes (in the Haskell way) over 
Ocaml, at least over CamlLight ?

Type classes (which are not object classes) solve in a very elegant way 
the problem of overloading (especially for arythmetic operators). I'm 
not sure to have understood precisely what G'Caml does but I don't think 
G'Caml solve this problem.



Shaddin Doghmi wrote:

> In my experiences with ocaml, one of the major frustrations i constantly
> run into is the lack of subtyping. Polymorphic variants partially fix
> that problem, by allowing one to define types as immediate unions (i.e.
> without constructors) of other types, hence allowing a value to belong
> to both the subtype and the supertype, not to mention multiple unrelated
> types.
>
> However, there is still the issue of defining stuff such as "equality
> types", "comparables", and such, allowing overloading of functions on
> those. For example, when writing a large system with many datatypes, i
> tend to find myself commenting each type definition with stuff like
> "(*equality type*)",  to indicate to myself whether or not im allowed to
> use the default = operator on that type(for example, a set type would
> not get that annotation).  Haskell solves that problem through the use
> of type classes.
>
> Another problem i run into is the inability to define parametric higher
> order polymorphic types (is this the correct terminology?).. for
> example. lets say i want to define the following type:
>
> type 'a identifier = I of 'a *int | S of 'a*int
>
> but, what if i want to restrict 'a to a narrower class of types (as
> opposed to ad hoc types)... i would wish to say something like:
>
> type 'identifiable identifier = I of 'a*int | S of 'a*int
>
> where 'identifiable is a type class of some sort. I am not sure if
> Haskell solves this problem using type classes(seems like it could),
> Someone experienced in Haskell would probably know.
>
> I wonder if there are any plans to implement such a system in ocaml? if
> so, what approach would be taken?
>
> just a few thoughts.....
>
>
>
> -------------------
> 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
>


-- 
*********************************************************************
* Daniel Weil                                                       *
* ATHYS                                                             *
* NOVESPACE Bâtiment B - 100 allée St Exupéry - 38330 Montbonnot    *
* Tel 33 (0)4 56 38 04 12 Fax 33 (0)4 56 38 04 01                   *
* daniel.weil@athys.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

Re: [Caml-list] subtyping, polymorphism, higher order types.....

[Vasile Rotaru]

On Thu, 03 Jul 2003 10:33:15 -0400
Shaddin Doghmi <shaddin@mitre.org> wrote:

> In my experiences with ocaml, one of the major frustrations i
> constantly run into is the lack of subtyping. [..]

  The Shaddin message (and other influences -- the most notable being
the Oberon language) had induced me to an idea which I offer here for
discussion. Open (or extensible) product types. Something like this

    type point = int * int * _ ;;

where the underscore stands for any sequences of types. Colour, taste,
strangeness, etc.

  Now a function designed to work with with "point" will work with any
type which is a "point" extension. Just now I cannot think of a good
"ocamlish" syntax for extending types. Maybe?

    type color_point = <point> * int * _

  The big question is what this will do with the type system of Ocaml
and whether it worth the pain..

> just a few thoughts.....
> 

just a few thoughts

Vasile Rotaru

-- 
They spell it "da Vinci" and pronounce it "da Vinchy".  Foreigners
always spell better than they pronounce.
		-- Mark Twain

-------------------
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] subtyping, polymorphism, higher order types.....

[Jacques Garrigue]

From: Vasile Rotaru <vrotaru@seznam.cz>
> On Thu, 03 Jul 2003 10:33:15 -0400
> Shaddin Doghmi <shaddin@mitre.org> wrote:
> 
> > In my experiences with ocaml, one of the major frustrations i
> > constantly run into is the lack of subtyping. [..]

You should be a bit more precise: ocaml has both explicit subtyping
(for objects), and parametric polymorphism (which is also a form of
implicit subsumption). So what it does not have is only the form of
implicit subtyping you are used to, and which is incompatible with
most forms of type inference.

>   The Shaddin message (and other influences -- the most notable being
> the Oberon language) had induced me to an idea which I offer here for
> discussion. Open (or extensible) product types. Something like this
> 
>     type point = int * int * _ ;;
> 
> where the underscore stands for any sequences of types. Colour, taste,
> strangeness, etc.
> 
>   Now a function designed to work with with "point" will work with any
> type which is a "point" extension. Just now I cannot think of a good
> "ocamlish" syntax for extending types. Maybe?
> 
>     type color_point = <point> * int * _
> 
>   The big question is what this will do with the type system of Ocaml
> and whether it worth the pain..

This looks very much like an ocaml object type to me...
Is the absence of labels for fields important?

Note that you can also encode the above with polymorphism:

  type 'a point = int * int * 'a
  type 'a color_point = (int * 'a) point

The only trouble here is that there is no way to create heterogeneous
collections, since you cannot coerce a [unit color_point] to a [unit
point]. Actually, this just comes from a missing relation in the ocaml
type algebra: the type Obj.t is not recognized as a supertype for all
types. If this were the case then you would be able to write:
  let l = [ (p :> Obj.t point); (cp :> Obj.t point) ]

That would be easy enough to add, but is it that useful?

     Jacques Garrigue

-------------------
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] subtyping, polymorphism, higher order types.....

[Fernando Alegre]

On Sat, Jul 05, 2003 at 11:21:26AM +0900, Jacques Garrigue wrote:

> This looks very much like an ocaml object type to me...
> Is the absence of labels for fields important?
> 
> Note that you can also encode the above with polymorphism:
> 
>   type 'a point = int * int * 'a
>   type 'a color_point = (int * 'a) point
> 
> The only trouble here is that there is no way to create heterogeneous
> collections, since you cannot coerce a [unit color_point] to a [unit
> point]. Actually, this just comes from a missing relation in the ocaml
> type algebra: the type Obj.t is not recognized as a supertype for all
> types. If this were the case then you would be able to write:
>   let l = [ (p :> Obj.t point); (cp :> Obj.t point) ]
> 
> That would be easy enough to add, but is it that useful?

I think yes. That would allow us to avoid creating ad-hoc classes whose only
use is such heterogeneous storage. This would save quite a few lines of
wrapping code when the basic data structure is a record or a sum type that
is extended with a problem-specific type.

Currently, the problem is not just heterogeneous collections. In our program,
a mutable variable of type 'a model can not be reused to solve one model
after another without exiting the program and restarting with a different
model, unless we wrap everything in classes. Exiting the program is really
inconvenient for interactive user interfaces, and wrapping the code adds
many unnecessary lines. So, something like Obj.t coercion would be really
useful. 

Fernando

-------------------
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] subtyping, polymorphism, higher order types.....

[Vasile Rotaru]

On Sat, 05 Jul 2003 11:21:26 +0900
Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp> wrote:

> > 
> >     type point = int * int * _ ;;
> > 
> > where the underscore stands for any sequences of types. Colour,
> > taste, strangeness, etc.
...
> 
> This looks very much like an ocaml object type to me...
> Is the absence of labels for fields important?

  Nor, it is not. The labels are not at all important. The same scheme
will work for open/extensible records. (In fact, those are the records
which are extensible in Oberon.) I have just run once the "ocamlc"
compiler with the "-dlambda" option, and I was pleasantly surprised to
see that access to components of a type is coded to something as simple
as:

	(field 0 param/57)
        (field 1 param/57)

and so on. But this means that any function which works with "point"-s
(from my previous message) will work work correctly "color_point"-s, if
it were allowed to. Correct me if I'm wrong, but the objects have a
higher overhead. Besides -- I'm subjective, of course -- this scheme has
some kind of "math appeal" to me.

  I know that there is and will always be a tradeoff between
expressiveness of a language and its complexity, so don't take that
proposal, for more than it is. Just a few thoughts. 

Vasile Rotaru

-- 
It is easy to find fault, if one has that disposition.  There was once a man
who, not being able to find any other fault with his coal, complained that
there were too many prehistoric toads in it.
		-- Mark Twain, "Pudd'nhead Wilson's Calendar"

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