mics2018.tex

 % This is sigproc-sp.tex -FILE FOR V2.6SP OF ACM_PROC_ARTICLE-SP.CLS
% OCTOBER 2002
%
% It is an example file showing how to use the 'acm_proc_article-sp.cls' V2.6SP
% LaTeX2e document class file for Conference Proceedings submissions.
%
%----------------------------------------------------------------------------------------------------------------
% This .tex file (and associated .cls V2.6SP) *DOES NOT* produce:
%     1) The Permission Statement
%     2) The Conference (location) Info information
%     3) The Copyright Line with ACM data
%     4) Page numbering
%
% However, both the CopyrightYear (default to 2002) and the ACM Copyright Data
% (default to X-XXXXX-XX-X/XX/XX) can still be over-ridden by whatever the author
% inserts into the source .tex file.
% e.g.
% \CopyrightYear{2003} will cause 2003 to appear in the copyright line.
% \crdata{0-12345-67-8/90/12} will cause 0-12345-67-8/90/12 to appear in the copyright line.
%
%
%---------------------------------------------------------------------------------------------------------------
% It is an example which *does* use the .bib file (from which the .bbl file
% is produced).
% REMEMBER HOWEVER: After having produced the .bbl file,
% and prior to final submission,
% you need to 'insert' your .bbl file into your source .tex file so as to provide
% ONE 'self-contained' source file.
%
% Questions regarding SIGS should be sent to
% Adrienne Griscti ---> griscti@acm.org
%
% Questions/suggestions regarding the guidelines, .tex and .cls files, etc. to
% Gerald Murray ---> murray@acm.org
%
% For tracking purposes - this is V2.6SP - OCTOBER 2002


\documentclass[12pt]{article}

\setlength{\oddsidemargin}{0in}
\setlength{\evensidemargin}{0in}
\setlength{\topmargin}{0in}
\setlength{\headheight}{0in}
\setlength{\headsep}{0in}
\setlength{\textwidth}{6in}
\setlength{\textheight}{9in}
\setlength{\parindent}{0in}

\usepackage{graphicx} %For jpg figure inclusion
\usepackage{times} %For typeface
\usepackage{epsfig}
\usepackage{color} %For Comments
%\usepackage[all]{xy}
\usepackage{float}
%\usepackage{subfigure}
\usepackage{hyperref}
\usepackage{url}
\usepackage{parskip}

%% Elena's favorite green (thanks, Fernando!)
\definecolor{ForestGreen}{RGB}{34,139,34}
\definecolor{BlueViolet}{RGB}{138,43,226}
\definecolor{Coquelicot}{RGB}{255, 56, 0}
\definecolor{Teal}{RGB}{2,132,130}
%Uncomment this if you want to show work-in-progress comments
\newcommand{\comment}[1]{{\bf \tt  {#1}}}
% Uncomment this if you don't want to show comments
%\newcommand{\comment}[1]{}
\newcommand{\emcomment}[1]{\textcolor{ForestGreen}{\comment{Elena: {#1}}}}
\newcommand{\todo}[1]{\textcolor{blue}{\comment{To Do: {#1}}}}
\newcommand{\tscomment}[1]{\textcolor{Teal}{\comment{Tony: {#1}}}}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{document}
\pagestyle{plain}
%
% --- Author Metadata here ---
%\conferenceinfo{WOODSTOCK}{'97 El Paso, Texas USA}
%\setpagenumber{50}
%\CopyrightYear{2002} % Allows default copyright year (2002) to be
%over-ridden - IF NEED BE.
%\crdata{0-12345-67-8/90/01}  % Allows default copyright data
%(X-XXXXX-XX-X/XX/XX) to be over-ridden.
% --- End of Author Metadata ---

\title{Implementing Novice Friendly Error Messages in Clojure}
%\subtitle{[Extended Abstract \comment{DO WE NEED THIS?}]
%\titlenote{}}
%
% You need the command \numberofauthors to handle the "boxing"
% and alignment of the authors under the title, and to add
% a section for authors number 4 through n.
%
% Up to the first three authors are aligned under the title;
% use the \alignauthor commands below to handle those names
% and affiliations. Add names, affiliations, addresses for
% additional authors as the argument to \additionalauthors;
% these will be set for you without further effort on your
% part as the last section in the body of your article BEFORE
% References or any Appendices.

\author{
Charlot Shaw \\
Computer Science Discipline \\
University of Minnesota Morris\\
Morris, MN 56267\\
shawx538@morris.umn.edu
}
\maketitle
\thispagestyle{empty}
%\alcomment{Should these say @morris.umn.edu?}

\section*{\centering Abstract}
Clojures promise as an educational language taught to first time programmers is
limited by its error messages, which show its Java underpinnings. The messages
are generated by the Java code executing the Clojure program, and thus are
focused on the state of the Java implementation of Clojure,
which hides the details about the issue in the users code.
By using these messages, along with the information obtained via Clojure.Spec contracts,
 error messages can be reformatted into a beginner friendly, near plain-language representation.
 By integrating the re-formatting code into Clojures nREPL middleware system, the
 transformation can be accomplished without disturbing programmers' workflow, and be easily
 incorporated into Integrated Development Environments.
We present a proof of concept implementation
integrating beginner friendly error messages into Clojure via nREPL.

\newpage
\setcounter{page}{1}

\section{Introduction}
Clojure~\cite{Hickey:2008}, amongst other functional languages, has gained attention in recent years
in part for its management of state and concurrency.
%\comment{is there something else I should call out as feature of Clojure?}
%\emcomment{For this write-up it's sufficient. For a full-scale paper you would need more details}
Running on the Java Virtual Machine (JVM), Clojure has a number of advantages for beginning students.
Its Lisp style syntax and elegant core library work together to let beginners learn easily, while
its ties to the JVM keep it relevant as students progress into later courses.
However, from an educational perspective, it has a significant flaw in the form of error messages.
As Clojure code runs in the JVM, its errors take the structure and terminology of Java error messages,
and so are confusing to new students. They can understand the source of the error,
but not how the system presents it to them.
For example, a user who accidentally called addition on a boolean needs
 to understand the Java object hierarchy, casting,
 and the classes involved to fully understand what is meant by
 ``java.lang.classCastException java.lang.Boolean cannot be cast to java.lang.Number'',
whereas the mental overhead required to understand
``In function + the first argument {\tt true} must be a number, but is a boolean''
 is significantly lower, with the latter being closer to a plain language
 description of the issue.
 In order to overcome these problems,
 we have explored possibilities for integrating customized error messages
 with common tools in the Clojure programming community.

\section{Error Messages in Clojure}
Clojure is hosted and interpreted in the JVM, as a Java program.
Clojure code can either be loaded by a running Clojure process, or
compiled Ahead Of Time (AOT compilation) into Java bytecode. In either case,
even simple Clojure code mid-execution is in actuality a complex Java program.
When that program encounters any error, including syntax errors, it is thrown as a Java exception.
From the viewpoint of the JVM, the entirety of the Clojure process is
a part of the users program, and so error messages include large amounts
of data about the underlying state of the Java classes that implement Clojure.
This surplus information can be useful in debugging,
but whole message is still phrased from a Java perspective, requiring familiarity with Java
to understand what is happening in Clojure.
This undue onus on the beginner,
unfamiliar with programming in general, is an unreasonable burden.
However, the information present can be leveraged by us to make our improved
error messages, though there is not enough information in them to rely on them entirely.
A second source of information is preferred when possible, and can be found within Clojure itself,
in the form of Clojure Spec contracts.

\section{Clojure Spec}
The second piece of the information required can be sourced from Clojure Spec~\cite{spec}
which is a recently added library within Clojure, dealing with runtime validation of
the structure of data within a program. These take the form of specifications, or contracts
and can be applied to any data structure, including the arguments supplied to a function.
 For example, a function dealing with a list can have a Spec contract enforcing that all arguments
 used as list indices are non-negative integers.
Importantly, these contracts provide detailed information
 about how the actual values differ from those required.
By providing Spec specifications for the core library of Clojure,
 we can cover every function that a novice is able to call, and thus catch
 any miscalled functions with detailed Spec error messages.
 This information can be captured by our system, and as a result
 lets us access information such as the actual values that caused the exception,
 a detail often omitted by default Clojure errors.
Note that Spec only provides errors for function arguments; for syntax errors or other kinds of
runtime exceptions, we need to source our data from the original Java error messages.
Between Spec error messages and the original Java error messages, we have enough
information to leverage the tools built by the
 University of Minnesota Morris research group~\cite{mics2017}.
However, up until now it was not clear how this system could be integrated with the larger Clojure ecosystem.
%, as soon as we can integrate
% our process with the larger Clojure ecosystem.
% \comment{Need to work out a transition here}

\section{Clojure, REPL and the IDE}
Clojure is homoiconic, meaning that a Clojure program is also a Clojure data structure.
 Evaluating every value in that structure is
equivalent to running the program.
This allows a Clojure process to read in data, process it as a program, display the results
 back to the programmer, and keep running, awaiting the next input.
 This common sequence of steps is referred to
as the Read-Eval-Print-Loop (REPL). Programmers use it to interactively test and build up
individual parts of their programs. This pattern of development is
referred to as REPL-Driven and is commonly used in Clojure community.
 Most Clojure Integrated Development Environments (IDEs) feature REPLs for
 user convenience. Outside of developer experimentation, the REPL mechanism is also used
by the Clojure process to load in new Clojure code for execution in a running program,
omitting the Print step if necessary.
Spanning both evaluation of code, and the preparation of output back to the user,
the REPL is a prime location for our system to be implemented.
However, building our own custom REPL is not advisable, as it limits the
integration possibilities, needing IDEs to be customized to support it.
Instead, the ideal position for our code is within a module
 for a popular, expandable REPL implementation.

\section{nREPL}
nREPL~\cite{nrepl} is a community standard implementation of the REPL concept,
 using a
\newline
Client/Server model.
%It is integrated in Leiningen
% (a project management system common in the Clojure community) as the default REPL.
% Plugins that utilize nREPL exist for Emacs, vim, InelliJ Idea, Atom, and Eclipse,
%among others.
It is integrated into Clojure project management software, as well as most commonly used IDEs
that support Clojure.
nREPL works by passing messages from the client, to be executed on the server, with the results
being returned to the client for display.
It allows a set of middleware to modify messages, providing utilities
like interruptible evaluations or independent user sessions.
Custom middleware, such as ours, can be added by simply
modifying a projects configuration file. Once our code is added,
it listens for messages coming back from the server
marked to be displayed to the users as errors.
It customizes the error messages, and then reinserts them into the middleware stack
to reach the user. As it is using the same message propagation scheme as an unmodified nREPL,
IDEs should pick up and display the new error messages with little trouble.
This also does not change or affect anything on the server side, so there are no side effects.

\section{Conclusion}
Between Clojure default error messages, and Clojure Spec
we have all the information needed to modify error messages, using the
tools created by prior works of the University of Minnesota Morris research group. %\cite{mics2017}
Using nREPL middleware lets us place our code seamlessly into the beginners
workflow, in a way that would not violate the expectations of more advanced users.
 Taken together our system shows a proof of concept for how Clojure
error messages can be modified for beginners via nREPL, a necessary step in making
Clojure an educational language for first time programmers.


\section{Acknowledgments}
The author thanks the project adviser  Elena Machkasova.
The work was supported in part by Morris Academic Partnership (MAP) stipend at UMM.

\bibliographystyle{acm}
\bibliography{mics2018}

\end{document}