13 Jan

Website Changes & Second Edition of Volume I

For some time now registration has not been required as all the material is on the web is freely available to any and all visitors. Moreover, whilst there have not been many (rejected) ‘spammer’ registrations, and the rate of hacking attempts has decreased slightly, I am keen to simplify and enhance security by removing the facility to register and logon to the website. This I intend do on February 1st, 2019. Thereafter the site will revert to just using the HTTP protocol rather than secure HTTPS and any registration data will be permanently deleted.

I do not intend any further updates of the website, as it stands, until later this year, when I will be re-publishing an alternate version to accommodate material for the second edition of Volume I.

The second edition is largely complete in its basic content (that is, it does require some further editing and the encoding of supporting videos) apart from the final part regarding multi/cross-platform UIs and the use of Visual Studio 2019. The move to Visual Studio 2019 removes all the ‘fudging’ required to get a workable F# environment in Visual Studio 2015. The material focuses almost entirely upon development of cross-platform code and applications using .NET Standard/Core with some testing via the Windows Subsystem for Linux, however, I am considering retaining a small section about using WPF because of its corporate legacy importance – the rest of the UI part would focus on Xamarin as there still appears to be no other choice. The nature of the content and its presentation have also been modified somewhat to reflect an F# usage more in line with what one may use it for in basic Data Science usage with a theme of reporting upon CITES (https://www.cites.org) sample data – although more advanced topics likes machine learning, computation expressions, type provider creation etc. will be presented in the later second edition of Volume II.

If you have any comments re. removing login/security from the site, or about the second edition of the book, please feel free to let me know.

04 Aug

Extending Marker Interfaces

In Volume II, Part VII, I use Yan Cui’s (@theburningmonk) concept of Marker Interfaces for “concatenating” unions (pp 86). The intent therein is to permit the user to “extend” the nature of the information that the ETW logging/instrumentation processes will log – although, the principle is useful in allowing a developer to “extend” any suitable marked-up union defined in a referenced assembly.

For other purposes I’ve reviewed this principle and now have found the method whereby it’s possible to extend the marker interface by adding properties and methods that will be automatically available to any user-defined union that implements a core defined marker interface. The method is depicted via three source files with an accompanying test script in the following image – note that I’m now using F#4.1 with .NET Framework 4.7 in the 2017 Community Edition of Visual Studio.

Extending Marker Interfaces - Source Code

Extending Marker Interfaces – Source Code

08 Mar

Video encoding

I have now finished re-encoding and replacing all of the videos for each volume. If you should discover a problem then please let me know via a comment to this post or send me an email.

The next task, for the website, is of the provision of an error/typo/bug log for the general review of errors, typos etc. in the material and posting (registered users) thereof.

06 Jan


Another mea culpa observed by André van Meulebrouck; when dealing with casting I am in error and not as consistent in defining and describing it as I perhaps should be – one of the many perils of proof-reading your own material! For example, on page 338 of Volume I, I incorrectly associate boxing with down-casting where it should be up-casting!

Let’s limit our scope of consideration to .NET Class Hierarchies – in this respect I mean the way in which object inheritance is depicted in the MSDN documentation. For example, the WPF FrameworkElement has the following inheritance hierarchy (in part – for the original click here)…

Inheritance Hierarchy Sample

This could also be “visualised” as a simplistic (asexual) genealogical family tree where the “originator”, the .NET System.Object, is at the top of the stack. If you want to see the “complete” family tree for WPF and .NET 4.5 have a look at this StackOverflow question – WPF 4 and .NET 4.5 class hierarchy poster.

When up-casting from the FrameworkElement one regresses through the ancestors – you go “up the family tree” to some point that may or may not terminate with the originator – the Object. Conversely, when down-casting, you go down through the descendants of FrameworkElement.

The up-cast operator :> is “static” – the compiler will let you know when you’re writing your code if there’s an error in your casting logic. Of course, you can always cast up the inheritance hierarchy to an Object but you cannot, for example, try…

let form = new Form()
let b5 = form :> TextBox

In this case the compiler knows, at design-time, that there is an error in your casting logic – TextBox is not an ancestor of Form in its inheritance hierarchy and the statement will be shown with a red squiggly – however, form :> obj will always “work” since, for .NET, Object is always at the root of the family tree. Consequently, when up-casting with :>, as long as your code compiles you won’t get a run-time type exception.

For down-casting, André proposes the mnemonic: The downcast operator :?> is downcast because it is sad that it can’t know at compile time whether the cast will work! Fair enough – I guess this is based upon emoticons – a “language” I am unfamiliar with!

06 Jan

Fold versus Reduce

André van Meulebrouck makes the comment that, in Volume I, there are instances where I should be using List.Reduce as opposed to List.Fold. I don’t deny that this is the case; firstly, let’s clarify the difference between the two functions as used for F# collections in general…

Fold requires a “starting value” into which elements are to be collated; the starting value can be any primitive F# type – I often use a string. Conversely, Reduce does not require a starting value consequently, the type used in the Reduce anonymous function must be of the same type as expressed by the collection (elements) one is folding.

I would be hard-pressed to quantify general processing performance differences between Fold and Reduce but I suspect that Reduce is faster since the accumulator and element value types must, by definition, all have the same primitive type. I guess the “general rule” about making a choice between the two is that if your accumulator is going to be the same primitive type as your collection elements then use Reduce – otherwise, use Fold since there will be some implicit casting involved – even if only in using the string representation (ToString()) of a collection element to enable the accumulator to “work”.

Contact Form

Contact Form

You may use this form to send me an email…
Click on the panel tab or elsewhere on the screen to close this panel.