deletions | additions       diff --git a/case-study.tex b/case-study.tex  index 044279f..77714bd 100644  --- a/case-study.tex  +++ b/case-study.tex 
...
\item since an {\tt feval} is executed through the interpreter, in the original functions arguments are boxed to make them more generic before the call.  \end{enumerate}  The first one in particular is a major source of inefficiency for the OSR-based approach, since the benefits from replacing the call to the interpreter's {\tt feval} dispatcher with a direct call are limited compared to the optimization opportunities deriving from a better type inference on the whole body of the function. In fact, as they operate on boxed values, instructions operating on generic-type variables are inherently much less efficient than their counterparts for [arrays of] primitive types. While the JIT-based approach is preferable as it generates much better code, on the other hand it cannot be applied to cases in which the first argument $f$ to {\tt feval} is not passed as argument to the enclosing function $g$, such as:  \begin{enumerate} $g$. Some possible scenarios are:  \begin{itemize}  \item $f$ is an {\tt inline} or an anonymous function defined in $g$;  \item $f$ is the return value from a previous call in $g$ to another function;  %\item $f$ is retrieved from a data structure;  \item $f$ is a constant string containing the name of a user-defined function (a typical inappropriate use of {\tt feval} according to~\cite{radpour2013refactoring}).  \end{enumerate} \end{itemize}    Lameed and Hendren conclude their paper by stating, ``It would be interesting to look at future work that combine the  strengths of both approaches".