Back to Questions
3.0k
views4
comments
Member overloading
f#

Hi,

I've been playing around with adding members to a union type and hit a type checking problem when overloading a method. Here's the code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69

#light 
module DigitalLogic.Fixed2
open DigitalLogic
open Circuit
open Design

exception Fix_error of string

type UFixed = 
  { 
    signal : Circuit.signal_t 
    high : int
    low : int
  }
  with
    
    (** id of internal signal *)
    member x.Id = uid x.signal
    (** width of integer signal *)
    member x.Width = width x.signal
    (** Fixed point position. *)
    member x.Fix = -x.low
    (** Determine if the width of the signal and high and low are valid *)
    member x.Valid = width x.signal = x.high - x.low + 1
    (** Left most bit position *)
    member x.High = x.high
    (** Right most bit position *)
    member x.Low = x.low
    (** Internal signal *)
    member x.Signal = x.signal
    
    (** Create a ufixed from a signal with the given fixed point *)
    static member to_ufixed s f = 
      let s = { signal = s; high = (width s) - f - 1; low = -f }
      s
      
    (** Convert the given floating point number to a fixed point integer.  Rounding is performed if rnd is true.  *)
    static member fixed_of_float' rnd f v =
      assert (v >= 0.0)
      let scale = 2.0 ** (float_of_int f)
      let rnd = if rnd then 0.5 else 0.0
      int_of_float ((v * scale) + rnd)

    (** Convert the given floating point number to a fixed point integer.  Rounding is performed.  *)
    member x.fixed_of_float v = UFixed.fixed_of_float' true x.Fix v

    (** fixed point constant from an integer *)
    static member consti w f i : UFixed = UFixed.to_ufixed (Design.consti w i) f
    
    (** fixed point constant from a float.  Rounding optional *)
    static member constf' r w f i = UFixed.consti w f (UFixed.fixed_of_float' r f i)

    (** fixed point constant from a float.  Performs rounding *)
    static member constf w f i = UFixed.consti w f (UFixed.fixed_of_float' true f i)

    member x.constf i = UFixed.consti x.Width x.Fix (UFixed.fixed_of_float' true x.Fix i)

    //member x.consti i = UFixed.to_ufixed (Design.consti x.Width i) x.Fix         //XXXX

  end

let test() = 
    let a = UFixed.to_ufixed (consti 16 0) 8  (* 8.8 fixed point number *)
    let b = UFixed.constf 16 8 2.0
    let c = a.constf 2.0
    
    let d = UFixed.consti 16 8 2
    //let e = a.consti 2            //XXXX
    ()

While I seem to be able to overload (and use) the constf function, I cannot do the same with consti. As given the above code works but uncomment the lines marked with XXX and it fails with the following errors. Not quite sure why as at first glance the functions look very similar.

c:\dev\hdfs\temp.ml(51,36): error: FS0041: The method consti is overloaded. Possible matches are shown below (or in the Error List window). Resolve the overloading by adding further type annotations to the arguments.

Possible overload: 'member UFixed.consti : 'b -> 'a'.

Possible overload: 'static member UFixed.consti : int -> (int -> int -> UFixed)'.

c:\dev\hdfs\temp.ml(53,33): error: FS0041: The method consti is overloaded. Possible matches are shown below (or in the Error List window). Resolve the overloading by adding further type annotations to the arguments.

Possible overload: 'member UFixed.consti : 'b -> 'a'.

Possible overload: 'static member UFixed.consti : int -> (int -> int -> UFixed)'.

c:\dev\hdfs\temp.ml(64,12): error: FS0041: The method consti is overloaded. Possible matches are shown below (or in the Error List window). Resolve the overloading by adding further type annotations to the arguments.

Possible overload: 'member UFixed.consti : int -> UFixed'.

Possible overload: 'static member UFixed.consti : int -> (int -> int -> UFixed)'.

c:\dev\hdfs\temp.ml(65,12): error: FS0041: The method consti is overloaded. Possible matches are shown below (or in the Error List window). Resolve the overloading by adding further type annotations to the arguments.

Possible overload: 'member UFixed.consti : int -> UFixed'.

Possible overload: 'static member UFixed.consti : int -> (int -> int -> UFixed)'.

Cheers,

Andy

.

In the first error message the very general type "'b -> 'a" indicates that at the point of overload resolution the inferred types of the overloaded members are not yet fully known. Overload resolution is based largely on types, hence this is a problem. Adding type annotation information to the arguments of the overloads should resolve the issue, or change their order of declaration in the class so their types are inferred first. (This is just part of the tax of using type inference in the context of defining a set of recursively referential overloads, similar to the tax of putting type annotations on things to resolve the "dot" notation)

However your style of attempting to overload on curried members is unusual and will almost certainly lead to problems. Overload resolution only takes into account the arity and types of the first parameter of a curried member (i.e. the true parameter, and not the parameters of the residual function arising from a curried application).

Note that new F# definitions of overload sets are only permitted by name/arity-of-first-argument by default, and your curried members currently have arity "1", i.e. the first argument is not a syntactic tuple, which is how arity is measued, e.g.

  • "member x.M()" gets arity 0
  • "member x.M(a)" gets arity 1
  • "member x.M(a,b)" gets arity 2

etc. So defining overloads really is biased towards members that take their arguments as a syntactic tuple.

To permit overloads resolved at type-granularity you need to use OverloadID attributes - this helps the type checker match implementations to signatures, among other things. See [link:research.microsoft.com]

Cheers,

Don

By on 1/18/2007 4:00 PM ()

In the first error message the very general type "'b -> 'a" indicates that at the point of overload resolution the inferred types of the overloaded members are not yet fully known. Overload resolution is based largely on types, hence this is a problem. Adding type annotation information to the arguments of the overloads should resolve the issue, or change their order of declaration in the class so their types are inferred first. (This is just part of the tax of using type inference in the context of defining a set of recursively referential overloads, similar to the tax of putting type annotations on things to resolve the "dot" notation)

I did notice that moving the declaration around would increase/decrese the number of errors. Adding type annotations didnt really seem to help but as you suggest that's most likely my use of curried functions.

However your style of attempting to overload on curried members is unusual and will almost certainly lead to problems. Overload resolution only takes into account the arity and types of the first parameter of a curried member (i.e. the true parameter, and not the parameters of the residual function arising from a curried application).

That explains things perfectly. I've refactored the code to eliminate currying and it works properly now. I also see why the constf function worked as it's first argument types were different (int and float).

To permit overloads resolved at type-granularity you need to use OverloadID attributes - this helps the type checker match implementations to signatures, among other things. See [link:research.microsoft.com]

I'n not too clear about what you mean here. What I did find, however, is that I could overload my operators (which weren't shown before) if I added a unique OverloadID to each version. I'n not sure why I have to do this however - it doesnt really seem any different to overloaded members. Anyway this is what I did. Does it look right?

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

    (** Addition.  The two input numbers are converted so that their ranges are compatible then extended by one bit.  The result therefore cannot overflow *)
    [<OverloadID("Add_ufixed_ufixed")>]
    static member (+) ((a : UFixed), (b : UFixed)) = 
      let high, low = UFixed.merge_ranges (a, b)
      let a, b = a.resize ((high + 1), low), b.resize ((high + 1), low)
      let s = UFixed.to_ufixed ((a.signal +: b.signal), (-(min a.low b.low)))
      s

    (** Addition with an integer operand on the right.  The integer operand is converted to the same fixed point format as the left operand *)
    [<OverloadID("Add_ufixed_int")>]
    static member (+) ((a : UFixed), (b : int)) = 
      assert (b >= 0);
      (a + UFixed.to_ufixed ((consti a.Width b), a.Fix))

    [<OverloadID("Add_int_ufixed")>]
    static member (+) ((a : int), (b : UFixed)) = b + a

Thanks for your help,

Andy

By on 1/18/2007 4:45 PM ()

Oops...spoke too soon. While ufixed + int works, int + ufixed doesnt:

hdfs/lib/test/test_fixed.ml(24,39): error: FS0001: This expression has type
UFixed
but is here used with type
int

By on 1/18/2007 4:54 PM ()

There is a restriction on overloaded infix operators such as (+) that basically means the type of the left-hand operand must be the type of the containing type. So TY+int is OK, but int+TY is not. That's just the way it is.

This restriction stems from the way operator overload constraints are propogated, which differs slightly from overload resolution (although it eventually boils down to overload resolution). We are in the process of reviewing this to decide if we want to extend the mechanism to allow the constraints to propogate arbitrary overload behaviour.

cheers,

don

By on 1/18/2007 5:33 PM ()

    Topic tags

    IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
    Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy     		Built with WebSharper