Does the order of query expression operators matter? Idk, but sometimes (in some selections) it does, but sometimes it doesn't (or maybe it does but implicitly handles some particular occasions).
Is is mandatory that select operator must go last? in pretty much every combination it complains if you don't write it as a last statement, but in case of take n, this operator can go after select
I'm just interested in how the process of execution acts?
This brings me to another question. If it iterates over Iterable collection, and thus on the first iteration it selects some one(first) value, how order works on that one(first) value? it would be clear if first it returned sequence, and then executed order on that sequence.. but seems like it executes sortBy at every iteration (?). I'm interested in what the design of the executed algorithm is.
Here is my example of Query Expression.
let sq = query {
for p in datasource do
where p.age>20
sortBy p.age
select p
}
Explanations would be greatly appreciated.
Thanks
We don't need to guess, we can find out.
let sample = Seq.init 10 (fun i -> i * 10) |> Seq.map (fun i -> { age = i })
let sq = query {
for p in sample do
where (p.age > 20)
sortBy p.age
select p
}
sq |> Seq.toList |> ignore
The generated IL (cleaned up) looks like
IL_004e: newobj instance void Program/sq#16::.ctor(class [FSharp.Core]Microsoft.FSharp.Linq.QueryBuilder)
IL_0053: callvirt instance [...] For<class Program/Person,
IL_005d: callvirt instance [...] Where<class Program/Person,
IL_0067: callvirt instance [...] SortBy<class Program/Person,
IL_0071: callvirt instance [...] Select<class Program/Person,
Suppose we change the order of sortBy
let sq = query {
for p in sample do
sortBy p.age
where (p.age > 20)
select p
}
The new IL will be:
IL_006c: callvirt instance [...] For<class Program/Person,
IL_0076: callvirt instance [...] SortBy<class Program/Person,
IL_0080: callvirt instance [...] Where<class Program/Person,
IL_008a: callvirt instance [...] Select<class Program/Person,
You can clearly see that it follows the exact order you define the query in.
This wouldn't matter for T-SQL comprehensions because the query will be translated by an Expression visitor, but for object queries, query expressions are pretty much just syntactic sugar for you.
Method #2:
You can extend the query expression module to include an operator for side-effects. This is simply a port of Interactive Extensions' DoAction method.
module QueryExtensions =
type QueryBuilderEx() =
inherit Linq.QueryBuilder()
[<CustomOperation("doAction", MaintainsVariableSpace = true)>]
member __.Do(source : Linq.QuerySource<'T,System.Collections.IEnumerable>, action) =
new Linq.QuerySource<'T,System.Collections.IEnumerable>(source.Source |> Seq.map (fun v -> action(v); v))
let query = QueryExtensions.QueryBuilderEx()
Now you can debug the order like so
let sq = query {
for p in sample do
sortBy p.age
where (p.age > 20)
doAction (printfn "Next -> %A")
select p
}
If you move it above the where, you'll see that it reflects those records before filtering.
Related
F# does not (currently) support type-classes. However, F# does support the OOP aspects of C#.
I was wondering, what is lost doing this approach compared to true type-classes?
// A concrete type
type Foo =
{
Foo : int
}
// "Trait" for things that can be shown
type IShowable =
abstract member Show : unit -> string
module Showable =
let show (showable : IShowable) =
showable.Show()
// "Witness" of IShowable for Foo
module Foo =
let asShowable (foo : Foo) =
{
new IShowable with
member this.Show() = string foo.Foo
}
// Slightly awkward usage
{ Foo = 123 }
|> Foo.asShowable
|> Showable.show
|> printfn "%s"
Your suggestion works for simple typeclasses that operate on a single value of a type, like Show. However, what happens when you need a typeclass that isn't so object-oriented? For example, when we want to add two numbers, neither one corresponds to OO's this object:
// not real F#
typeclass Numeric<'a> = // e.g. Numeric<int> or Numeric<float>
abstract member (+) : 'a -> 'a -> 'a // e.g. 2 + 3 = 5 or 2.0 + 3.0 = 5.0
...
Also, keep in mind that many useful typeclasses require higher-kinded types. For example, consider the monad typeclass, which would look something like this:
// not real F#
typeclass Monad<'m<_>> = // e.g. Monad<Option<_>> or Monad<Async<_>>
abstract member Return<'a> : 'a -> 'm<'a>
abstract member Bind<'a, 'b> : 'm<'a> -> ('a -> 'm<'b>) -> 'm<'b>
There's no good way to do this with .NET interfaces.
Higher-kinded type classes are indeed impossible to model with interfaces, but that's just because F# does not support higher-kindedness, not because of type classes themselves.
The deeper thing to note is that your encoding isn't actually correct. Sure, if you just need to call show directly, you can do asShowable like that, but that's just the simplest case. Imagine you needed to pass the value to another function that wanted to show it later? And then imagine it was a list of values, not a single one:
let needsToShow (showable: IShowable) (xs: 'a list) =
xs |> List.iter (fun x -> ??? how do I show `x` ???)
No, this wouldn't do of course. The key is that Show should be a function 'a -> string, not unit -> string. And this means that IShowable itself should be generic:
// Haskell: class Showable a where show :: a -> String
type IShowable<'a> with
abstract member Show : 'a -> string
// Haskell: instance Showable Foo where show (Foo i) = show i
module Foo =
let showable = { new IShowable<Foo> with member _.Show foo = string foo.Foo }
// Haskell: needsToShow :: Show a => [a] -> IO ()
let needsToShow (showable: IShowable<'a>) (xs: 'a list) =
xs |> List.iter (fun x -> printfn "%s" (showable.Show x))
// Haskell: needsToShow [Foo 1, Foo 42]
needsToShow Foo.showable [ { Foo: 1 }; { Foo: 42 } ]
And this is, essentially, what type classes are: they're indeed merely dictionaries of functions that are passed everywhere as extra parameters. Every type has such dictionary either available right away (like Foo above) or constructable from other such dictionaries, e.g.:
type Bar<'a> = Bar of 'a
// Haskell: instance Show a => Show (Bar a) where show (Bar a) = "Bar: " <> show a
module Bar =
let showable (showA: IShowable<'a>) =
{ new IShowable<Bar<'a>> with member _.Show (Bar a) = "Bar: " + showA.Show a }
This is completely equivalent to type classes. And in fact, this is exactly how they're implemented in languages like Haskell or PureScript in the first place: like dictionaries of functions being passed as extra parameters. It's not a coincidence that constraints on function type signatures even kinda look like parameters - just with a fat arrow instead of a thin one.
The only real difference is that in F# you have to do that yourself, while in Haskell the compiler figures out all the instances and passes them for you.
And this difference turns out to be kind of important in practice. I mean, sure, for such a simple example as Show for the immediate parameter, you can just pass the damn instance yourself. And even if it's more complicated, I guess you could suck it up and pass a dozen extra parameters.
But where this gets really inconvenient is operators. Operators are functions too, but with operators there is nowhere to stick an extra parameter (or dozen). Check this out:
x = getY >>= \y -> getZ y <&> \z -> y + 42 > z
Here I used four operators from four different classes:
>>= comes from Monad
<&> from Functor
+ from Num
> from Ord
An equivalent in F# with passing instances manually might look something like:
let x =
bind Foo.monad getY <| fun y ->
map Bar.functor (getZ y) <| fun z ->
gt Int.ord (add Int.num y 42) z
Having to do that everywhere is quite unreasonable, you have to agree.
And this is why many F# operators either use SRTPs (e.g. +) or rely on "known" interfaces (e.g. <) - all so you don't have to pass instances manually.
Is it possible to use lambda-style querying of IQueryable objects in F#, instead of query expressions? Something like:
type schema = SqlDataConnection<"Data Source=(local);Initial Catalog=MyDatabase;Integrated Security=true;">
let db = schema.GetDataContext()
let q = db.MyTable |> Seq.filter (fun r -> r.id < 100) |> Seq.take 10
let result = q |> List.ofSeq
When I profile this it is doing select * from MyTable so I assume the filter and take are being executed on IEnumerables not IQueryables?
Or is the only way to fix this to use query {} without lambdas?
The reason is that Seq.toList calls the data struncture GetEnumerator() and there is something like this inside the type (pseudo, not the actual source):
type SqlDataConnection<...>(...) =
interface seq<'T> with
member __.GetEnumerator() = executeSQL()
If you want to operate with IQueryable instead of IEnumerable, there is the query-syntax in F#:
query {
for r in db.MyTable do
where (r.id < 100)
take 10
} |> Seq.toList
More details:
https://learn.microsoft.com/en-us/dotnet/articles/fsharp/language-reference/query-expressions
I have a simple sequence expression that makes use of a resource that I'd like to clean up when I'm finished:
type MyObject() =
member this.Items =
seq {
use resource = ResourcePool.Get()
let c = resource.ValueCount
if c > 0 then
for i in 0 .. c - 1 do
yield resource.GetValue i
}
If I then use the sequence to iterate, say, half-way through the items, when will the resource be Disposed?
For example:
// ...
let foo = MyObject
let item = foo.Items |> Seq.find ( fun i -> i.Name = "name" )
// ...
Will resource be disposed after Seq.find is finished? Or do I need to reconsider my resource management strategy?
It will be disposed when the IEnumerator is disposed, regardless of how many items are enumerated. For functions in the Seq module this happens when the function exits (see tryFind as an example). GetEnumerator is rarely called directly in user code, but when it is it should be done with use instead of let.
Is it just me, or does F# not cater for cyclic lists?
I looked at the FSharpList<T> class via reflector, and noticed, that neither the 'structural equals' or the length methods check for cycles. I can only guess if 2 such primitive functions does not check, that most list functions would not do this either.
If cyclic lists are not supported, why is that?
Thanks
PS: Am I even looking at the right list class?
There are many different lists/collection types in F#.
F# list type. As Chris said, you cannot initialize a recursive value of this type, because the type is not lazy and not mutable (Immutability means that you have to create it at once and the fact that it's not lazy means that you can't use F# recursive values using let rec). As ssp said, you could use Reflection to hack it, but that's probably a case that we don't want to discuss.
Another type is seq (which is actually IEnumerable) or the LazyList type from PowerPack. These are lazy, so you can use let rec to create a cyclic value. However, (as far as I know) none of the functions working with them take cyclic lists into account - if you create a cyclic list, it simply means that you're creating an infinite list, so the result of (e.g.) map will be a potentially infinite list.
Here is an example for LazyList type:
#r "FSharp.PowerPack.dll"
// Valid use of value recursion
let rec ones = LazyList.consDelayed 1 (fun () -> ones)
Seq.take 5 l // Gives [1; 1; 1; 1; 1]
The question is what data types can you define yourself. Chris shows a mutable list and if you write operations that modify it, they will affect the entire list (if you interpret it as an infinite data structure).
You can also define a lazy (potentionally cyclic) data type and implement operations that handle cycles, so when you create a cyclic list and project it into another list, it will create cyclic list as a result (and not a potentionally infinite data structure).
The type declaration may look like this (I'm using object type, so that we can use reference equality when checking for cycles):
type CyclicListValue<'a> =
Nil | Cons of 'a * Lazy<CyclicList<'a>>
and CyclicList<'a>(value:CyclicListValue<'a>) =
member x.Value = value
The following map function handles cycles - if you give it a cyclic list, it will return a newly created list with the same cyclic structure:
let map f (cl:CyclicList<_>) =
// 'start' is the first element of the list (used for cycle checking)
// 'l' is the list we're processing
// 'lazyRes' is a function that returns the first cell of the resulting list
// (which is not available on the first call, but can be accessed
// later, because the list is constructed lazily)
let rec mapAux start (l:CyclicList<_>) lazyRes =
match l.Value with
| Nil -> new CyclicList<_>(Nil)
| Cons(v, rest) when rest.Value = start -> lazyRes()
| Cons(v, rest) ->
let value = Cons(f v, lazy mapAux start rest.Value lazyRes)
new CyclicList<_>(value)
let rec res = mapAux cl cl (fun () -> res)
res
The F# list type is essentially a linked list, where each node has a 'next'. This in theory would allow you to create cycles. However, F# lists are immutable. So you could never 'make' this cycle by mutation, you would have to do it at construction time. (Since you couldn't update the last node to loop around to the front.)
You could write this to do it, however the compiler specifically prevents it:
let rec x = 1 :: 2 :: 3 :: x;;
let rec x = 1 :: 2 :: 3 :: x;;
------------------------^^
stdin(1,25): error FS0260: Recursive values cannot appear directly as a construction of the type 'List`1' within a recursive binding. This feature has been removed from the F# language. Consider using a record instead.
If you do want to create a cycle, you could do the following:
> type CustomListNode = { Value : int; mutable Next : CustomListNode option };;
type CustomListNode =
{Value: int;
mutable Next: CustomListNode option;}
> let head = { Value = 1; Next = None };;
val head : CustomListNode = {Value = 1;
Next = null;}
> let head2 = { Value = 2; Next = Some(head) } ;;
val head2 : CustomListNode = {Value = 2;
Next = Some {Value = 1;
Next = null;};}
> head.Next <- Some(head2);;
val it : unit = ()
> head;;
val it : CustomListNode = {Value = 1;
Next = Some {Value = 2;
Next = Some ...;};}
The answer is same for all languages with tail-call optimization support and first-class functions (function types) support: it's so easy to emulate cyclic structures.
let rec x = seq { yield 1; yield! x};;
It's simplest way to emulate that structure by using laziness of seq.
Of course you can hack list representation as described here.
As was said before, your problem here is that the list type is immutable, and for a list to be cyclic you'd have to have it stick itself into its last element, so that doesn't work. You can use sequences, of course.
If you have an existing list and want to create an infinite sequence on top of it that cycles through the list's elements, here's how you could do it:
let round_robin lst =
let rec inner_rr l =
seq {
match l with
| [] ->
yield! inner_rr lst
| h::t ->
yield h
yield! inner_rr t
}
if lst.IsEmpty then Seq.empty else inner_rr []
let listcycler_sequence = round_robin [1;2;3;4;5;6]
C# has anonymous delegates. So I can write:
public vois foo(string d, Action t){
t();
}
In ruby:
def foo d
yield
end
How to do the same in F#? Prefered syntax is:
foo "dfdfdf" { do something here }
Thanks
Your first example isn't an anonymous method -- it's just passing and calling through a delegate (which might refer to a named or an anonymous method). To do this in F#, just provide and call a function argument:
let foo n f = f n
let square n = n * n
let result = foo 123 square
printfn "%A" result
To create the equivalent of an anonymous method in F#, use the fun keyword:
let result2 = foo 123 (fun n -> n * n)
Have a look at this article about Higher Order Functions in F#. Higher Order Functions are functions which accept other functions as arguments, and sound like the concept you are describing.
open System
// create a function that expects an Action delegate and executes it
let foo (actionDelegate:Action) (s:String) = actionDelegate.Invoke();
// create a function that meets Action delegate
let ActionFunction param = Console.Write("Action in action")
// call foo passing ActionFunction
foo (new Action(ActionFunction)) "my string"