@@ -381,7 +381,7 @@ A drawback of monad transformers is their somewhat rigid nature – every behavi
381381
382382Recently a ne aprproach to effect systems has been getting more attention – \emph{free monads algebraic effects}~\cite{kiselyov2015freer, ploeg2014reflection, kiselyov2013extensible}. This approach solves the problems with monad transformers mentioned above. Rather than being transformers, effects are described as \emph{functors}. The composability problem is resolved due to functors being in general composable. Contrary to how monad transformers operate, effects (or their carriers) in \emph{free monads algebraic effects} (we will from now on refer to them as just \emph{algebraic effects}) don't have any particulare inrpretation of the effect associated with them. Effects are interpreted in an ad-hoc way at the call site. Furthermore this allows us to dynamically modify the behavior of effects without changing the types or implementations of functions we wish to change the behavior of. How we use \emph{algebraic effects} will be discussed in more detail in section~\ref{sec:implementation}.
383383
384−\subsection{Type system}
384+\section{Type system}
385385
386386As mentioned above, we have opted to use the Damas-Milner type system as a basis for our implementation. Our goal is not to just add types for the sake of types, but give additional reassurance to the developer, and reject as many potentially ``invalid'' programs as possible. If the developer typechecker processes a program without errors, then the program should have no type errors during execution.
387387
@@ -406,7 +406,7 @@ Traditionally in languages similar to \emph{simply-typed lambda calculus} genera
406406 \label{fig:closing}
407407\end{figure}
408408
409−Apart from \emph{let expression} Nix also has \emph{attribute sets} discussed in section~\ref{sec:attrSet}, definitions in which are semantically similar to those in \emph{let expressions}. \emph{Attribute set} definitions also seem like a good point for \emph{generalization}.
409+Apart from \emph{let expressions} Nix also has \emph{attribute sets} discussed in section~\ref{sec:attrSet}, definitions in which are semantically similar to those in \emph{let expressions}. \emph{Attribute set} definitions also seem like a good point for \emph{generalization}.
410410
411411\subsection{Inferring recursive types}
412412
@@ -556,6 +556,10 @@ The term \texttt{x: y: x // y} would field the following type:
556556 \forall \alpha \beta \gamma. \; \alpha \update \beta \sim \gamma \Rightarrow \alpha \rightarrow \beta \rightarrow \gamma
557557\end{equation}
558558
559+\section{Implementation} \label{sec:implementation}
560+
561+\section{Possible improvements}
562+
559563\subsection{Making predicates more user-friendly}
560564
561565\subsubsection{A novel technique}
@@ -601,8 +605,6 @@ The technique is not in applicable if the ``result'' of a predicate is not a typ
601605
602606Another limitation is that we can not remove predicates if their ``result'' type variable is not present in the head of the type like in type \ref{eq:optFieldPredExample}, since we would be losing typing information by doing so.
603607
604−\section{Implementation} \label{sec:implementation}
605−
606608\section{Conclusion}
607609
608610Nix is a rapidly growing ecosystem. At the time of writing, nixpkgs, the Nix package registry, contains over 60000 packages\footnote{\url{https://github.com/NixOS/nixpkgs}} that can be either installed or used as dependencies in other projects. There is much interest in the approach used by Nix, and making the ever-growing codebase of configurations easier to manage and extend would be a welcome development.