The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

Hi Dave,
thanks for reporting this - you are absolutely correct - this should refer to listing 13! Added to the errata.

Tomas
Hi Josh,
thanks very much for reporting this. The two versions of the code should certainly be the same. I'll let Kit investigate what exactly is happening (I suspect there could be some issue with floating-point precision). In any case, I'll add it to errata to warn other readers!

Thanks,
Tomas
I just added this as the first item of our errata, thanks for reporting this!

T.

PS: Looks like copy-paste errors do not happen just when coding smilie.
Hello, sorry for a slow reply.

This is taking a bit of time because we need to manage contributions from all the different authors. We'll definitely get the repository setup for the next review (once the last chapter is added).

Thanks,
Tomas
Hi Vasily,
thanks very much for your comments (and also for the extended discussion on Twitter). We will have a detailed look at all your feedback and make sure that we address your points.

The chapter 13 is less "cutting-edge" functional chapter, because it discusses compromises that some F# developers may need to make (or find useful to make) in the corporate "enterprise" environment where they need to interoperate or collaborate in larger team mostly used to C# programming patterns.

Your feedback is extremely useful, because it shows that we have failed to explain these compromises (or did a bit too many of them). We'll certainly review this and make sure to either, follow your advice, or clearly explain why a "better" solution was not used (because of some other constraints).

I agree that using F# in a more functional style leads to better code - and we have other chapters showing how to do that - but there are many ways to success with F# and we wanted to show multiple of them.

Thanks,
Tomas
Hello,
thanks for the feedback - this is an unfortunate consequence of how the typesetting process works at Manning. In the final version, the marks (like #A) will be turned into some visual elements and so they will not confuse the copy & paste.

We are working on putting together a github repository with all the samples, so that people do not need to copy code from the documents.

Thanks,
Tomas
Hi,
thanks for reporting this, it really makes the text a bit confusing! I added it to the Errata (available here: http://functional-programming.net/errata.aspx)
Hi, are you referring to the "factorials" value defined in listing 12.4? If yes, the problem is that the function doesn't actually define an infinite factorial - it only demonstrates how to define recursive sequence, but infinite sequences are discussed later (section 12.2.2). The "factorials" value only returns factorials smaller than 1000000, and there are less than 20 of them - you can remove the "if" condition from the listing 12.4 to get an infinite sequence.
Hi, thanks for reporting this and sorry to keep you from Jon Skeet's book!
The Errata is available on the book's web site: http://functional-programming.net/errata.aspx (and I'm updating it right now). I'll check with Manning to make sure we add a link to the book page at Manning.com.

Thanks!
Tomas
Thanks for reporting this issue. Added to the list smilie.

Tomas
Thanks for reporting this. I'm adding it to errata. What a silly typo!

I'm glad you like the book so far!
Tomas
Hi,
I don't see any error in this piece of code, but I may be missing something!
Does the 'readInput' function in your environment have the right type? It should print:

> readInput;;
val it : (unit -> int option) = <fun:it@3>

Also, I see the 'Option<int>' type in the output, which is confusing as F# usually prints 'int option' when printing the type of standard F# option type. If you tried running your own defintion of the option type in FSI (e.g. the one on page 126), then the "Some" and "None" constructors of your type would hide the pre-defined F# constructors. As a result, your value 'Some 10' would be a value of your 'Option<int>' type (which is different to standard F# 'int option').

Hope this helps!
T.
Yes, these two are actual bugs. Thanks for reporting them!

Tomas
Great smilie, I'm glad I don't need to add anything to Errata, but if we'll going to do a second edition, we should definitely add some warning about this.
Hi Paul,
yes, you're right, it should be "ofSeq". This is one of the renamings I did in the late phase, so it looks that I've made some mistakes. Thanks for reporting this, I'm just updating the book's web site, so I'll add this to the errata.

Tomas
Hi,
yes, this is indeed a typo. Adding to the errata...

Thanks,
Tomas
Hi,
Thanks for the feedback - we've already fixed this - "Character" should be "GameCharacter" in all of the places you mentioned.

T.
Hi,
thanks for the feedback - I believe this has been already corrected during proofreading. It should be fixed in the final version. Expect final PDF version soon smilie...

Tomas
Hi Martin,
thanks for the feedback - this has been already corrected during proofreading (which also means that the book should go to the print soon!).

T.
Hi Martin,
Thanks again for reporting this issue. It'll be fixed in the final version!

Tomas
Hi Dimitris,
I was thinking about using Rx as well. I'd definitely use it if it was standard part of .NET 4.0, but that applies only to the IObservable type (which will be mentioned, because it'll be also used by F#). However, the LINQ query capabilities for working with IQueryable are still experimental and a bit hard to use. I'll make sure that my examples are as close to Rx as possible, so that most of the code will work with Rx as well.

Regarding tuples - that's also a good point. I'll make sure the code works with .NET 4.0 tuples.

Thanks,
Tomas
Hi,
First of all, your version of the code for generating nunmbers (based on the factorial example) is better option than the code used in the sidebar. Caching is more a workaround for situations when you can't write it more nicely (but I don't think it's used very often).

Regarding the internal workings of "nums" - the important thing is that seq<'a> type is the IEnumerable<T> type (and not IEnumerator<T>smilie. This means that when we work with it, we always have to ask it to start generating elements one by one from the beginning. So, when you start pulling elements from "nums", it yields 1 and then gets elements from "nums" again.

Now, if we don't use Seq.cache, then the "for" loop simply re-evaluates "nums" starting from the first element (so we're creating a chain of sequences that reference each other and each new element adds one sequence). When we use "cache", then the "nums" sequence contains a list of already generated elements. When we start reading elements from it (we still have to create a new IEnumerator to do that), it first returns all already generated elements. If we ran out of elements, it would generate more using the code in sequence expression. That doesn't happen in the case here, because before we need Nth element, we're already generating N+1th element.

I hope this helps at least a little bit - understanding this kind of code in F# can be really difficult, because there are quite a lot of hidden side-effects. I'll add a note that this is example only for curiosity and that a version implemented like yours (based on factorial sample) would be more idiomatic and better F#.

Thanks for the feedback!
Tomas
Yes, thanks for the reminder. I'm updating the manuscript for the Beta 1 version right now, so this should be fixed. But I have to say, "Future" sounded much better to me...

Tomas
Hi,
yes, I admit that relation between this way of using discriminated unions and the Decorator Pattern is a bit tenuous. However, that's probably always the case when looking for some relations between FP and OO code. The similarity I see is mainly in the structure they represent. Not in the goals and problems they try to solve. But that's all determined by the fact that in functional design, you're more often working with sealed choices and you have different kinds of problems than when developing OO systems.

I believe the key problem in functional programming is designing the data structure and I hope that the relation with OO pattern can suggest in which cases we can use discriminated union to represent something like decoration (the most famous example of Decorator Pattern with adding scrollbars to a widget would be probably solved like this in functional program).


>> In a functional language one does not need design patterns because the
>> language is likely so high level, you end up programming in concepts that
>> eliminate design patterns all together.

I know people often say that, but I'm not really convinced. It doesn't need object oriented design patterns, but it may need some different patterns. After all, patterns just describe common solutions to tricky problems, so the statement above essentially says that there are no difficult problems in functional programming smilie I wish that would be true...

An interesting discussion about this topic is here:
http://stackoverflow.com/questions/327955/does-functional-programming-replace-gof-design-patterns
Hi, that's a good point - I'm renaming it right now, it'll be fixed in the next version.

Thanks!
Tomas
Hi,
Yes, I believe clarity of the code is often underestimated in functional programming - hopefully this will change now that it's becoming main-stream. However, I think hiding of values is quite basic feature of functional languages, so I don't think this is the biggest source of "evil", but it definitely needs to be used with care! It can be mis-used to write nasty things smilie.

>> my comments may sound negative, but they don't mean to be. I'm glad you
>> wrote the book and I think it needed to be written and hopefully it will help lots
>> of readers transition to a more "functional" mindset.

Not at all! I'm finding your comments very useful and I believe that the changes I did based on your feedback will make the book better & easier to understand. Thank you very much for your time spent on this forum!

Tomas
Hi,
thanks very much for the error report and feedback! The bug in listing 7.2 should be fixed in the next version. Regarding Unechecked.defaultof - I probably wouldn't use it in this case, because when working with .NET types, we can use the 'null' value, so it's easier and arguably also safer to just use 'null'.

F# doesn't like 'null', but it doesn't like 'defaultof' either. In fact 'defaultof' is even more "dangerous" than 'null', because it can be used for assigning 'null' values to references to F# classes, which isn't otherwise possible.

There is some discussion about 'defaultof' in chapter 11 (where we mention that it can be used if you're writing code that can be called from C# - the C# user can give you a null reference in a place where F# compiler doesn't allow you to use 'null' so you can't write "reference <> null" and have to use defaultof instead).

Thanks!
Tomas
Hi,
I've already fixed the last one in the manuscript (when updating everything to work smoothly with latest F# version). I'll fix the two other issues when I'll get the chapter back from copyediting (the next phase on the way to a printed book smilie ).

Thanks for the bug reports!
Tomas
Hi,
thanks for reporting this - you're right the listing is wrong. I wanted to write the folding with 1 as the initial value (I'm not sure how "5" appeared there):

>> [ 1 .. 5 ] |> List.fold (*) 1

Regarding fold_left - yes, that's deprecated with F# "beta 1". I'm just updating all the source code for this version, so this is corrected in the manuscript now.

Thanks (and thanks for your other posts too - I'll eventually get to all of them).
Tomas
Thanks!
I'm just editing chapter 6, so I'll try to add something like this to the manuscript. I hope there is still some space for this!

Tomas
Hi,
thanks for the feedback. I originally thought about having a similar example in the chapter (at least it should be in the online source code you can download from www.functional-programming.net), but then, I wasn't really sure whether I should put it in the book or not.

In this case, the code using function composition isn't particularly shorter and to me, it doesn't seem to be more elegant. In fact, I think it's less readable then the straightforward version, so I probably wouldn't use it. It seems to me that function composition is used less often in F# than for example in Haskell. That said, it's still, no doubt, an important functional construct, but I think a simple example is enough for an introductory book.

Regarding your the code samples, the online source code contains this version (using just one function composition):
let names = places |> List.filter (snd >> ((<smilie 1000000)) |> List.map fst

The issue you're facing with the second example is "Value restriction" (see for example http://strangelights.com/fsharp/wiki/default.aspx/FSharpWiki/ValueRestriction.html). The problem is that when you define "findNames" it is a value intead of a function and values like this cannot be declared as generic. This means that the compiler needs to know the exact type. If you want to make it generic, you'll need to turn it into a function by writing:

let findNames x = x |> List.filter (snd >> ((<smilie 1000000)) >> List.map fst

I hope this answered your questions. I'd be still happy to include some more examples of function composition somewhere in the book, but I think this example may scare some people and isn't really showing the best F# programming practices (at least from some point of view).

Thanks!
Tomas
Hi,
yes - you're of course right. The "!" operator (for working with reference cells) is actually discussed in chapter 8, I just didn't realize that when categorizing all the allowed operator characters in chapter 6. It looks like I'll have to move it to the "other characters" category!

Thanks!
Tomas
Hi, thanks again for your reply.

I was just reviewing the chapter 5, so I added a brief sidebar explaining the motivation for this design (based on my previous post here). I believe it'll be helpful to readers who are wondering the same thing as you!

>> why it is preferable to keep "Map" and "Bind" as extension
>> rather than instance methods - unless it is simply the opportunity
>> for adding similar functions later without the need to re-compile
>> existing client objects

My motivation was mainly to follow the functional style in F# (and functional programming). I think the motivation for this in F# is the ability to add similar processing functions. In fact, the F# libraries have about 13 methods for procesing option values, but only a part of them are in the core F# library. The rest is located in PowerPack, so they benefit from this design choice.

Anyway, thanks again for your (very useful) feedback!
Tomas
Hi,
this is a difficult question. In this case, your implementation is perfectly correct and it is definitely better, because it follows the object-oriented/C# coding standards.

The book uses an alternative style, because it more closely resembles the F# types and I was hoping that this will make it easier to understand how things work in F# (I'm writing a note that I should explicitly say that in the book, thanks!).

The most important thing is that once you have "MatchNone" and "MatchSome" you can keep "Map" and "Bind" as extension methods (because they can be implemented using the two Match methods). I'd prefer that because there are other operations that you may want to do with option values and in the functional desing you'd probably add/remove them more often.

From the strictly object-oriented point of view, "MatchNone" and "MatchSome" are wrong just like type codes. These methods fully reveal the structure of the class hierarchy (just like Tag) and it makes it impossible to add a new subclass without modifying the base class (and adding "MatchNewSubClass" method). However, the point of discriminated unions in functional programming is that they make it easy to add new operations, which is possible only when we reveal the whole class hierarchy.

However, "discriminated unions" are probably the only thing that conflicts with any object-oriented guidelines. Otherwise the functional and object-oriented styles play very nicely together and I guess the when writing functional code in C# you just won't use "discriminated unions" (encoded in C#) as often as you'd use them in F#.

Hope this clarifies the point and thanks for asking the question - I'll try to add some explanation to the manuscript as well.

Tomas
Hi, thanks for your post.
In general, things like this should be fixed during copyediting, but this one was particularly tricky typo, so thanks for reporting it! I just fixed it in the manuscript.

Tomas
Thanks again!
I just got the chapter for the final review and nobody noticed this problem so far! I'm correcting it right now...

T.
Hi, thanks for the feedback!
It definitely takes some time to learn how to read F# type signatures (especially because currying which is an important aspect is explained at the end of chatper 5). I like the idea of adding "stub" declaration of the function to make it easier to understand this bit, so I just added that to the manuscript.

Thanks again for the suggestion,
Tomas
Hi,
that's a good point. When I was reading the section I also thought it sounds a bit wrong. I think it may be occasionaly useful to ignore the success flag - in some cases, 0 or false are reasonable default values. In that case it may be better to use "snd" and avoid declaring value (succ) which isn't and shouldn't be used anywhere.

Regarding the function - I guess I forgot about this when writing chapter 6. Thanks for pointing that out. I'll remove the reference, because after reading chapter 6 you should know enough to write a function like this:

let defaultParsed defaultValue (succ, value) =
...if succ then value else defaultValue

defaultParsed (-1) (Int32.TryParse(str))

Using the pipelining operator from chapter 6 you could write the same thing like this:

let n = Int32.TryParse(str) |> defaultParsed -1

Thanks!
Tomas
Hi,
thanks for pointing this out. I'm not sure how it's possible that we've missed that!

Tomas
Hi,
thanks for the feedback - it'll be corrected in the final version.

Tomas
Hi,
thanks for the feedback - I added a brief note about the attribute, so that the readers know this is another option.

Tomas
Hi Ayende,
thanks for the feedback. I fixed the chapter so that it mentions short circuiting now. Anyway, your note about big distinction between short circuiting and lazy evaluation is a bit surprising to me. I'd say that short circuiting is just a (simpler) special case of lazy evaluation, with laziness declared only on the callee side (operator) as oposed on both sides which is typical in F# (Lazy<T> on callee side and 'lazy' keyword on caller side).

I'd be interested in your thoughts on this issue! BTW: Sorry for the late response. I'm checking the forum usually when I get to review the specific chapter.

Thanks!
Tomas
Hi Vladimir,
thanks for reporting this issue. It'll be fixed in the final version! Surprisingly, nobody else noticed this so far!

Tomas
Hi,
thanks for reporting this - you're of course correct. I've fixed the issue just now. The problem is that when showing folding in chapter 3, it is more natural to show fold right, so I have to change the source code in chapter 6 to show fold left.

Thanks!
Tomas
Hi,
thanks for reporting this! It'll be fixed in the next version.

Tomas
Hi,
thanks for the feedback - you're right. In a bigger application it would be quite useful to define a type alias for this. I'm often trying to make the code a bit simpler and focus only on some aspects, so I didn't do that.

However, there will be an inline annotation right in the listing (in the final version), so the code should be easy to follow. Same thing could be achieved by adding a code comment (but it's of course better to make the code more self-explanatory when possible).

Thanks!
Tomas
Hi, thanks for reporting the issue. I just fixed it while finalizing chapter 6, so it'll be corrected in the final version.

Thanks for catching this!
Tomas
Hi, I'm glad you're finding the book and the examples useful! Thanks for reporting the issue - you're right there is a typo in the example. I'll change the code of the listing so that it produces the expected output like this:

let (+>smilie a b = a + "
>> " + b;;
printfn ">> %s" ("Hello world!" +>
"How are you today?" +>
"I'm fine!");;

Output will be:

>> Hello world!
>> How are you today?
>> I'm fine!

Thanks!
Tomas
Thanks again - I just corrected this in the manuscript.

Tomas
Hi, thanks again - all of these errors should be now corrected.

BTW: the book will go through proof-reading later during the editing, so minor bugs like these should be found later. But It's of course useful if you report the bug when you spot one, so that we can fix it as soon as possible.
Hi,
thanks very much for the report. All of them are now fixed in the manuscript.

Tomas
Hi Anthony,
thanks for a careful reading - I'm just correcting these typos in the manuscript.

Tomas
Hi David,
I'm glad to hear that you're enjoying the book so far! Thanks very much for all the points - we haven't discovered any of them, so your feedback was very useful! I just fixed these isssues in the manuscript, so they should all be fixed in the next version (and in the final printed version too!)

Thanks,
Tomas
Hi,
sorry - it looks like the web server doesn't allow files with the "fs" extension. You can get the file from this url for now: http://www.functional-programming.net/files/parallel.fs.txt. I'll update the page with all the sources soon, so all the code will be also available here: http://www.functional-programming.net/sources.aspx
Thanks for the hint. Unfortunatelly it's on a shared web hosting, so I'd have to ask the administrator to do that. I think we'll remove the direct link from the book anyway, so once it'll be in the "Source" section on the web site, it should be okay.
Hi,
I'm just doing some final edits, so this should all be covered now.

Thanks!
Tomas
Hi,
we've also restructured the TOC a little bit, so for example what was originally in chapter 17 (interactive & explorative working with data) has been moved to chapter 13, so I believe we won't miss anything important even though the book will have less chapters.
Hi,
I'm glad you liked the book so far and that you find it useful to show C# and F# side-by-side! Regarding your comments - it seems that we've already fixed most of them during reviews with Jon Skeet, but thanks for sending them anyway! We did a lot of editing in the earlier chapters - hopefuly the new release should be ready soon.

Tomas
Hi, I think I already fixed this one - but thanks for reporting it.
It's much better to have it reported two times rather than zero-times!

Tomas
Hi,
it's great that you reported this even though you realized what we meant originally - many readers may have a similar question, so it's good to know that the diagram isn't that clear. We'll definitely take a look at how it could be improved!

Thanks for the report!
T.
Hi, thanks for sharing your notes! I'm glad you're enjoying the book so far.

>> typo on page 76:
This one has been already fixed by the review Jon Skeet did, but thanks for reporting it!

>> In section 2.5.3, you describe a number of popular functional languages.
We removed this section from chapter 2 (though other programming languages are mentioned in various places somewhere else in the book, so it isn't lost). Anyway, the reason for not mentioning OCaml is that it is very similar to F# and I wanted to point out other interesting directions than the one F# (and OCaml) follow.

>> Mathematical Purity
I think this has been improved a bit during the recent edits as well, but we'll take a look to make sure it is properly explained!

Thanks!
Tomas
Hi,
thanks for reporting this - even though we did some changes to the chapter already, the error was still there! It should be fixed in the next release.

Thanks,
T.
Hi,
thanks for the suggestion - that definitely needs to be clarified. I changed it to: "between the functional programming style (FP) demonstrated earlier and the usual object-oriented style (OO)", so that the sentence contains 'full name' for both of the abbreviations.

Thanks!
T.
Hi,
are you refering to the listing "Listing 6.16 Type inference process for 'Option.bind' function (F#)"? We changed the numbering a bit, so I just wanted to make sure we're talking about the same thing! If that's the case, the "#1" and other numeric references refer to the snippet showing the implementation of bind in the beginning of section 6.5.1. Is that what looks confusing?

I agree this needs some clarification (I was actually confused for a while when getting back to this too), but I'm not yet sure what are the typesetting options for this. Surely, we'll find something readable smilie.
Yes, this is actually a part that has been removed alltogether.
I think the next MEAP update should be ready in a few days.

T.
Hi, yes, it probably sounds a bit confusing, but I'm not sure whether changing the name of the delegate would be the right thing to do - the point is that you really could define a delegate type just like Func from .NET 3.5. I think we could change the sidebar like this (changes highlighted):

It added generics, so we could declare generic delegate like Func and use
the new anonymous methods feature to create them instead of writing named method:

delegate R Func<T1, T2, R>(T1 a, T2 b);
Func<int, int, int> add = delegate(int a, int b) { return a + b; }

Finally, .NET 3.5 and C# 3.0 came with several other changes. The Func delegate was added to the system libraries, so you no longer have to declare it yourself and C# added lambda expressions that allow us to write the same code in a much more succinct way:


Would something like this clarify it?
Hi,
yes that's right - thanks for reporting this. It will be fixed in the next MEAP release!

Tomas
Thinking of this again - "average" won't really work because it needs to sum the values anyway. Looks like I'll have to think of something else smilie. Anyway, thanks for pointing this out!
Hi David,
thanks for the feedback - I agree that this isn't the best example. It demonstrates the idea, but it should be something that doesn't rely on integer overflow...
I'll think about it in more detail, but a quick idea would be to replace "sum" with "average". That should work for both of the examples.

(And I'm glad you liked the book so far!)

Thanks!
Tomas

Message was edited by:
tomas.petricek
Hi,
there were some changes in chapter 2 since the last update, so I believe this is already corrected. Anyway, thank you very much for finding the time to send the feedback!

T.
Hi,
this has also changed since the last update smilie. The new version shows how a simiar thing would look using standard C# switch and then using pattern matching in F# (after showing a declaration of the discriminated union).

Thanks
T.
Hi,
this is really difficult choice - I changed it back to standard C# and then back to pseudo-C# again. I didn't want to start with F#, because I wanted to make the chapter 2 as "light" as possible and the F# syntax could be difficult to read for some readers in the beginning.

Anyway, the reason why I ended up with pseudo C# is that I really want to be able to demonstrate how let-bindings (that are also expressions) work - the fact that you can write (using the pseudo-C#):

return x > y ? 0 : { var rest = SumNumbers(x+1, y) in x + rest };

T.
Hi,
some of the parts have changed, so the chapter should be more coherent now (including coherency with chapter 1, because some things were oddly divided and repeated...)

However some of the sections still remain. I quite like some of the titles you suggest. I'll discuss this with colleagues, but I think the titles of (former) section 2.2.2 and 2.2 could be improved.

Thanks!
Tomas
Hi,
thanks for all the corrections. I'm doing some larger changes in the chapter 1, so this text has changed. Anyway, if you find smaller language issue, than don't worry about it. There will be a copyediting later to check this. If you find some part that you can't understand, than please, let me know, because that's more substantial thing to look at!

Thanks for your effort & I hope you're enjoying the book!
Tomas
Hi,
I'm doing some changes in the Chapter 1, so this example won't be (probably) included. Thanks for the suggestion anyway!

Tomas
Hi,
sorry for the late reply. Did you find a solution for this? The only thing I can see is that there may be spaces missing in the setSecond declaration. There should be some indentation (e.g. 2 spaces) on the subsequent two lines (let ... and (f, nsnd)).

Thanks,
Tomas
Thanks! I just corrected this in the manuscript.

T.
Hi,
Thanks - I just corrected these issues!

T.

PS: I'm looking at the chapter again now, so that's why I'm answering so late.
Hi,
Thanks for the suggestion. The application definitely looks better when this is included, but I don't want to complicate the source in the book. I'll add something like this at least to the source code (which should be shortly finally available).

Thanks,
Tomas
You're right.
The STAThread attribute should be there. I added it and also made the note about using Show in the F# interactive more visible (it was there only as an annotation).

Thanks,
Tomas
Of course! Just another renaming during writing smilie.
Thank you very much for careful reading!

Tomas
Hi,
I believe that this code demonstrates the idea even without being fully shown in the book text, but I'd be interested to know if you think this isn't the case!

I'll definitely add a more explicit note about this & I'll include everything in the source code.

Thanks,
Tomas
Thanks for the suggestion.
I'm not sure if it's needed to present this in the book text, but I'll mention that it'll be available in the online source code.
Another change that I did in the source after pasting it to Word smilie

Thanks for mentioning it!
Tomas
Hi,
That was a typo. Parentheses are required in F# in this case.

Thanks,
Tomas
Hi,
This should be now updated.

Thanks,
Tomas
Hi,
I think the classification is often a bit confusing. I guess you can imagine a OO language that would be purely immutable (and as a result, in some sense, functional). Declarative langauges are definitely another thing that would deserve mentioning (but wikipedia almost unifies declarative with functional, so it's a bit unclear (again) what does this mean).

Anyway, there will be larger changes in chapter 1, so this has changed quite a bit. I'm looking forward to the feedback regarding the new version (once it's out!)

Thanks,
Tomas
Hi,
thanks for the suggestion. I was writing this before F# CTP, so it used to work without these. I'll definitely mention that you should use "Add Reference" when working wtih WinForms and System.Drawing.

To get rid of the console window, you can go to the project properties and select "Windows Application" in the "Output type" drop-down. Another thing that should be mentioned in the book smilie!
Hi,
I know it may look confusing, but it wasn't a typo. F# gives quite a lot of flexibility how to write things, so I'm trying to choose the best way to make the book readable (and F# accessible) for .NET programmers.

My impression is, that from the following options, the third one looks the best:
let sumRest = (countSum tail)
let sumRest = countSum tail
let sumRest = countSum(tail)


Especially, since F# allows you to write (in OCaml, I think you'd have to use option 1 in this case):
let sumRest = countSum(tail) + 10

This also looks good when working with .NET methods:
let a = Math.Sin(10.0)
let b = sin(10.0)


I think this might help to make the .NET programming look more consisten in F#. I'd be very interested in hearing what you (and others) think about this, so please send all your comments and ideas smilie! The next MEAP release should contain these changes especially in chapter 4, so I'd love to hear whether this makes the F# code more readable for C# programmers.

Thanks!
T.
Hi,
yes - this is valuable when working with functions that take multiple arguments, because you can use functional tricks like pipelining operator and partial function application.

let add a b = a + b
[1..10] |> List.map (add 10)

.. you couldn't do that easily if add was declared as add(a, b) or when List.map was List.map(f, list). And of course, I'm going to use these using the classical functional style.

So I think the fact that functional programmers usually write "countSum tail" is to make it consistent with functions like this. F# is somewhere in between, so choosing the right thing is a bit tricky smilie

And again, thanks for your feedback!
Thanks for mentioning this.
Yes, you can write this without parentheses. I think I haven't really yet unified the way I write this in the book, so after reading your suggestion, I finally tried to find a good set of rules to follow.

When writing simple functions with single argument, I'll always write:
let sumRest = countSum(tail)

Even though the parentheses are optional, I think it makes the code more readable, so I'll follow this rule. Next MEAP release should use this consistently at least in chapters 3,4,5,6 (I'll edit others soon as well).
Thanks - that's a good point! I added it to the summary.

Tomas
Yes, they should be the same.
"severelyWarpedGeneticMutationTreeThatCausesHeinousStackOverflows" would be definitely a good name smilie, but I'll use "imabalncedTree". That's a bit shorter and also a bit more precise than "sillyTree", which clearly shows what I think about trees like this! But it's no doubt not a politically correct term!

Thanks,
T.
Hi,
Yes, that can be quite subtle. I added a brief mention to the text.

Thanks for a great suggestion (as always!)
Tomas
Yes, that's right.
Thanks for mentioning this!

T.
Heh,
I'd like to know what was I thinking when I wrote that smilie. Probably nothing...

Thanks,
Tomas
That's a very good suggestion. I added some explanation.

Thanks,
T.
Yes, I agree it sounds a bit odd. I'll think about someting better.

Thanks,
Tomas
Hi,
There is really nothing extraordinary about referencing F# library from F# application. However I agree that it may be useful to point this out explicitly. I'll add some side-note about this.

Thanks!
T.
Yes, that's true.
I'll add a note explaining that rather than updating the screenshot, because I think it is interesting to show that it works for more F# types (e.g that F# interface looks like an ordinary C# interface).

Thanks!
T.