My "slides" from my talk at F# Exchange were actually just a set of .fsx scripts this year, enabling me to play a bit live during the presentation.
If you're interested you can find them on my github account at https://github.com/mavnn/FSharpX2017.
Have fun!
@mavnn ltd have always offered training as a service, but we're now pleased to announce our very first public training event. As readers of this blog (or people attending F# Exchange), you get first notification!
"Level Up Your F#" is going to be a two day course running in London on the 15th-16th June. We'll run through a syllabus of language features unique to F# and not shared by the other dotnet languages - features that offer unparalleled expressive power at the cost of a learning curve and the occasional sharp edge. In the course we'll give you a leg up that curve, and protect you from a few cuts along the way.
This course will be aimed at people who have spent some time coding in F# (possibly after taking a course like the "Fast Track to F#") and realise that their projects could benefit from a deeper understanding of F# special abilities. These techniques are especially useful for writing generic, reusable code - whether that's core internal code or widely used libraries.
It will be a small group, allowing for personalization and some flexibility in design, but at its core it will be build up through four major topics:
Useful tricks: active patterns, member constraints, etc
Quotations: what they are, and how and when to use them
Type Providers: how to build them, and use them for type safety
Computational Expressions: build powerful abstractions and then expose them in an easy to use way
We're aiming for a cost of £1,295.00 for the course with early bird (10 15% until the 15th May) and group discounts available (contact us). Due to the nature of the course, there will be a hard limit of 12 attendees. There's also a limited quantity of super-early bird tickets available if you're quick! Register your interest soon to secure a ticket, and if there's a waiting list we'll consult you about
additional dates.
As always with @mavnn training courses, we're also willing to come and deliver this training on site and tailor it to your specific needs. Contact us at [email protected] to discuss requirements and quotes.
But why should I learn F#?
I'm glad you asked! With multiple languages targeting the CLR it can seem just to be a matter of preference. Do you like curly braces, or significant white space?
But it soon becomes apparent there's a bit more to it than that; at first you spot pattern matching and discriminated unions. And then you start noticing a bunch of other things which look cool… but it's not quite so obvious how to use them or what to do with them. Last year I was able to give a lightning talk at F# Exchange on some of these language features and the response was positive enough that I'm back at F# Exchange 2017 to give the full version.
So: whether it's active patterns, computational expressions, type providers or quotations I'll be running through practical examples of how these features can be used, and how to get started creating your own examples.
And apart from being hyped to give my own talk, it's going to be great to meet up with the F# community again and meet some new faces. The opportunity to meet in person people I've exchanged ideas with online (hi Marcus Griep, Dave Thomas, …!) is invaluable. And even for someone who's been around F# for a while like me, there's always new things going on; Puritas looks fascinating.
Looking forward to meeting a bunch of you there, and you should start seeing a bit more appearing on this blog again after the conference. The last year has been pretty intense, but I'm hoping to make some announcements of interest to the F# community over the next couple of months.
Is this where I'm supposed to say "watch this space"?
Each year I like to make my F# advent post centered around an aspect of the actual Christmas story, so this year I decided to look at the actual text of the Christmas story.
There are a couple of direct historical accounts recorded in the bible, in the Gospels of Mark and Luke. But Jesus's birth is a central point of the overall biblical story, with links to the Old Testiment books written before and referenced in places through the New Testiment.
Sounds like a graph to me, so lets see how far we can take some analysis.
Fortunately, someone has already produced a text file with a whole bunch of cross references in a nice regular format. So all we need to get started is a nice parser. We'll also want to pull in some metadata about the structure of the bible as a book in JSON format from the people at bibles.org.
Time to reference some dependencies to do our heavy lifting for us: FParsec for parsing, and FSharp.Data for the JSON type provider.
I'm writing this in the excellent Jupyter F# notebook (and then exporting it as markdown), so I'll use their Paket helpers to grab my dependencies (this should work on the Azure notebooks as well, although I've only tried it locally).
I spoke this morning at F# Exchange and this being SkillsMatter they've published the recording already.
It's a nice short talk, weighing in at about 15 minutes. So grab yourself a coffee and take a short tour of how some of F#'s more esoteric features (active patterns, computational expressions, quotations and type providers) have been used to solve real problems in the real world.
Video here: https://skillsmatter.com/skillscasts/7735-fixing-real-life-problems-from-the-ivory-tower
Slides here: https//blog.mavnn.co.uk/FromTheIvoryTower/
This is a "just because you can" post, although frankly bizarrely I have a genuine use case for this.
Let the mind melting commence!
Computational expressions in F# provide nice sugared syntax for monadic data structures such as seq and async; but the specific expressions are not built in language features. You can build your own.
Which is fun and all, but you know what's even more fun? Well, it turns out that there's no requirements for computational expressions to be actual monads. Even more fun than that is that the bind operation (used when you invoke let! syntax) is a member on a class - and it is valid both for it to be an extension method, and for it to be overloaded. You can even add custom operators to computational expressions using the extension method trick.
Which means you can do some very interesting things indeed to existing computational expressions. Let's try it out!
During the Type Provider Live recording, Ryan asked me about basing erased provided types on dictionary types, and then exposing nicely typed properties to access data stored within the dictionary.
This will sound familiar to users of a number of dynamically typed languages as in many cases objects in these languages are just dictionaries under the hood.
This is such a common thing to be doing in a type provider that I thought it was worth writing up a working example that can then be modified to your individual situation. I've presented the entire listing below with comments, but there is one particular trick I'll explain in a bit more detail. Let's have a look at let bindings in quotations!
I recently gave a live streamed tutorial on building type providers, which I've embedded below. Apologies for the sound; apparently Google Hangouts added a feature I was unaware of until after the stream started which mutes your microphone whenever you type.
Fortunately I think enough was preserved to be useful, and (amazingly!) all of the demonstrations actually worked.
If you'd like to try things out for yourself, there's a github repository at https://github.com/mavnn/CambridgeTypeProvider which contains 6 individual fsx files, one for each new feature added to the type provider.
There's a bunch of other type provider information scattered around this blog, if you're interested just click the "typeprovider" tag.
You can find EmParsec on GitHub: https://github.com/mavnn/EmParsec
Type providers, by their very nature, tend to access data external to the .net ecosystem. It can also be very awkward technically to make use of dependencies during the actual type generation process.
This is rather a pity, because accessing all of that external data is much nicer and easier when you have a decent parser to do it with. And F# has very, very nice parser support via the FParsec library. Instead, many (most?) type providers end up creating mini-one shot parsers which can be a bit slow to write and don't tend to have features that come for free in a more complete solution such as nice error reporting.
Writing yet an other parser (YAOP) this week I decided that enough was enough. What I needed was a shared resource that people could pool improvements for that could be easily embedded in projects like type providers were it isn't desirable (or sometimes possible) to take external binary dependencies.
So I built it.
An angel of the Lord appeared to them, and the glory of the Lord shone around them, and they were terrified. Luke 2:9
It's that time of year again, where the F# community get together to source a collection of weird, wonderful and occasionally useful blog posts on life, the universe and sometimes Christmas.
As mentioned in last years post, I like to go back to the source when it comes to advent posts, so lets dive back into the book of Luke (and learn about agent based programming as we go).