Recursive query comprehensions (F# 3.0) - f#

I am trying to define Bill Of Materials kind of queries using the recently introduced F# 3.0 query comprehension syntax. Though it is possible to define these kind of queries using yield! seq comprehensions for in-memory collections I had no lack in translating those into query comprehensions that target remotable IQueryable sources. I guess the hard part would be to "train" the provider into recognizing Common Table Expressions out of recursive patterns.
Any ideas?

Unfortunately, I don't think that the current query syntax support in F# 3.0 is capable of dealing with recursive queries. The main problem is that F# 3.0 relies on standard IQueryable implementations that were designed mainly for C# and so they do not expect recursive structures.
I think that supporting this would be quite difficult. You could either implement your own F# quotations to SQL translator (which is hard) or you could implement some sort of pre-processor that takes an F# quotation (query) that contains recursion and translates the recursion to something that the LINQ to SQL translator can deal with (but this is probably hard too).
In general, the approach would be to define your own query builder:
open System.IO
open Microsoft.FSharp.Quotations
type MyQueryBuilder() =
member x.For(a, body) = Seq.collect body a
member x.Quote(e) = e
member x.YieldFrom(s) = s
member x.Run(e:Expr<'T>) : 'T = failwithf "%A" e
// Example using the custom query builder
// (fails, printing the quoted query)
let mquery = MyQueryBuilder()
let n = [1 .. 10]
let rec nums a : seq<int> =
mquery { for b in n do
yield! nums b }
In the Run method, you get a quotation that represents the query. You could pre-process that and replace all calls to MyQueryBuilder with calls to standard query operations and replace recursion with something else. Then you could call query.Run (to run the standard IQueryable implementation).
Though as I said, this is probably going to be quite difficult to implement - but perhaps, if you have some specific kind of recursion that you can easily deal with, it might be an option. However, if LINQ to SQL does not generate Common Table Expressions for any standard patterns, then I don't think you can train it to generate them - as far as I know, the translator is not really extensible.

Related

F# "reverse" exhausting match on discriminated unions?

Taking the example of writing a parser-unparser pair for a DU.
The unparser function of course uses match expression, where we can count on static exhaustiveness check if new cases are added later.
Now, for the parsing side, the obvious route is (with eg FParsec) use a choice parser with a list of the DU case parsers. This works, but does not have exhaustiveness checking.
My best solution for this, is to create a DU_Case -> parser function that uses match expression, and using runtime reflection get all DU cases, call the function with them, and pass the so generated list to the choice combinator. This works, and does have static exhaustiveness checking, BUT gets pretty clunky fast, especially if the cases have varying fields.
In other words, is there a good pattern other than using reflection for ensuring exhaustiveness when the discriminated union is the output and not the input?
Edit: example on the reflection based solution
By getting clunky, I mean that for every case that has fields, I have to also create the field values dynamically, instead of the simple Array.zeroCreate(0) which is of course always valid. But what in the else branch? There needs to be code to dynamically create the correct number of field values, with their correct (possibly complex) constructors and so on. Not impossible with reflection, but clunky.
FSharpType.GetUnionCases duType
|> Seq.map (fun duCase ->
if duCase.GetFields().Length = 0 then
let case = FSharpValue.MakeUnion(duCase, Array.zeroCreate(0))
else
(*...*)

Monadic operations on Choice<'T1,'T2>

I could not find an object choice in the standard libraries, that allows me to write
let safeDiv (numer : Choice<Exception, int>) (denom : Choice<Exception, int>) =
choice {
let! n = numer
let! d = denom
return! if d = 0
then Choice1Of2 (new DivideByZeroException())
else Choice2Of2 (n / d)
}
like in Haskell. Did I miss anything, or is there a third-party library for writing this kind of things, or do I have to re-invent this wheel?
There is no built-in computation expression for the Choice<'a,'b> type. In general, F# does not have a built-in computation expression for the commonly used Monads, but it does offer a fairly simple way to create them yourself: Computation Builders. This series is a good tutorial on how to implement them yourself. The F# library does often have a bind function defined that can be used as the basis of a Computation Builder, but it doesn't have one for the Choice type (I suspect because there are many variations of Choice).
Based on the example you provided, I suspect the F# Result<'a, 'error> type would actually be a better fit for your scenario. There's a code-review from a few months ago where a user posted an Either Computation Builder, and the accepted answer has a fairly complete implementation if you'd like to leverage it.
It is worth noting that, unlike in Haskell, using exceptions is a perfectly acceptable way to handle exceptional situations in F#. The language and the runtime both have a first-class support for exceptions and there is nothing wrong about using them.
I understand that your safeDiv function is for illustration, rather than being a real-world problem, so there is no reason for showing how to write that using exceptions.
In more realistic scenarios:
If the exception happens only when something actually goes wrong (network failure, etc.) then I would just let the system throw an exception and handle that using try ... with at the point where you need to restart the work or notify the user.
If the exception represents something expected (e.g. invalid user input) then you'll probably get more readable code if you define a custom data type to represent the wrong states (rather than using Choice<'a, exn> which has no semantic meaning).
It is also worth noting that computation expressions are only useful if you need to mix your special behaviour (exception propagation) with ordinary computation. I think it's often desirable to avoid that as much as possible (because it interleaves effects with pure computations).
For example, if you were doing input validation, you could define something like:
let result = validateAll [ condition1; condition2; condition3 ]
I would prefer that over a computation expression:
let result = validate {
do! condition1
do! condition2
do! condition3 }
That said, if you are absolutely certain that custom computation builder for error propagation is what you need, then Aaron's answer has all the information you need.

Why is there no Seq.partition in F#

In F# we have List.partition and Array.partition which return a tuple of lists and a tuple of arrays respectively.
so, why is there no Seq.partition returning a tuple of sequences?
here is a very simple implementation:
F# Snippets
so... why isn't this part of the core?
In F# 4.0 (Visual Studio 2015), the core libraries are a lot more uniform than before, but they still do not come with an implementation of Seq.partition. You can find more about this in the F# language design discussion: Regular functional operators producing two or more output collections.
The summary is that the Seq.partition function is quite tricky and a having it could introduce potential performance issues. There a couple of ways it can work:
It can iterate over the input collection twice (like the FsSnip version), which can cause issues if you have complex delayed computation (you're doing everything twice)
It can iterate over the input once, but then it would have to do some complex mutable state sharing (which could secretly allocate memory).
So, Seq.partition cannot be implemented reasonably while keeping all the good properties that you would expect about the seq<'T> type.
Seq.partition is just a specialized version of Seq.groupBy, so the standard library could implement the former as a wrapper around the latter without introducing any new issues.
let partition predicate source =
let map =
source
|> Seq.groupBy predicate
|> Map.ofSeq
let get flag =
map
|> Map.tryFind flag
|> Option.defaultValue Seq.empty
get true, get false

F# seq<float> to ILNumerics in functional style

I have a F# query that returns seq<float>.
I was wondering how I could stuff the data within the seq<float> in a ILNumerics dense array (http://ilnumerics.net/FunctionRules.html) using an F# idiomatic functional style.
The data in the seq may correspond to a row, a column or the entire dense array.
References to F# code are also welcome.
Looking at the C# example on this page, something like this should work
let toILNUM input = array(input |> Seq.toArray)

IEnumerable<T> in OCaml

I use F# a lot. All the basic collections in F# implement IEumberable interface, thus it is quite natural to access them using the single Seq module in F#. Is this possible in OCaml?
The other question is that 'a seq in F# is lazy, e.g. I can create a sequence from 1 to 100 using {1..100} or more verbosely:
seq { for i=1 to 100 do yield i }
In OCaml, I find myself using the following two methods to work around with this feature:
generate a list:
let rec range a b =
if a > b then []
else a :: range (a+1) b;;
or resort to explicit recursive functions.
The first generates extra lists. The second breaks the abstraction as I need to operate on the sequence level using higher order functions such as map and fold.
I know that the OCaml library has Stream module. But the functionality of it seems to be quite limited, not as general as 'a seq in F#.
BTW, I am playing Project Euler problems using OCaml recently. So there are quite a few sequences operations, that in an imperative language would be loops with a complex body.
This Ocaml library seems to offer what you are asking. I've not used it though.
http://batteries.forge.ocamlcore.org/
Checkout this module, Enum
http://batteries.forge.ocamlcore.org/doc.preview:batteries-beta1/html/api/Enum.html
I somehow feel Enum is a much better name than Seq. It eliminates the lowercase/uppercase confusion on Seqs.
An enumerator, seen from a functional programming angle, is exactly a fold function. Where a class would implement an Enumerable interface in an object-oriented data structures library, a type comes with a fold function in a functional data structure library.
Stream is a slightly quirky imperative lazy list (imperative in that reading an element is destructive). CamlP5 comes with a functional lazy list library, Fstream. This already cited thread offers some alternatives.
It seems you are looking for something like Lazy lists.
Check out this SO question
The Batteries library mentioned also provides the (--) operator:
# 1 -- 100;;
- : int BatEnum.t = <abstr>
The enum is not evaluated until you traverse the items, so it provides a feature similar to your second request. Just beware that Batteries' enums are mutable. Ideally, there would also be a lazy list implementation that all data structures could be converted to/from, but that work has not been done yet.

Resources