Add extra info about type search

1 files changed, 16 insertions, 0 deletions

diff --git a/resources/md/2021-07-26-cloogle-search-overview.md b/resources/md/2021-07-26-cloogle-search-overview.md
index 213e71c..6fb6e6e 100644
--- a/resources/md/2021-07-26-cloogle-search-overview.md
+++ b/resources/md/2021-07-26-cloogle-search-overview.md
@@ -118,6 +118,22 @@ would have the type `Int -> b` and node 6 the type `String -> b`. How the type
 is built depends on the order in which types are found by the index builder. It
 does not really matter for the search algorithm.
 
+Besides this, there are some nice tricks to improve the results. For instance,
+type synonyms are resolved in both the type tree and the query. In Hoogle, you
+won't find `length :: Foldable t => t a -> Int` with the query `String -> Int`,
+because it does not resolve `String -> Int` to `[Char] -> Int`. In Cloogle, the
+same query will find `size :: (a e) -> Int | Array a e`, because it knows that
+`String` is an `{#} Char` (an array of characters).
+
+Also, universally quantified type variables can be used to restrict the search
+to functions that are polymorphic. By default, a query like `[a] -> [a]` will
+return results like `indexList :: [a] -> [Int]`, because the user might not
+realize that the function they are looking for cannot be defined in a
+polymorphic way (or the function in the index does not have the most general
+type). However, if you are sure you only want results where `a` is not unified,
+you can use `A.a: [a] -> [a]`. `A` here is similar to Haskell's `forall`. The
+unification system takes care of the rest.
+
 # Ranking
 
 The last interesting optimization concerns ranking. We go several times through