Same label in different types, how do people solve this?

Same label in different types, how do people solve this?

[Mattias Waldau]

In Ocaml, you cannot have the same label in different types, see the example
below where
point_2d hides point_3d.

How do people normally code around this restriction? One solution is using
objects, but what other solutions are there? Can 'Polymorphic variants'
solve this?

Also, I am a bit curious why it doesn't help to type explicitely, i.e. to
write
let x:point_3d={x=10.;y=20.;z=30.} ???

/mattias


type point_3d = {
    x:float;
    y:float;
    z:float;
  }

type point_2d = {
    x:float;
    y:float;
  }

# {x=10.;y=20.;z=30.};;
Characters 0-19:
The record field label z belongs to the type point_3d
but is here mixed with labels of type point_2d
# {x=10.;y=20.};;
- : point_2d = {x=10.000000; y=20.000000}

Re: Same label in different types, how do people solve this?

[John Max Skaller]

Mattias Waldau wrote:
> 
> In Ocaml, you cannot have the same label in different types, see the example
> below where
> point_2d hides point_3d.
> 
> How do people normally code around this restriction? 

	Use distinct names :-)
The 'correct' solution is a bit messy: use modules.

> Also, I am a bit curious why it doesn't help to type explicitely, i.e. to
> write
> let x:point_3d={x=10.;y=20.;z=30.} ???

 	The RHS is typed without examining the type constraint on the LHS,
then the constraint is checked. As in:

	let f (x : int) : int = "Hello"

The type of f is first infered as 'a -> string, as if it had been
written

	let f x = "Hello"

then this type is unified with the declared type constraint. In your
example,
the type is infered to be point_2d, since you declared that second, and
the 
field name 'x' is associated with this type: the previous binding
of x to (a field of the) type point_2d is hidden.
 
For your example try:

module D3 = struct
 type point = {
     x:float;
     y:float;
     z:float;
   }
end
module D2 = struct
 type point = {
     x:float;
     y:float;
   }
end
;;

{D3.x=10.;D3.y=20.;D3.z=30.};;

The 'field names' escape out of the type like a C enumeration,
to allow type inference to deduce the type of a record literal.

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net

Re: Same label in different types, how do people solve this?

[Maxence Guesdon]

Mattias Waldau a écrit :
> 
> In Ocaml, you cannot have the same label in different types, see the example
> below where
> point_2d hides point_3d.
> 
> How do people normally code around this restriction? One solution is using
> objects, but what other solutions are there? Can 'Polymorphic variants'
> solve this?

In your example, and without objects, I would have chosen explicit names
for labels, i.e. :

type point_3d = {
     p3d_x:float;
     p3d_y:float;
     p3d_z:float;
   }
 
type point_2d = {
     p2d_x:float;
     p2d_y:float;
   }

It sure is kind of a pain to write, but it is much more easy to
understand when you read it. With
explicit labels, you "see" the type of toto in toto.p3d_x. I think not
allowing to have the same label
in different types is a great way to force developers to write cleaner
code ;-)


----------------------
Maxence Guesdon
http://maxence.guesdon.free.fr

Re: Same label in different types, how do people solve this?

[Gerd Stolpmann]

On Wed, 06 Dec 2000, Mattias Waldau wrote:
>In Ocaml, you cannot have the same label in different types, see the example
>below where
>point_2d hides point_3d.
>
>How do people normally code around this restriction? One solution is using
>objects, but what other solutions are there? Can 'Polymorphic variants'
>solve this?

The simplest way is to use different labels. 

Another solution is to wrap the type definition into modules:

module P3d = struct
type point_3d = {
    x:float;
    y:float;
    z:float;
  }
end

module P2d = struct
type point_2d = {
    x:float;
    y:float;
  }
end

Now you can prefix the labels with the module identifiers:

{ P3d.x = 10.; P3d.y = 20.; P3d.z = 30. }, or
{ P2d.x = 10.; P2d.y = 20.}

You can open the module whose type is used more frequently:

open P2d
{ x = 10.; y = 20.; }

Polymorphic variants are union types and not product types, so they do not help
very much.

Gerd
-- 
----------------------------------------------------------------------------
Gerd Stolpmann      Telefon: +49 6151 997705 (privat)
Viktoriastr. 100             
64293 Darmstadt     EMail:   gerd@gerd-stolpmann.de
Germany                     
----------------------------------------------------------------------------

Re: Same label in different types, how do people solve this?

[Jacques Garrigue]

From: "Mattias Waldau" <mattias.waldau@abc.se>

> In Ocaml, you cannot have the same label in different types, see the example
> below where
> point_2d hides point_3d.
> 
> How do people normally code around this restriction? One solution is using
> objects, but what other solutions are there? Can 'Polymorphic variants'
> solve this?

There are various ways. The most common is to differentiate label
names (i.e. use x_3d and x_2d instead of x). Another more subtle one
is to put the definitions in deifferent modules (Point2d and Point3d)
so that you can specify exactly which label you want (Point2d.x or
Point3d.x).

The last solution might be nicer if we had a
    let open Module in
construct (would require 10 lines in the compiler)

Polymorphic variants cannot help, but if you do not care about
efficiency you can use objects:

class point_3d ~x ~y ~z = object
  method x : float = x
  method y : float = y
  method z : float = z
end

class point_2d ~x ~y = object
  method x : float = x
  method y : float = y
end

Note that objects provide you more than overloading: you can define
truly polymorphic functions, working on both point_3d and point_2d,
and you can even coerce a point_3d to a point_2d.

> Also, I am a bit curious why it doesn't help to type explicitely, i.e. to
> write
> let x:point_3d={x=10.;y=20.;z=30.} ???

Because this is not the way it works. Labels are defined as are values
or constructors, this is only afterwards that the compiler checks that
they all belong to the same type. That is, the type cannot influence the
choice between x(point_3d) and x(point_2d), only the order of
definition can.

There has been already various proposals for allowing types to be taken
into account when typing record labels. The difficulty is that as soon
as you make it into something useful, you loose the principal type
property, and that some theoreticians working on ocaml wouldn't like
it.

A very restrictive approach would still work: use type annotations,
but only when they are directly on the creation/access/modification
construct.

That is
     ({x=1.;y=1.;z=1.}:point_3d)
     let p : point_3d = {x=1.;y=1.;z=1.}
     (p : point_3d).x
     {p : point_3d with x = 2.}

Here, there is no ambiguity at all. But this is very weak:

     let p : point_3d = {x=1.;y=1.;z=1.} in p.x +. p.y +. p.z

would still be illegal...

Jacques
---------------------------------------------------------------------------
Jacques Garrigue      Kyoto University     garrigue at kurims.kyoto-u.ac.jp
		<A HREF=http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/>JG</A>

Re: Same label in different types, how do people solve this?

[Sven LUTHER]

On Fri, Dec 08, 2000 at 10:22:29AM +0900, Jacques Garrigue wrote:
> From: "Mattias Waldau" <mattias.waldau@abc.se>
> 
> > In Ocaml, you cannot have the same label in different types, see the example
> > below where
> > point_2d hides point_3d.
> > 
> > How do people normally code around this restriction? One solution is using
> > objects, but what other solutions are there? Can 'Polymorphic variants'
> > solve this?
> 
> There are various ways. The most common is to differentiate label
> names (i.e. use x_3d and x_2d instead of x). Another more subtle one
> is to put the definitions in deifferent modules (Point2d and Point3d)
> so that you can specify exactly which label you want (Point2d.x or
> Point3d.x).
> 
> The last solution might be nicer if we had a
>     let open Module in
> construct (would require 10 lines in the compiler)

Is this not already possible ? i read about something similar in the docs
somewhere ...

Another idea would be to add some construct to use something like :

type p3d = { x:float;y:float;z:float }
type p2d = { x:float;y:float }

and then be able to do :

{p3d.x=10.;p3d.y=20.;p3d.z=30.}

and 

{p2d.x=0; p2d.y=5}

Would this be difficult to do ?

Friendly,

Sven Luther

Re: Same label in different types, how do people solve this?

[Pierre Weis]

> Another idea would be to add some construct to use something like :
> 
> type p3d = { x:float;y:float;z:float }
> type p2d = { x:float;y:float }
> 
> and then be able to do :
> 
> {p3d.x=10.;p3d.y=20.;p3d.z=30.}
> 
> and 
> 
> {p2d.x=0; p2d.y=5}
> 
> Would this be difficult to do ?

You will have ambiguities in accessing records: what means r.y.z ?  Is
it access to field z of type y of r, or access to field z of access to
field y of r ?

I would suggest another syntactic notation to specify the type to
which a label belongs: label@@type.

{x@@p2d = 0; y = 5}
r.x@@p2d

Best regards,

Pierre Weis

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

Re: Same label in different types, how do people solve this?

[Nicolas barnier]

Sven LUTHER wrote:
>
> > The last solution might be nicer if we had a
> >     let open Module in
> > construct (would require 10 lines in the compiler)
> 
> Is this not already possible ? i read about something similar in the docs
> somewhere ...

I'm afraid not. But you can define local modules as a language extension:

7.6   Local modules

The expression let module module-name = module-expr in expr locally binds the
module expression module-expr to the identifier module-name during the evaluation
of the expression expr. It then returns the value of expr.

-- Nicolas

Re: Same label in different types, how do people solve this?

[Sven LUTHER]

On Fri, Dec 08, 2000 at 10:36:44AM +0100, Pierre Weis wrote:
> > Another idea would be to add some construct to use something like :
> > 
> > type p3d = { x:float;y:float;z:float }
> > type p2d = { x:float;y:float }
> > 
> > and then be able to do :
> > 
> > {p3d.x=10.;p3d.y=20.;p3d.z=30.}
> > 
> > and 
> > 
> > {p2d.x=0; p2d.y=5}
> > 
> > Would this be difficult to do ?
> 
> You will have ambiguities in accessing records: what means r.y.z ?  Is
> it access to field z of type y of r, or access to field z of access to
> field y of r ?
> 
> I would suggest another syntactic notation to specify the type to
> which a label belongs: label@@type.
> 
> {x@@p2d = 0; y = 5}
> r.x@@p2d

Yes, didn't think about it, but that would be best.

(too bad there is not a third kind of case to do the same kind of trick that
is done with modules ...)

Friendly,

Sven Luther

Re: Same label in different types, how do people solve this?

[Brian Rogoff]

Mattias Waldau wrote : 
> In Ocaml, you cannot have the same label in different types, see the
example
> below where point_2d hides point_3d.

Troublemaker :-). There is a thread on this topic on comp.lang.functional. 
Please, FAQ maintainer, this is very definitely FAQ material!

> Also, I am a bit curious why it doesn't help to type explicitely,
i.e. to
> write let x:point_3d={x=10.;y=20.;z=30.} ???

John Skaller and Jacques Garrigue answered this.

Maxence Guesdon wrote: 

> In your example, and without objects, I would have chosen explicit names
> for labels, i.e. :
> 
> type point_3d = {
>      p3d_x:float;
>      p3d_y:float;
>      p3d_z:float;
>    }
>  
> type point_2d = {
>      p2d_x:float;
>      p2d_y:float;
>    }
> 
> It sure is kind of a pain to write, but it is much more easy to
> understand when you read it. With

I very strongly disagree. If I didn't disagree, I'd probably also prefer
to annotate all of my functions in place with their types. Same principle, a
pain to write but somewhat easier to read. I don't agree with the principle
that more annotations means easier readability, and I've written a fair enough 
amount of Ada to believe that my opinion is not without some merit. I think 
annotating each field is way too verbose, even for the reader. My opinion
of course, feel free to differ. 

I do agree with the general Ada principle that you shouldn't be concerned 
with the writer of the code, but with the reader/maintainer. I guess one 
counterargument though is that code which is never written won't be
maintained anyways ;-).

Jacques Garrigue wrote:
> There are various ways. The most common is to differentiate label
> names (i.e. use x_3d and x_2d instead of x). Another more subtle one
> is to put the definitions in deifferent modules (Point2d and Point3d)
> so that you can specify exactly which label you want (Point2d.x or
> Point3d.x).

I prefer the module solution. 

> The last solution might be nicer if we had a
>     let open Module in
> construct (would require 10 lines in the compiler)

Yes, I would like something like this! There is a workaround, in which you
can use a local module and do your "open" in that. 

let module Top = struct open Module let f () = ... end in Top.f () 

but I think a cleaner syntax might be nice and I'm reluctant to use P4 in 
work projects until its status is clearer.

For this problem, you're still hosed if you want to use 2d and 3d points
in the same module, and don't want distinct labels. 

> Polymorphic variants cannot help, but if you do not care about
> efficiency you can use objects:

Maybe the efficient compilation of OO code deserves more attention,
especially for this case where we use classes just to get polymorphic
records. 

> > Also, I am a bit curious why it doesn't help to type explicitely,
i.e. to
> > write
> > let x:point_3d={x=10.;y=20.;z=30.} ???

> A very restrictive approach would still work: use type annotations,
> but only when they are directly on the creation/access/modification
> construct.
> 
> That is
>      ({x=1.;y=1.;z=1.}:point_3d)
>      let p : point_3d = {x=1.;y=1.;z=1.}
>      (p : point_3d).x
>      {p : point_3d with x = 2.}
>
> Here, there is no ambiguity at all. But this is very weak:
> 
>      let p : point_3d = {x=1.;y=1.;z=1.} in p.x +. p.y +. p.z
> 
> would still be illegal...

Yes, still pretty weak. My gut feeling is that putting the records in
separate modules and having a local open construct would be better, if
developers are dead set on preserving the principal type property. But,
maybe in combination with the local open this is "good enough"?

Pierre Weis wrote
> I would suggest another syntactic notation to specify the type to
> which a label belongs: label@@type.
> 
> {x@@p2d = 0; y = 5}
> r.x@@p2d

I don't want to start a syntax war, but I think Ocaml is already suffering
a bit from too much added syntax and this doesn't look good to me. Jacques' 
reuse of ":" (I know, it applies to the whole record and not a label) is 
easier on my eyes, which already associate ":" with typing. 

-- Brian

Re: Same label in different types, how do people solve this?

[John Max Skaller]

Pierre Weis wrote:

> I would suggest another syntactic notation to specify the type to
> which a label belongs: label@@type.
> 
> {x@@p2d = 0; y = 5}
> r.x@@p2d

	This is logical .. but do we really need another operator?
The syntax is bloating beyond C++ :-)

	If some kind of overloading is being considered,
couldn't it apply to record labels too? I guess you'd have to use
a let/type .. and construction:

	let f x = x + x 
	and f x = x +. x
	in f 1, f 1.0

	type p2 = { x : int; y : int }
	and p3 = { x : int; y : int; z : int };;
	{ x=1; y = 2 };;

It seems unprincipled that the first case reports an error,
but in the second, the second 'x' hides the first.

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net

RE: Same label in different types, how do people solve this?

[Mattias Waldau]

Thanks for all the answers! Obviously this question including the
suggestions should be in the FAQ.

I understand that all you functional experts thinks this restriction is
obvious, but for me it is more like a bug/misfeature. So this 'misfeature'
should actually be stated for all us who aren't interested how types are
infered in functional programming.

I actually thought there was a simple work-around, but there isn't.

/mattias

Re: Same label in different types, how do people solve this?

[Pierre Weis]

> Mattias Waldau wrote : 
> > In Ocaml, you cannot have the same label in different types, see the
> example
> > below where point_2d hides point_3d.
> 
> Troublemaker :-). There is a thread on this topic on comp.lang.functional. 
> Please, FAQ maintainer, this is very definitely FAQ material!

Feel free to propose an entry for the FAQ (in english and french
please): I would be glad to add it.

[...]
> Pierre Weis wrote
> > I would suggest another syntactic notation to specify the type to
> > which a label belongs: label@@type.
> > 
> > {x@@p2d = 0; y = 5}
> > r.x@@p2d
> 
> I don't want to start a syntax war, but I think Ocaml is already suffering
> a bit from too much added syntax and this doesn't look good to me. Jacques' 
> reuse of ":" (I know, it applies to the whole record and not a label) is 
> easier on my eyes, which already associate ":" with typing. 
> 
> -- Brian

The notation I suggested is simpler to implement and specify: there is
nothing new in type constraints propagation and label overloaing
resolution strategy: just a notation to specify the type to which a
label or constructor belongs to in the same spirit as usual
qualification of names in the module system.

Pierre Weis

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

RE: Same label in different types, how do people solve this?

[Chris Hecker]

>I understand that all you functional experts thinks this restriction is
>obvious, but for me it is more like a bug/misfeature. So this 'misfeature'
>should actually be stated for all us who aren't interested how types are
>infered in functional programming.

I'm with Mattias on this one.  I'm practical above theoretical.  All of the workarounds for this problem seem like they generate way more tedious work for the programmer, and they still don't quite accomplish the goal 100%.  This characteristic of doing more work and only asymptotically approaching your goal is a bad taste I associate with C++.

Anyway, my "vote" would be to allow specification, with : if it's possible since it's the obvious syntax, but even with @@ if necessary (even though I think it's really ugly).

Chris

Re: Same label in different types, how do people solve this?

[Pierre Weis]

> >I understand that all you functional experts thinks this restriction is
> >obvious, but for me it is more like a bug/misfeature. So this 'misfeature'
> >should actually be stated for all us who aren't interested how types are
> >infered in functional programming.
> 

> I'm with Mattias on this one.  I'm practical above theoretical.  All
>of the workarounds for this problem seem like they generate way more
>tedious work for the programmer, and they still don't quite accomplish
>the goal 100%.  This characteristic of doing more work and only
>asymptotically approaching your goal is a bad taste I associate with
>C++.

> Anyway, my "vote" would be to allow specification, with : if it's
> possible since it's the obvious syntax, but even with @@ if
> necessary (even though I think it's really ugly).
> 
> Chris

I tried a lot of more attractive alternative:
 -- type::label but :: is already used for lists (consing).
 -- type@label, but @ also used (append). 
 -- type`label, but the symbol ` introduces variant
 -- type'label (as in Ada), but ' is used in identifier and chars and ...

Another available notation could be type.:label, or type.'label ...

Cheers,

PS: I added something in the FAQ about the problem of overloading of
labels, see one of (or both :)

http://pauillac.inria.fr/caml/FAQ/FAQ_EXPERT-fra.html
http://pauillac.inria.fr/caml/FAQ/FAQ_EXPERT-eng.html

Pierre Weis

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

Re: Same label in different types, how do people solve this?

[Chet Murthy]

The issue, about practicality, isn't whether you _can_ specify the
particular types and type-usages you want.  The issue is whether, if
you write a phrase, and you got it wrong, you have to know all about
the type system, in order to debug that phrase.

In SML, you have to understand the type algorithm enough to identify
when you've underspecified a type, and that can be _tricky_.

In CAML, you either got it right, or got it wrong.

That simplicity goes a long way.  And without it, well, you've got to
teach the world all the intricacies of polymorphic typing.

Not a winning strategy.

--chet--

>>>>> "CH" == Chris Hecker <checker@d6.com> writes:

    >> I understand that all you functional experts thinks this
    >> restriction is obvious, but for me it is more like a
    >> bug/misfeature. So this 'misfeature' should actually be stated
    >> for all us who aren't interested how types are infered in
    >> functional programming.

    CH> I'm with Mattias on this one.  I'm practical above
    CH> theoretical.  All of the workarounds for this problem seem
    CH> like they generate way more tedious work for the programmer,
    CH> and they still don't quite accomplish the goal 100%.  This
    CH> characteristic of doing more work and only asymptotically
    CH> approaching your goal is a bad taste I associate with C++.

    CH> Anyway, my "vote" would be to allow specification, with : if
    CH> it's possible since it's the obvious syntax, but even with @@
    CH> if necessary (even though I think it's really ugly).

Re: Same label in different types, how do people solve this?

[Sven LUTHER]

On Mon, Dec 11, 2000 at 08:17:47PM +0100, Pierre Weis wrote:
> > >I understand that all you functional experts thinks this restriction is
> > >obvious, but for me it is more like a bug/misfeature. So this 'misfeature'
> > >should actually be stated for all us who aren't interested how types are
> > >infered in functional programming.
> > 
> 
> > I'm with Mattias on this one.  I'm practical above theoretical.  All
> >of the workarounds for this problem seem like they generate way more
> >tedious work for the programmer, and they still don't quite accomplish
> >the goal 100%.  This characteristic of doing more work and only
> >asymptotically approaching your goal is a bad taste I associate with
> >C++.
> 
> > Anyway, my "vote" would be to allow specification, with : if it's
> > possible since it's the obvious syntax, but even with @@ if
> > necessary (even though I think it's really ugly).
> > 
> > Chris
> 
> I tried a lot of more attractive alternative:
>  -- type::label but :: is already used for lists (consing).
>  -- type@label, but @ also used (append). 
>  -- type`label, but the symbol ` introduces variant
>  -- type'label (as in Ada), but ' is used in identifier and chars and ...
> 
> Another available notation could be type.:label, or type.'label ...
> 
> Cheers,
> 
> PS: I added something in the FAQ about the problem of overloading of
> labels, see one of (or both :)
> 
> http://pauillac.inria.fr/caml/FAQ/FAQ_EXPERT-fra.html
> http://pauillac.inria.fr/caml/FAQ/FAQ_EXPERT-eng.html

Why not automatically produce some kind of module for every type declaration,
or at least the one that involve records and labels, but it could be usefull
also for variants.

when you type :

  type point_2d = { x:int; y:int}

it would be automatically converted to :

module Point_2d = struct
  type point_2d = { x:int; y:int}
end
open Point_2d

Then you can easily use :

let p2 = {Point_2d.x=10; Point_2d.y=10}

Sure there can be problem with module namespace conflicts, but a trick could
be found (well types are lowercases, while module are uppercases, isn't it ?)

Is there a big space or efficiency issue involved with this ?

Another idea would be to have the record cast to the correct type :

let p2 : point_2d = {x=10; y=10}
or
let p2 = {x=10; y=10} : point_2d

Or maybe this causes problems with the typer ?

Friendly,

Sven Luther

Re: Same label in different types, how do people solve this?

[John Max Skaller]

Mattias Waldau wrote:
> 
> Thanks for all the answers! Obviously this question including the
> suggestions should be in the FAQ.
> 
> I understand that all you functional experts thinks this restriction is
> obvious, but for me it is more like a bug/misfeature. So this 'misfeature'
> should actually be stated for all us who aren't interested how types are
> infered in functional programming.
> 
> I actually thought there was a simple work-around, but there isn't.

This isn't unique to 'functional' languages.
Consider:

	enum X {a,b,c};
	enum Y {a,b}; // Woops!

The C++ solution is the same as the Ocaml one: wrapping:

	struct XX { enum X {a,b,c
}; };
	struct YY { enum Y {a,b}; };

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net

Re: Same label in different types, how do people solve this?

[John Max Skaller]

Chet Murthy wrote:

> The issue, about practicality, isn't whether you _can_ specify the
> particular types and type-usages you want.  The issue is whether, if
> you write a phrase, and you got it wrong, you have to know all about
> the type system, in order to debug that phrase.

It is a tradeoff. Full inference makes code short: lack of
inference severely pollutes programming style (as in C++).
In Felix, I compromised: functions must be explicitly typed
when declared, but values don't:

	function f(a:int): int { val b = a; return b; }

f must be explicitly typed. The type of b is deduced.
Compare with

	let f a = let b = a in b;;

The explicit typing of functions avoids a need for
a full scale type inference algorithm. 

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net

Functions must be explicitly typed, (was Same label in different types, how do people solve this?)

[Mattias Waldau]

> In Felix, I compromised: functions must be explicitly typed
> when declared, but values don't:
>
>	function f(a:int): int { val b = a; return b; }

Which I think is an good idea. I normally type the functions in Ocaml, but I
don't type the local variables. Then I will get the type-error message at
the function definition and not at references to the function.

In the following example I forgot the 2nd argument to f2 in g. Now the
compiler will complain when the function g is called from h and point at h
for the error. THIS IS TOO LATE!

let f2 x y = x * y

let g x = f2 x

let h x = 2 * g x
              ^^^
This expression has type int -> int but is here used with type int


However, if I had wrote


let f2 (x:int) (y:int) = x * y

let g (x:int) : int = f2 x
                      ^^
This expression has type int -> int but is here used with type int

let h (x:int) = 2 * g x


I would have gotten a compiler error directly since the type of g isn't int,
it is the closure 'f2 x'. AND NOW I CAN CORRECT THE ERROR DIRECTLY


I don't really see the use of infering types for functions. It works for one
person hacks, like compilers, interpreters, theorem provers, but it doesn't
scale well to programs with many programmers involved.

The types of the function is vital information when you try to understand
the code. And putting this information in a separate file (.mli) for some of
the functions (the public ones) isn't a very good solution.

If you required that the arguments where typed, wouldn't it be possible to
get rid of the distinction of * and *., and infer if it is float or int? It
is a big pain today changing from int to float in a program, in non-ML
languages you just make 'M-x query-replace "int" "float"'


/mattias

Re: Functions must be explicitly typed, (was Same label in different types, how do people solve this?)

[John Max Skaller]

Mattias Waldau wrote:
> 
> > In Felix, I compromised: functions must be explicitly typed
> > when declared, but values don't:
> >
> >       function f(a:int): int { val b = a; return b; }
> 
> Which I think is an good idea. I normally type the functions in Ocaml, but I
> don't type the local variables. 

	But everything is a compromise. I do this regularly:

let rec f (a:ta) (b:tb) (c:tc) (d:td) (e:te) =
   let ff e = f a b c d e in
   ....
	ff expr

It would be a pain to have to type 'ff' here: it's more like
a 'local variable' than a new function definition.

In Ocaml, terse expression with the _option_ of adding a type
constraint isn't that unreasonable. The real problem is that
the inference engine isn't smart enough to remember _how_ it
deduced a type, and report _both_ locations when there is a
conflict. I have a suspicion this is non-trivial: probably
worth a PhD. :-)

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net

Re: Functions must be explicitly typed, (was Same label in different types, how do people solve this?)

[Stefan Monnier]

>>>>> "Mattias" == Mattias Waldau <mattias.waldau@abc.se> writes:
> I don't really see the use of infering types for functions. It works for one

I agree that it's generally good documentation (and good debugging aid when
you get a type error), but when you just need a small function to pass to
`map' or `fold' (i.e. cases that correspond to loop bodies in procedural
languages), it can be convenient not to have to write the types.

> person hacks, like compilers, interpreters, theorem provers, but it doesn't
> scale well to programs with many programmers involved.

I don't think that has much to do with the number of people involved.
I have enough trouble understanding code written by "myself a year ago".


        Stefan

Re: Functions must be explicitly typed, (was Same label in different types, how do people solve this?)

[Andreas Rossberg]

John Max Skaller wrote:
> 
> In Ocaml, terse expression with the _option_ of adding a type
> constraint isn't that unreasonable. The real problem is that
> the inference engine isn't smart enough to remember _how_ it
> deduced a type, and report _both_ locations when there is a
> conflict. I have a suspicion this is non-trivial:

It is non-trivial because in general the deduction of a type involves
arbitrary many `locations'. So you actually had to report some kind of
unification trace, which might not be very helpful for the unprepared
programmer if it gets too complicated. The actual problem is to find
useful heuristics for identifying the `interesting' parts of this
information and for presenting it to the user.

> probably worth a PhD. :-)

There is in fact research going on on this topic, some of it certainly
being done by PhD students. ;-)

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

:: be declarative. be functional. just be. ::

Re: Functions must be explicitly typed, (was Same label in different types, how do people solve this?)

[Pierre Weis]

> >>>>> "Mattias" == Mattias Waldau <mattias.waldau@abc.se> writes:
> > I don't really see the use of infering types for functions. It works for one

I would like to note that type inference (i.e. code without
annotations) helps a lot when developing programs: the annotation free
code is not only easier to write but also easier to maintain since it
is kind of ``auto-adaptative'' and resistant to reorganisations and
names modifications.

As an example, consider a function with an explicit profile:

let (type_type_definition : Synt.td -> ...) = function ...

If we consider renaming the module Synt into Syntax, and the type td
into type_definition to reflect as closely as possible the intended
meanings, we would have to edit the definition of the function (and
the definition of every function that uses either the module Synt or
the type td). By contrast, if we omit manual type annotations, the
type checker will silently change the type assigments as necessary. It
is extremely convenient when writing systems that are rapidly
evolving.

Hope this helps,

Pierre Weis

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

Re: Functions must be explicitly typed, (was Same label in different types, how do people solve this?)

[Frank Atanassow]

John Max Skaller wrote (on 13-12-00 11:51 +1100):
> In Ocaml, terse expression with the _option_ of adding a type
> constraint isn't that unreasonable. The real problem is that
> the inference engine isn't smart enough to remember _how_ it
> deduced a type, and report _both_ locations when there is a
> conflict. I have a suspicion this is non-trivial: probably
> worth a PhD. :-)

Or at least a Master's. And by a fortuitous coincidence, one of our students
Bastiaan Heeren wrote a thesis on this essentially this topic. His type
inferencer uses heuristics to improve the quality of type-error messages; for
example, if x gets assigned type A in 2 places, and type B in only 1 place,
then the inferencer reports the latter as the source of the type conflict.

You can find his page, and the thesis, here:

  http://www.cs.uu.nl/people/bastiaan/

There is also some work by Dominic Duggan and Frederick Bent on "type
explanation":

  D. Duggan and Frederick Bent.  Explaining type inference.  Science of
  Computer Programming, 27,1, June 1996.

  Dominic Duggan. Correct Type Explanations  ACM ML Workshop, Baltimore,
  Maryland, September 1998.

and an implementation, SML/E: A Type Explanation Facility for Standard ML:

  http://guinness.cs.stevens-tech.edu/~dduggan/Public/Smle/index.html

-- 
Frank Atanassow, Information & Computing Sciences, Utrecht University
Padualaan 14, PO Box 80.089, 3508 TB Utrecht, Netherlands
Tel +31 (030) 253-3261 Fax +31 (030) 251-379

RE: Functions must be explicitly typed, (was Same label in different types, how do people solve this?)

[Mattias Waldau]

>>> >>>>> "Mattias" == Mattias Waldau <mattias.waldau@abc.se> writes:
>>> > I don't really see the use of infering types for functions. It works
for one

I was wrong! It is very nice to have type inference for local and anynomous
functions.

>>
>> I would like to note that type inference (i.e. code without
>> annotations) helps a lot when developing programs: the annotation free
>> code is not only easier to write but also easier to maintain since it
>> is kind of ``auto-adaptative'' and resistant to reorganisations and
>> names modifications.

If this were important, we shouldn't have different operators for * and *.
I had to change a program from integers to float recently, and it isn't fun
at all.

/mattias

Re: Same label in different types, how do people solve this?

[Bruce Hoult]

At 4:43 AM +1100 13/12/00, John Max Skaller wrote:
>Chet Murthy wrote:
>
>>  The issue, about practicality, isn't whether you _can_ specify the
>>  particular types and type-usages you want.  The issue is whether, if
>>  you write a phrase, and you got it wrong, you have to know all about
>>  the type system, in order to debug that phrase.
>
>It is a tradeoff. Full inference makes code short: lack of
>inference severely pollutes programming style (as in C++).
>In Felix, I compromised: functions must be explicitly typed
>when declared, but values don't:
>
>	function f(a:int): int { val b = a; return b; }
>
>f must be explicitly typed. The type of b is deduced.

That's how most code gets written in Dylan.  You need to declare 
argument types for methods of generic functions so that the 
polymorphic dispatch can figure out which method to call for which 
actual arguments.  Once you've done that, the compiler can often 
figure out all the types within the method by itself.

Internal functions -- anonymous arguments to things such as map(), 
and ones used for tail-recursive looping, for example -- don't tend 
to have their arguments declared.

The difference between Dylan and ML-family languages is, of course, 
that in ML if the compiler can't figure out some types it complains, 
whereas Dylan just says "oh well, it's <object>, then", and you 
silently end up with less efficient code.  A good compiler will have 
tools to tell you about this sort of thing when you want to know 
about it, and ignore it otherwise.

-- Bruce

RE: Functions must be explicitly typed, (was Same label in different types, how do people solve this?)

[Brian Rogoff]

On Fri, 15 Dec 2000, Mattias Waldau wrote:
> >> Pierre Weis wrote
> >> I would like to note that type inference (i.e. code without
> >> annotations) helps a lot when developing programs: the annotation free
> >> code is not only easier to write but also easier to maintain since it
> >> is kind of ``auto-adaptative'' and resistant to reorganisations and
> >> names modifications.
> 
> If this were important, we shouldn't have different operators for * and *.

I agree. It's the same problem as with functions like print_int, output_int, 
etc., where the lack of overloading forces a type name to get attached to
a function to disambiguate. I don't like this either, and I eagerly await
a solution. Be patient, people are still working on a fix; it has come up
a few times already that the Caml developers are not happy with the status
quo but are working on something which will do quite a bit more than just 
enable you to overload a few arithmetic operators. 

> I had to change a program from integers to float recently, and it isn't fun
> at all.

Yes, I used to wonder if type classes would have been a good idea since
they do make a few of these simpler issues easier to handle. Pierre Weis 
gave some examples of what he'd like to be able to do: for instance, to
overload the .() or .[] so array and string access would be the same, and
even extend it to hash table lookup. If it takes a little while to get
these features in a type-safe way I'm willing to wait. If it turns out to
be too difficult then I suppose we can agitate for type-classes ;-). I
guess the positive side of all of this for the Caml developers is that
they'll always have lots of interesting things to work on. 

In the meantime, there are workarounds which can help you out. You may use 
the module system to bind the names of functions (like "*.") to the
name you want and localize the changes that you'll need to make when you
change representations (i.e., you'll only need to change them where you've
done the rebinding). Admittedly this is a workaround, same as the record
label fixes, but it may lessen your difficulties. 

-- Brian

ROverloading

[John Max Skaller]

Mattias Waldau wrote:

> >> I would like to note that type inference (i.e. code without
> >> annotations) helps a lot when developing programs: the annotation free
> >> code is not only easier to write but also easier to maintain since it
> >> is kind of ``auto-adaptative'' and resistant to reorganisations and
> >> names modifications.
> 
> If this were important, we shouldn't have different operators for * and *.
> I had to change a program from integers to float recently, and it isn't fun
> at all.

	Overloading is, perhaps unfortunately, more or less
mandatory in the long run, perhaps not so much to support 'ad hoc
polymorphism'
as to relieve the programmer of learning lots of names for
things. In Ocaml, learning + for int and +. for float isn't
so bad. But add in ten other integer representations, and we're rapidly
forced to resort to named prefix operators (i.e. function names).

	Unfortunately, overloading isn't quite so simple when 
you've also got type inference:

	let f a b = a + b in
	let x = f 1.0 2.0 in
	let y = f 1 2 in 

If we take 'f' to be monomorphic, then
the second call is in error, because the overloaded + in the
definition of 'f' doesn't determine it's type until x is
calculated. Otherwise, 'f' could be taken to define an overloaded
set of functions (somewhat like a C++ template) and the calculations
of x and y would call different specialisations .. but this rapidly
gets quite messy.

Felix supports overloading, but it works more easily because
functions must be explicitly typed. Nevertheless it is sometimes
necessary to explicitly resolve an overload:

	function f(a:int):int { ..}
	function f(a:float):float { ..}
	val g = f of (int); // which f?

because there is inference of val's and var's, and, even without that:

	function g(f:int->int):int { .. }
	function g(f:float->float):float { .. }
	.. g(f of (int)) .. //which g? depends on which f!


-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net

Re: ROverloading

[John Max Skaller]

Dave Berry wrote:
> 
> John Max Skaller wrote:
> 
> >       Unfortunately, overloading isn't quite so simple when
> > you've also got type inference:
> 
> That depends on how general you try to be.  I'd be quite happy with a system
> that allowed multiple definitions of a name, but forced applications to be
> monomorphic.  In your example, the definition of f would require a
> disambiguating type annotation (or assume a default):
> 
> >       let f a b = a + b in
> >       let x = f 1.0 2.0 in
> >       let y = f 1 2 in
> 
> would become
> 
>         let f a b = a + b : int in ...
> 
> Theoretically inelegant, but pragmatically sufficient.  As indeed you seem
> to be doing in Felix.
> 
> I'd use the module system to introduce and control overloading, rather than
> trying to extend the core language.  It seems a simpler route.

	In Felix, overload resolution is done during a name binding
phase. It is necessary to 'chase' the type of variables introduced
without a type annotation recursively, but the process appears to
always terminate (though I'm not completely sure).

	There are no 'type variables', hence no generic functions:
instead, I plan to use functors (as in ocaml) exclusively. This fits
better with the back end target (C++), and I hope it will be easy
enough for C++ programmers to use .. as well as generating efficient
code .. and providing some interesting challenges in reducing
code bloat (the compiler target is a shared library :-)

	But I do not have a good model for using the module system
to control overloading. I worked on the design of namespaces in C++
and don't really consider it satisfactory. So I'd be interested in how
you'd control overloading leveraging the module system. ??


	In felix, only functions can be overloaded, NOT function
closures. So while you can do this:

	module fred { function f(a:int):int { return 1; } }
	val f = fred::f of (int);

the 'f' in the outer scope cannot be overloaded. It isn't a function,
its a function closure. It would be possible to implement:

	open fred;
	open joe;

so that function overload sets merged (and other duplications caused an
error on use). This is equivalent to 'using namespace fred; using
namespace joe;' in C++ (except that it doesn't change the public
interface
of the module doing the opening). It's also very coarse.

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net

RE: ROverloading

[Dave Berry]

John Max Skaller wrote:

> 	Unfortunately, overloading isn't quite so simple when 
> you've also got type inference:

That depends on how general you try to be.  I'd be quite happy with a system
that allowed multiple definitions of a name, but forced applications to be
monomorphic.  In your example, the definition of f would require a
disambiguating type annotation (or assume a default):

>	let f a b = a + b in
>	let x = f 1.0 2.0 in
>	let y = f 1 2 in 

would become

	let f a b = a + b : int in ...

Theoretically inelegant, but pragmatically sufficient.  As indeed you seem
to be doing in Felix.

I'd use the module system to introduce and control overloading, rather than
trying to extend the core language.  It seems a simpler route.

Dave.