caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
* bug in object type inference ?
@ 2008-01-13 13:58 Romain Beauxis
  2008-01-13 14:19 ` [Caml-list] " David Baelde
  0 siblings, 1 reply; 2+ messages in thread
From: Romain Beauxis @ 2008-01-13 13:58 UTC (permalink / raw)
  To: caml-list

	Hi all !

While preparing a function that takes an object as parameter, I encountered a 
type issue on which I'd like to have some feedback..

Let's consider this very simple example:

* We got a class of objects:
class test =
  object(self)
  method test ?(foo="bar") () = ()
end

* We instanciate one of them:
let p = new test

* We define a function that takes one of them, plus additional argument, and 
apply to the method test:
let f = fun p foo -> p#test ~foo ()

* Then, we got a type error:
This expression has type test but is here used with type
  < test : foo:'a -> unit -> 'b; .. >
Types for method test are incompatible

This means that the optional argument for method test in class test is infered 
as mandatory argument for the object passed to f.

Or course, this can be solved by writing directly:
let f : test -> string -> unit  = fun p foo -> p#test ~foo ()

But I'm wondering why the type inference could not just say "either optional 
either mandatory argument". After all, this confusion comes from the fact the 
the semantic for applying optional and mandatory arguments are the same...

Or perhaps this is a well known subject and I'm not documented enough ?


Romain


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [Caml-list] bug in object type inference ?
  2008-01-13 13:58 bug in object type inference ? Romain Beauxis
@ 2008-01-13 14:19 ` David Baelde
  0 siblings, 0 replies; 2+ messages in thread
From: David Baelde @ 2008-01-13 14:19 UTC (permalink / raw)
  To: Romain Beauxis; +Cc: caml-list

Hi Romain,

This is not a bug, but just a limitation of type inference on labels
-- it is independent from OO. If a type is unknown and is used for a
labelled application, the parameter will be supposed to be mandatory.
I guess inference goes too wild without that restriction -- because
with types where the optionality is unknown, it is also unknown when
an application is total.

A simpler example of that:

# let g f a = f ~a () ;;
val g : (a:'a -> unit -> 'b) -> 'a -> 'b = <fun>

The type of f is infered with a mandatory param labelled a.

# let f ?a b = b ;;
val f : ?a:'a -> 'b -> 'b = <fun>
# g f ;;
This expression has type ?a:'a -> 'b -> 'b but is here used with type
  a:'c -> unit -> 'd

This would work with an annotation in the declaration of g:

# let g (f : ?a:'a -> unit -> 'b) a = f ~a () ;;
val g : (?a:'a -> unit -> 'b) -> 'a -> 'b = <fun>

-- 
David


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2008-01-13 14:19 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-01-13 13:58 bug in object type inference ? Romain Beauxis
2008-01-13 14:19 ` [Caml-list] " David Baelde

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).