Back to Questions
2.3k
views8
comments
what am I missing about types?
f#

I must be reading over or just not understanding something fundamental about type inference in F#. My expectation is that something like this:

let checkType thing =
match thing with
| bool -> "a bool"
| _::_ -> "a list";;

would generalize the type of "thing" to " 'a ", but when I put this into fsi, I get:

val applyone : 'a list -> string

Why is F# assuming that "thing" is a list? What's even more damning is that even though I'm told the type is a list, I get a warning informing me that the second rule (which actually checks for a list) will never be matched. That much, at least, is true. Giving "checkType" a list of anything brings back the string "a bool". Interestingly, giving the function a bool actually fails the function.

Is my syntax wrong? Am I just missing something? I've tried about forty different permutations, as well as reading three different chapters from the Experts' book, and I feel like my brain has jumped ship.

DC

.

At the moment "bool" is the name of a variable, just as if you had written:

1
2
3
4

let checkType thing = 
    match thing with
    | x -> "a bool"
    | _::_ -> "a list";;

Clearly the first rule will match any input and bind it to "x". Hence the warning about the second rule: it's telling you that you have a problem.

What you really want is a type test, e.g.:

1
2
3
4
5

let checkType thing = 
    match box thing with
    | :? bool  -> "a bool"
    | :? list<int> -> "an integer list"
    | _ -> failwith "something else";;

Note I've called "box" to turn the 'a input into a value of type "obj". This is covered in Chapter 5 of the draft chapters.

Note also we've only checked for a particular type of list (list<int>) - there are ways to check if the thing is _any_ kind of list, but I won't go into them here - basically you almost never need to do that in F# coding and since you're just starting off it's better to learn the normal way to use the language first.

Cheers

don

By on 3/22/2007 2:27 PM ()

BTW you can also bind the result of the type test:

1
2
3
4
5

let checkType thing = 
    match box thing with
    | :? bool as b -> "a bool: " + (if b then "true" else "false")
    | :? list<int> as l -> "an integer list, length = " + Int32.to_string l.Length
    | _ -> failwith "something else";;

Don

By on 3/22/2007 2:30 PM ()

Okay, I read that, but I must have borked the syntax when I was trying things, because I had trouble with boxing. Thanks again!

DC

By on 3/22/2007 2:40 PM ()

No problem. I can see you know your stuff as a programmer, so I'm interested to know what kind of extra material in the book chapters (or whatever other material you've been consulting) would have been helpful for you to get over these little hurdles? For example, would a more complete grammar have been useful? Or more examples?

Thanks!

Don

By on 3/22/2007 2:49 PM ()

Thanks for the compliment. Coming from someone who designs freaking languages, that means a lot.

I think the one thing that would help me more than anything would be a more complete discussion of the fundamental differences between doing something (even something simple, like comparing types, or substituting things in a list/array/tuple/whatever) in a functional language like F#, and doing it in an imperative language like C# (which I use on a daily basis).

A breakdown of types is useful for someone who is new to .NET, but who is going to hit an experimental functional language on their first run into a framework? I can't speak for all programmers, but it seems to me that showing the difference between a task in C# and F# (or C and F#, or Java and F#) would make finding a mental footing a lot less agonizing.

That being said, with one or two exceptions (such as a slightly anemic exposition on type testing) the syntax is pretty well defined in the things I've read thus far. Whether that's just because F# has a succinct grammar or because you've hit all of the high points that a beginner is likely to run into, I can't say. I have yet to even begin to contemplate writing any OOP code, so I've only briefly skimmed that section of the book, and as such, my opinion will be less than helpful.

DC

By on 3/22/2007 3:25 PM ()

Great feedback - thanks.

You'd be surprised about people's backgrounds - a good proportion of F# users have had no experience of .NET, and come from either an OCaml, Haskell or Python background. These users are usually pretty happy to find a fairly familiar language combined with a great set of libraries. For example, AndyMan who does HDFS and regularly contributes here is, I believe, an OCaml programmer first and foremost. And Richard Mortier at MSR Cambridge switched from Python. And Jon Harrop of "F# for Scientists" fame is an OCaml programmer at heart. We're a broad church :-)

But I absolutely agree that a "F# for the C# programmer" guide would be helpful. Antonio Cisternino is a co-author on Expert F# (writing the GUI chapter, among others) and plans to add that to the book.

Don

By on 3/22/2007 3:39 PM ()

That's a good point. In my little Punnet Square of programmers, I neglected the quadrant involving those individuals who knew functional programming but not .NET.

DC

By on 3/22/2007 6:02 PM ()

I've been using OCaml for several years and I learned F# a few months ago. It was my first .Net language. I think F# is a nice opportunity for functionnal programmers to work on real-world applications thanks to the .Net library (OCaml standard library is way smaller) and a full IDE.

I'm not surprised many F# users where OCaml programmers, because they don't have to learn a whole new language (differences are quite small). I think the transition OCaml -> F# is quite natural.

Laurent.

By on 3/23/2007 2:43 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