small improvements

doc/jsweet-language-specifications.tex

@@ -1383,7 +1383,7 @@ assert c instanceof MyClass;
 assert typeof(n3) == "number";
 \end{lstlisting}
 
-From JSweet version 1.1.0, the \texttt{instanceof} operator is also allowed on interfaces, because JSweet keeps track of all the implemented interfaces for all objects. This interface tracking is ensure through an additional hidden property in the objects called \texttt{\_\_interfaces} and containing the names of all the interfaces implemented by the objects (either directly or through its class inheritance tree determined at compile time). So, in case the type argument of the \texttt{instanceof} operator is an interface, JSweet simply checks out if the object's \texttt{\_\_interfaces} field exists and contains the given interface. For example, this code is fully valid in JSweet when \texttt{Point} is an interface:
+From JSweet version 1.1.0, the \texttt{instanceof} operator is also allowed on interfaces, because JSweet keeps track of all the implemented interfaces for all objects. This interface tracking is ensured through an additional hidden property in the objects called \texttt{\_\_interfaces} and containing the names of all the interfaces implemented by the objects (either directly or through its class inheritance tree determined at compile time). So, in case the type argument of the \texttt{instanceof} operator is an interface, JSweet simply checks out if the object's \texttt{\_\_interfaces} field exists and contains the given interface. For example, this code is fully valid in JSweet when \texttt{Point} is an interface:
  
 \begin{lstlisting}[language=Java]
 Point p1 = new Point() {{ x=1; y=1; }};
@@ -1393,7 +1393,9 @@ assert p1 instanceof Point
 
 \subsection{Limitations and constraints}
 
-Since all numbers are mapped to JavaScript numbers, JSweet make no distinction between integers and floats for example. So, \texttt{n instanceof Integer} and \texttt{n instanceof Float} will always give the same result whatever the actual type of \texttt{n} is. The same limitation exists for strings and char, which are not distinguishable at runtime.
+Since all numbers are mapped to JavaScript numbers, JSweet make no distinction between integers and floats for example. So, \texttt{n instanceof Integer} and \texttt{n instanceof Float} will always give the same result whatever the actual type of \texttt{n} is. The same limitation exists for strings and chars, which are not distinguishable at runtime, but also for functions that have the same number of parameters. For example, an instance of \texttt{IntFunction<R>} will not be distinguishable at runtime from a \texttt{Function<String,R>}. 
+
+These limitations have a direct impact on function overloading, since overloading uses the \texttt{instanceof} operator to decide which overload to be called.
 
 Like it is usually the case when working in JavaScript, serialized objects must be properly "revived" with their actual classes so that the \texttt{instanceof} operator can work again. For example a point object created through \texttt{Point p = (Point)JSON.parse("\{x:1,y:1\}")} will not work with regard to the \texttt{instanceof} operator. In case you meet such a use case, you can contact us to get some useful JSweet code to properly revive object types.
 
@@ -1575,6 +1577,8 @@ Typically, \texttt{d.ts} files shall be generated by the JSweet transpiler using
 
 Finally it is recommended (and good practice) to also package the generated JavaScript as a bundle. The adopted way by JSweet is to package the JavaScript following the WebJar conventions: \url{http://www.webjars.org/}. When packaged this way, a JSweet transpiler using your candy will automatically extract the bundled JavaScript and extract it in a directory given by the \texttt{candiesJsOut} option (default: \texttt{js/candies}).
 
+A typical Maven \texttt{pom.xml} for building a candy can be found here: \url{https://gist.github.com/renaudpawlak/5d3f1fa092d718e12407ef1801fb5ddd}.
+
 \chapter*{Appendix 1: JSweet transpiler options}
 
 \begin{verbatim}