<commit_before>\documentclass[11pt, letterpaper, oneside, twocolumn] {article}
\usepackage{minted}

\begin{document}

\title{HaPy \\
Haskell for Python
}
\author{<NAME>, <NAME>, and <NAME>}
\maketitle

\section{Introduction}

\section{Motivation}
It is a truth universally acknowledged, that a single Python module in possession of a good GUI, must be in want of a Haskell backend. Joking aside, three trends are clear when looking at the most recent State of Haskell survey and other data: in the first place, Haskellers primarily use Haskell for mathematical analysis, parsing/compiling, and (increasingly) web development; importantly, GUI development in Haskell is almost non-existent. Secondly, Python remains a popular language for creating GUIs, because of its high-level, human-readable syntax and intuitive ease of use. Lastly, Python code is much slower than the corresponding C code, while Haskell's performance is generally almost as good as C's for most use cases. This is in spite of the fact that Python and Haskell are both very high-level languages. 

\section{Use}

\subsection{Loading Haskell Modules}

\subsection{Haskell types in Python}

\section{Implementation}

\subsection{Dynamic Loading of Haskell modules}

\subsection{Function Currying}

\subsection{Type checking}

\section{Future work}
In future, HaPy could support dynamic conversion from GADTs to Python types when instance of user-defined Haskell data are passed from the Haskell layer to the Python layer---in particular, Haskell's product types would map to Python classes while Haskell's sum types could be represented in Python by an enumerated type. 

\section{Refernces}
System.Plugins stuff.

\end{document}<commit_msg>outline<commit_after>\documentclass[11pt, letterpaper, oneside, twocolumn] {article}
\usepackage{minted}

\begin{document}

\title{HaPy \\
Haskell for Python
}
\author{<NAME>, <NAME>, and <NAME>}
\maketitle

\section{Introduction}
% - what is HaPy?
% - focuses on ease of use
%  - to acomplish this: should be pythonic
%  - completely transparent!
%  - no coding overhead on either side (shouldn't be aware that you're using haskell on python side, don't need to code for python in haskell -> should be able to use any haskell module on system)

\section{Motivation}
It is a truth universally acknowledged, that a single Python module in possession of a good GUI, must be in want of a Haskell backend. Joking aside, three trends are clear when looking at the most recent State of Haskell survey and other data: in the first place, Haskellers primarily use Haskell for mathematical analysis, parsing/compiling, and (increasingly) web development; importantly, GUI development in Haskell is almost non-existent. Secondly, Python remains a popular language for creating GUIs, because of its high-level, human-readable syntax and intuitive ease of use. Lastly, Python code is much slower than the corresponding C code, while Haskell's performance is generally almost as good as C's for most use cases. This is in spite of the fact that Python and Haskell are both very high-level languages. 
% - general motivation: haskell and python are good at different things
%  - in a large project: good to be able to do each piece in the best language
%  - usefullness is inversely proportional to friction (so now maximally useful)
% - example use case:
%  - python GUI, haskell backend
%  - (or existing python project)
%  - (or existing haskell library)

\section{Use}

\subsection{Loading Haskell Modules}
% - super easy: all haskell modules represented as submodules of HaPy
% - import HaPy.Data.List

\subsection{Haskell types in Python}
% - some automarshalled (haskell functions, haskell primitive types)
% - others opaque
% - support function currying
%  - haskell functions in python have haskell-type access if desired
%  - can be ignored
%  - can apply a few arguments at once
% -  returns a new function every time
% - can apply opaque haskell types
% - automatically marshall (if possible) once all args applied

\section{Implementation}

\subsection{Dynamic Loading of Haskell modules}

\subsection{Function Currying}

\subsection{Type checking}

\section{Future work}
In future, HaPy could support dynamic conversion from ADTs to Python types when instance of user-defined Haskell data are passed from the Haskell layer to the Python layer---in particular, Haskell's product types would map to Python classes while Haskell's sum types could be represented in Python by an enumerated type. 

\section{Refernces}
System.Plugins stuff.

\end{document}
{'fraction_non_alphanumeric': 0.06445954834466126, 'fraction_numerical': 0.0008770006577504934, 'mean_word_length': 4.7025, 'pattern_counts': {'":': 0, '<': 9, '<?xml version=': 0, '>': 10, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '3886923', 'n_tokens_mistral': 1270, 'n_tokens_neox': 1160, 'n_words': 604}