[Caml-list] Optional arguments in inherited methods

[Caml-list] Optional arguments in inherited methods

[John Goerzen]

Hello,

I have this defined in a base class:

    method private getdata sname oname =  <code here>

In my subclass, I wish to do this:

    method private getdata ?(raw=false) ?(idepth=10) ?extravars sname oname = <code>

The compiler does not seem to like this at all, though I am at a loss to
explain why.  Can someone help me out?

The error I get is:

The method getdata has type
  ?raw:'a -> ?idepth:'b -> ?extravars:'c -> 'd -> 'e -> 'f
  but is expected to have type string -> string -> string

So even stranger is that it doesn't set a type for anything, even though
it has enough information to figure out the type for everything.

Hints?

-- John

-------------------
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] Optional arguments in inherited methods

[james woodyatt]

On 28 Apr 2004, at 09:13, John Goerzen wrote:
>
> I have this defined in a base class:
>
>     method private getdata sname oname =  <code here>
>
> In my subclass, I wish to do this:
>
>     method private getdata ?(raw=false) ?(idepth=10) ?extravars sname 
> oname = <code>
>
> The compiler does not seem to like this at all, though I am at a loss 
> to
> explain why.  Can someone help me out?

Presumably, given this in the base class:

	method getdataf sname = <code here returns function>

...you wish the compiler to insure that the default values are used for 
each of the optional arguments in the [possibly partial] evaluation of 
the derived class method.

Well— it doesn't.  You have to define the derived class method in two 
parts.

	method private getdata_aux ?(raw=false) ?(idepth=10) ?extravars sname 
oname = <code>
	method private getdata sname oname = self#getdata sname oname

> The error I get is:
>
> The method getdata has type
>   ?raw:'a -> ?idepth:'b -> ?extravars:'c -> 'd -> 'e -> 'f
>   but is expected to have type string -> string -> string
>
> So even stranger is that it doesn't set a type for anything, even 
> though
> it has enough information to figure out the type for everything.

Yeah, it's already decided you have a problem before it's finished 
inferring the types of everything.  That might be another one of those 
little annoyances... since inferring types when the code is known to be 
in error is probably a hard problem.


-- 
j h woodyatt <jhw@wetware.com>
that's my village calling... no doubt, they want their idiot back.

-------------------
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] Optional arguments in inherited methods

[John Goerzen]

On Wed, Apr 28, 2004 at 09:56:36AM -0700, james woodyatt wrote:
> 	method getdataf sname = <code here returns function>
> 
> ...you wish the compiler to insure that the default values are used for 
> each of the optional arguments in the [possibly partial] evaluation of 
> the derived class method.
> 
> Well? it doesn't.  You have to define the derived class method in two 
> parts.

Hmm.  I worked around that problem but now I have a new one.  From my
.mli file, I have this in my superclass:

    method get: ?default:string -> string -> string -> string

and I wish to have this in my subclass:

    method get: ?default:string -> ?raw:bool -> ?idepth:int -> 
          ?extravars:(string, string) Hashtbl.t 
          -> string -> string -> string
                      
Now, since labeled args are not positional, I would think that the
compiler should have no problem with adding new optional args, since a
call to the base class's method would remain completely valid as a call
to the subclass's method.  However, I get this error:

The method get has type
  ?default:string ->
  ?raw:bool ->
  ?idepth:int ->
  ?extravars:(string, string) Hashtbl.t -> string -> string -> string
but is expected to have type ?default:string -> string -> string -> string

Argh.  Does OCaml's object system really not support adding additional
optional variables to subclass methods?

That would be rather annoying if true.

-- John

-------------------
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] Optional arguments in inherited methods

[Jacques GARRIGUE]

From: John Goerzen <jgoerzen@complete.org>

> Argh.  Does OCaml's object system really not support adding additional
> optional variables to subclass methods?

No, it doesn't support that.
Methods in subclasses must have exactly the same type as in the
superclass (the types are unified during checking).
So you are not even allowed to use a subtype of the original method
type (which would be perfectly sound in theory)

> That would be rather annoying if true.

Unfortunate, but in the case of optional arguments the problem is
not with typing but with how they are implemented: an optional
argument of type [t] is actually a non-optional argument of type [t
option]. They disappear automagically on application, but this means
that None's are automatically inserted. So applying a function which has
optional arguments is completely different from a function without
them (even if the function call looks the same in your source code).

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] Optional arguments in inherited methods

[Henri DF]

> Unfortunate, but in the case of optional arguments the problem is
> not with typing but with how they are implemented: an optional
> argument of type [t] is actually a non-optional argument of type [t
> option]. They disappear automagically on application, but this means
> that None's are automatically inserted. So applying a function which has
> optional arguments is completely different from a function without
> them (even if the function call looks the same in your source code).
> 

what about optional arguments which have a default value? i would assume 
these are not implemented using options, so would that change anything 
here?

thanks
henri

-------------------
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] Optional arguments in inherited methods

[Jacques GARRIGUE]

From: Henri DF <henri.dubois-ferriere@epfl.ch>

> > Unfortunate, but in the case of optional arguments the problem is
> > not with typing but with how they are implemented: an optional
> > argument of type [t] is actually a non-optional argument of type [t
> > option]. They disappear automagically on application, but this means
> > that None's are automatically inserted. So applying a function which has
> > optional arguments is completely different from a function without
> > them (even if the function call looks the same in your source code).
> 
> what about optional arguments which have a default value? i would assume 
> these are not implemented using options, so would that change anything 
> here?

They are also implemented with options.

  let f ?(x=0) y = x + y

is just a shorthand for

  let f ?x y = let x = match x with Some x -> x | None -> 0 in x + y

(I believe this is explained in the manual)

Why is it this way? Just because the ocaml type system is such that we
don't want to have values inside types, which is the approach you can
see in C++ for instance.

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