Back to Questions
1.5k
views3
comments
why explicit upcasts?
f#

Hi,

Coming from C# and other non-ML languages, I didn't expect the following...

let f (objs : obj list) = ...
f [box 1; "a"]

... which gives the error "Type mismatch. Expecting a obj list but given a string list". I understand this error, and can eliminate it by saying ("a" :> obj), but I'm wondering: is there a reason for requiring the explicit upcast? If I understand this right, other languages (like C#) add upcasts implicitly. And I gather that F# does this too, when calling class members.

I sometimes like these "mixed type" collections. Another example is a property list -- (string * obj) list. And of course I also like succinct code. So I want to get rid of the (<i>expr<i> :> obj) constraints around values in my list expressions. Rob

.

BTW... I don't want to sound like I'm nitpicking at the language. To all those working hard on F#: thank you! I'm just learning, but so far I think it is awesome. I used Scheme for a while in a commercial environment, and my functional bliss was diluted by runtime type errors, among other things. F# feels like the answer to those problems.

They say learning Lisp/Scheme makes you a better programmer. I'm feeling the same way as I learn F# and OCaml.

Rob

By on 3/18/2007 9:26 PM ()

Hi Rob,

Upcasts are indeed required in F#, sometimes that places where you may not expect them. For the case of the list syntax the simple answer is "the typing rule for the [e1; ...; eN] list expression construct requires that each e1 .. eN has the same static type". The longer answer is that the .NET type system does not always allow a type checker or type inference system to automatically compute the intersection type of two types, e.g. to find a nearest unique common parent to the types of e1 and e2 in the expression [e1; e2]. This can be done in some special cases, but not in general.

I can see an argument for either making this rule more liberal, e.g. if a nearest common unique ancestor is well-defined, or for allowing automatic upcasts where the precise type of the list is already known (e.g. through a type annotation).

One of the other places where upcasts occur is in assignments "x.f <- expr".

Cheers!

don

By on 3/19/2007 2:14 PM ()

As someone who works on formal verification, may I say that the need for explicit upcasts in F# was a nice surprise. Compared to traditional languages, F# offers much greater possibilities for formal verification, because of the general absence of aliases to mutating objects. The requirement for upcasts to be explicit in most contexts is a bonus. This is because knowing the exact type of a value means that when a member function is called, the exact definition of the result is known, rather than just some postcondition that the author may not have bothered to write anyway.

By on 3/6/2008 1:39 AM ()

    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