% Sebastian Ivarsson %

\documentclass[11pt,a4paper]{article}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage[english]{babel}
\usepackage{fancyhdr}
\usepackage{hyperref}
%%\usepackage{showframe}
%\usepackage[parfill]{parskip} %% New line instead of indentation for paragraphs

\usepackage{geometry}
\geometry{  a4paper,
            total={210mm,297mm},
            left=25mm,
            right=25mm,
            top=25mm,
            bottom=35mm,
        }

\hypersetup{    pdftitle={AFP Assignment 3},%
                pdfauthor={Sebastian Ivarsson, John Martinsson},%
                pdfborder={0 0 0},%
            }

\usepackage{listings}
\usepackage{amsmath}
\usepackage[parfill]{parskip}
\usepackage{graphicx}
\usepackage{caption}
\usepackage{subcaption}

\usepackage{amssymb}
\usepackage{dsfont}

% Table
\usepackage{tabularx}
\usepackage{tikz}
%\tikzset{every picture/.style={remember picture}}

\renewcommand\tabularxcolumn[1]{m{#1}}
\newcolumntype{M}{>{\centering\arraybackslash}m{1cm}}

\newcommand\tikzmark[2]{%
    \tikz[remember picture,baseline]
    \node[inner sep=2pt,outersep=0] (#1){#2};%
    }

\newcommand\link[2]{%
    \begin{tikzpicture}[remember picture, overlay, >=stealth, shift={(0,0)}]
        \draw[->] (#1) to (#2);
    \end{tikzpicture}%
    }

% Strikeout
\usepackage[normalem]{ulem}

\usepackage{algpseudocode} % Pseudocode
\usepackage{amsthm} % Theorems

\newtheorem{myclaim}{Claim}[section]
\newtheorem{mytheorem}{Theorem}[section]
\newtheorem{mydef}{Definition}

\begin{document}



% Settings %
\pagestyle{fancy}
\fancyhead[L]{Advanced Functional Programming\\TDA342\\20150301}
\fancyhead[R]{Sebastian Ivarsson\\John Martinsson\\Fire: group 13}

\renewcommand{\headrulewidth}{0pt} \setlength{\headsep}{30pt}
\setlength{\headheight}{30pt}
%% %\addtolength{\voffset}{-50pt}
%% %\addtolength{\textheight}{50pt}
%% \setlength{\marginparsep}{0pt}
%% \setlength{\marginparwidth}{0pt}
%% \addtolength{\textwidth}{90pt}
%% \addtolength{\hoffset}{-50pt}
% \Settings %

\title{Assignment 3}
\author{Sebastian Ivarsson, John Martinsson}
\maketitle
\thispagestyle{fancy}


\section{Part I}
For this assignment, we have chosen the package ‘haskeline’. Haskeline is used
to provide a more advanced means of getting input from the user than using the
standard ‘getLine’ function in Haskell. It provides functionality similar to
that of the GNU 'readline' library for C, used in many linux applications. We
think haskeline is an interesting package as it provides a very easy way of
getting a nice input interface for your haskell command line applications.

Our idea is to implement a simple shell in haskell using this library along with
the process library to pass on the calls to the system binaries. In order to
make it a bit more interesting, we thought it would be fun to add some basic
scripting functionality to the shell (as in bash/zsh). Since the project is so
short, this scripting language would have to be very limited. The things we have
planned are:

Variables using let expressions, for example:
\begin{verbatim}
  let $x = ls -la in x | wc; cd ..; x
\end{verbatim}

Which would be equivalent to:

\begin{verbatim}
  ls -la | wc; cd ..; ls -la
\end{verbatim}

Not only should it be possible to have variables in scope for the coming
command, but also for the whole session:

\begin{verbatim}
  let $x = hello; echo $x
\end{verbatim}

List comprehensions over lists of output values from another command:

\begin{verbatim}
  [ echo $x | $x <- ls ]
\end{verbatim}

Which would correspond to (in zsh):

\begin{verbatim}
  for $f in $(ls); do echo $f; done
\end{verbatim}

Functions (this is by far the hardest part, and may not be feasible for such a small project):

\begin{verbatim}
  let f n = n + 1 in echo (f 0)
\end{verbatim}

Which would be interpreted / evaluated as:

\begin{verbatim}
  echo 1
\end{verbatim}

In order to write such a shell application, we would need to write a parser for
the user input. Luckily, the package 'bnfc' makes it easy to generate a parser
automatically from a specified grammar, and by having a very restricted set of
features it should not be too hard to write those rules.

With a finished parser, the challenge will be to put it all together, i.e.,
handling user input via haskeline, parsing (and interpreting) the scripting
language via the bnfc generated parser, and handling system binary execution via
the process library. Our haskell shell will also need to handle the state of the
shell, that is, the current path and variables. One possible extension would be
to implement even more advanced shell functionality such as job control (way out
of scope for this project, but it would be cool to have).


We believe this project would cover the course goals in the following ways:

\textbf{DSLs}: Both bnfc and haskeline are DSLs, so working with them will require
understanding how they work. Our own scripting language will be a DSL in itself,
and by implementing it, we will need to handle both the concrete and abstract
syntax of our language, as well as the semantics when evaluating it.

\textbf{Types}: Writing the code for this project will inevitably include writing our own
types, and since our shell will no doubt have to be at least in the IO monad
(and the State monad), we will use monad transformers to construct it. Also, the
abstract syntax will be an algebraic datatype.  The haskeline library uses quite
a big stack of monad transformers (mostly ReaderT). If functions are to be
implemented in our shell language, we might need to use a GADT to model the
expressions.

\textbf{Spec / Testing}: Ideally, we would also like to create  a proper testsuite
(preferably using quickCheck) for our program, but as time will be very limited,
this will only be done if there is time left. Since the program will be mostly
monadic, proving properties might be hard.

We realise that this might be an ambitious undertaking, and we have consulted
one of the TAs about the project. The recommendation was to focus on the
haskeline library, and instead question it’s implementation choices, and try to
make suggestions on how to improve upon them. However, we feel that writing a
simple shell could be a really interesting project, and we would like to give it
a try, but, should we realise early that this is not feasible within the limited
time-frame of this course, we will instead go with the TAs recommendation and
focus on the haskeline library itself.

\section{Part II}

\subsection{Task 1 - Writing code}
\textbf{Modification / extension}: Show how the library could be changed to improve it in
some aspect, or extend the library with some useful feature. Implementing the
suggested feature is of course the best thing, but since this is a short project
we understand if the result is limited to a partial solution or even a sketch of
the implementation along with a description (in your report) of what
difficulties you faced when trying to implement it.

\textbf{Advanced usage / tutorial}: Show some examples of what the library can be used
for. The examples must demonstrate a deep understanding of the library (or part
of it). Note: This task is potentially much simpler than the other two. Making a
good tutorial is enough for a passing grade on this assignment, but is unlikely
to yield a higher grade.

\subsection{Task 2 - Documentation}
Haskeline is a user interface used to handle line input for command-line
programs. It is primarily used to enable a rich editing interface when entering
input on the command line, for example, functionality such as Emcas- and
Vim-Mode is present by default.

It is also highly customizable, as the user of the library can define their own
'completion functions', which are basically the function that is used
intelligently complete a command that is being entered on the command-line.

\subsubsection{Description of library interface}
Haskeline provides a simple, and easy to use interface. The documentation for
this interface is good, and we will therefore give a brief summary of how to use
it, and what functionality is available to the application programmer.

\subsubsection{Settings}
The application programmer has a couple of settings available. It is possible to
set how history should be handeled, i.e., which history file to use, and if
history should be automatically added to the history file. History in this
context is all non-empty lines that has been entered into the command-line of
the application.

The more interesting setting is the custom 'completion function', which allows
the application programmer to decide how the input should be completed.

\subsection{Preferences}
Haskeline also provides some basic functionality regarding preferences, which by
default is read from the file $\mathtt{\sim}$\textit{/.haskeline}. This allows the end user to
configure the application to his/her liking. For example:

\begin{verbatim}
  editMode: Vi
  completionType: MenuCompletion
  maxhistorysize: Just 40
\end{verbatim}

\subsubsection{Interesting techniques}
- Reader stack?
- Implementation of error robust state

\subsubsection{Monite shell}
Monite shell is a shell written in Haskell. Monite shell is build using a couple
of libraries; the major three being: haskeline, BNFC, and process.

Haskeline is used used to provice a rich command-line interface for the
end-user. Monite is customizable to the end-users preferences in the
configuration file $\mathtt{\sim}$\textit{/.moniterc} (see haddock documentation
for available preferences). It also provides monite with a history file, and
useful completion functions. The end-user can tab-complete commands entered at
the command-line, and using our customized completion function we look in the
users \$PATH, in order to suggest completions for the first word entered at the
command-line, and we then use the standard file completion from haskeline for
tab-completion of the arguments.

BNFC is a parsing library, and is used in monite to parse a small scripting
language, which is available to the end-user to enter at the command line. We
have written our own BNFC grammars, and BNFC can then generate a lexer, and a
parser from these grammars, which are used to parse the commands entered on the
command-line in monite. The abstract syntax tree is then evaluated using our own
own evaluation functions.

The process library is used to allow for easy execution, and handling of binary
processes such as ls, cat, echo, etc, as well as to allow piping, and
redirection of stdout. We support redirection, e.g., "ls > filef", and "cat <
filef" and piping, e.g., "ls | wc | wc | wc".

\textbf{Features}:
Tab-completion, history file, configuration, redirection, piping, (small)
scripting language, script execution, interrupt handling (Ctrl-c)

\textbf{Missing features}:
More general configuration file, the configuration supported now is that which
haskeline provides by default, it would be nice to be able to set a custom
prompt, and define custom functions. However, this would entail extending the
scripting language with support for functions, which we realized was beyond the
scope of this course. It would be nice to be able to set environment variables
in the scripting language, e.g., allow the end-user can set his/her own \$PATH.

Job control is another missing feature that monite could be extended with
(probably a necessity for it to be considered a usable shell).

\end{document}
