Basic F# questions: mutability, capitalization standards, functions vs. methods

Question

Feel free to point me to other answers if these have already been asked!

I'm just starting F# with the new release this month. I've got some background in both OO and functional languages (Haskell and Scheme, but not OCaml/ML). A couple of questions have arisen so far from reading through the little tutorial thing that comes with the F# CTP.

1) Are mutable variables preferred over monads? If so, are monads entirely shunned in F#?

2) I'm a tad confused by the capitalization being used. In this tutorial code file, sometimes functions start with a lowercase letter, and sometimes uppercase. I know MS tends to like initial caps with functions and methods, but here it seems like there are two ways of doing it. It's not a huge deal to me, as I'm just playing around on my own time, but I am curious what the standard is.

3) I'm pretty confused about this whole combination of OO and functional styles. print_string "string" makes sense, but then here is List.map fn list (unless List is just the namespace, forgive me if so). Then here is str.Length. Anyone care to elucidate when to use what, and which is preferred?

Thanks!

Answer 1

Regarding mutability: F# allows you to be pragmatic. I rarely prefer a state monad to a mutable/ref, but you can do whichever you like. Monads are not shunned, but I think people tend to only use them when they're a clear-cut win (e.g. async programming).

Regarding naming: there is a tension in the fact that 'functions are values' means you might choose to name a let-bound function with a capital letter (because it's a function, and functions begin with capitals) or with a lower-case letter (because it's a let-bound value (that just happens to have an '->' in its type name)). Personally I prefer to always use upper-case names for all functions, but you'll see both styles (especially since the style of the F# library itself has been slowly evolving/standardizing over the past year or two). Underscores seem to be shunned throughout .Net, and the F# library is no longer an exception (there are a few names left that use underscores, but they stand out now like a sore thumb and will probably be changed).

Regarding function style: I am unclear what you are asking. In the case of List.map, 'List' is the name of an F# module, and 'map' is a function in that module. Member functions (e.g. str.Length) have the advantage of being commonly used throughout .Net, and provide a nice intellisense experience in the editor.

Answer 2

1) I wouldn't go so far as to say monads are shunned... You mentioned you have some background with Haskell - so F# workflows are what you want to look into (the term workflow maybe confusing but these only have a tiny bit to do with business process stuff). In general, sequence expressions and more generally computational expressions (a.k.a workflows) are going to be close to monads. That said mutable is pretty common though I'm not sure 'preferred' would be the way to express it. They each have a place - Personally, I started with two books -- 'Foundation of F#' - but if you're looking to dive in - go 'Expert F#' -- both are good. Honestly, I needed Foundations to help me get started.

2) In the experience I've had, the confusion is that traditional functions in .NET have a convention that really doesn't lend itself to functional programming. As such, I feel that in F# you the confusion can sometimes be when you're looking at usage of 'traditional .NET' named functions vs. elements of F# that are clearly functional... For example, in the book I mention above 'Expert F#' - they mention that you'll see let values such as List.map and Dates.Today in both camelCase and PascalCase (Pascal case being a more traditional .NET). A good rule of thumb is that if you're staying in the functional world - use more traditional functional (camelCase) naming - however if what you're making is expected to be used by other .NET languages, go with the more .NET norm (Pascal). Also note in the functional world there is a much higher tolerance for abbreviation (itr, tbl, etc... ) where as .NET in general has went away from this... So again, you'll see a varying degree of this sort of thing based on if you're calling functional elements vs. elements exposed in F# that are shared across the whole of .NET.

3) I agree that the combination of OO and function styles can be confusing. Again, I'm not sure which is preferred, beyond saying that F# (being functional) clearly styles itself in terms of the functional paradigm. However, F# is a functional language in the .NET world (notice the relative confusion of naming I mention above)... So again, it's not totally clear cut.

Hope this helps... Believe it or not, as you use F# and think of other languages that have shared concepts C++ with C (for example) - it gets easier. Personally, the naming began to make sense and the concepts worked as I started to get that I was a F# is a functional language operating on a traditional platform - made to interoperate (though I'm not sure calling the interoperation seamless would be appropriate :D)

Answer 3

In general monads ("workflows" in F#) are much rarer than in Haskell, firstly because mutable variables are available so it's unlikely that people would choose to use a state monad instead. Secondly there are no higher-kinded type variables, which means that you can't write code that is overloaded to work on any monad, which makes using them much less attractive.

One place that they are commonly used is in sequence expressions (which are really like list comprehensions in Haskell, but those are closely related to the list monad).