introduction.tex

\documentclass[proposal.tex]{subfiles} 


\begin{document}
%----------------------------------------------------------------------------
\section{Introduction}\label{sect:introduction}
%----------------------------------------------------------------------------
\subsection{Beginnings}
\paragraph{}
Computers have become a part of everyone's life. From the ones in our pockets to the ones on desks or in our school bags, working or in fact living without 
them is difficult if not impossible. All the more reason to know how to use one. Simply speaking just using a computer these days is not enough. To be able 
to utilise their true potential, one must go deeper and communicate with them. This is where the art of programming steps in.     

\par Programming has become an integral part of working and interacting with computers and day by day more and more complex problems are being 
tackled using the power of programming technologies. It is possibly the only way to talk to computers and hence the need for a robust and multi purpose 
programming language has never been more urgent. The desirability of a programming language depends on a lot of factors such as the ease of use, the 
features and functionalities that it provides, adaptability and what sort of problems can it solve. One is  spoilt for choice with a number of options for a 
wide variety of programming paradigms, for example Object Oriented Languages. Over the last decade the declarative style of programming has gained 
popularity. The methodologies that have stood out are the Functional and Logical Approaches. The former is based on Functions and Lambda Calculus, 
while the latter is based on Horn Clause Logic. Each of them has its own advantages and flaws. How does one choose which approach to adopt? Perhaps
one does not need to choose! This document looks at the attempts, improvements and future possibilities of uniting \progLang{Haskell}, a Purely 
Functional Programming Language and \progLang{Prolog}, a Logical Programming Language so that one is not forced to choose.

\subsection{Thesis Statement}
\paragraph{} 
The thesis aims to provide insights into merging two declarative languages namely, \progLang{Haskell} and \progLang{Prolog} by embedding the latter 
into the former and analysing the result of doing so as they have conflicting characteristics. The finished product will be something like a \textit{haskellised}
 \progLang{Prolog} which has logical programming like capabilities.       


%----------------------------------------------------------------------------
\subsection{Problem Statement}
%----------------------------------------------------------------------------

\paragraph{}
Over the years the development of programming languages has become more and more rapid. Today the number of is in the thousands and counting. The 
successors attempt to introduce new concepts and features to simplify the process of coding a solution and assist the programmer by lessening the 
burden of carrying out standard tasks and procedures. A new one tries to capture the best of the old; learn from the mistakes, add new concepts and 
move on; which seems to be good enough from an evolutionary perspective. But all is not that straight forward when shifting from one language 
to another. There are costs and incompatibilities to look at. A language might be simple to use and provide better performance than its 
predecessor but not always be worth the switch.

\begin{comment}
\par \progLang{Prolog} has a similar story. It was born in an era where procedural programming had made everyone notice their presence. Talking about 
competition, it was against something radical; the \progLang{C} programming language. The languages \progLang{C} has influenced is off the chart and 
so is the performance. It had paved the way for structured procedural programming and had given birth to the Unix operating system. Though the 
original version of \progLang{Prolog} has given rise to a large number of different flavours but a few drawbacks remain through the bloodline and as a 
result it did become the first choice. Some basic requirements such as modules are not provided by all compilers. To make it do real world stuff, a set of 
practical features are pushed in now and then which results in the loss of the purely declarative charm. The problem is that \progLang{Prolog} is fading 
away, \cite{website:prolog-steam,website:prolog-death,website:prolog-killer}, not many people use it and most of the times when it is used, the variant 
is usually \textit{practical} \progLang{Prolog} and the area being academia. It is not used for building large programs \cite{wikiprolog,somogyi1995
logic,website:prolog1000db}. But there are a lot of good things about \progLang{Prolog} that should not die away. Moreover, \progLang{Prolog} is ideal 
for search problems. 
\end{comment}

\par \progLang{Prolog} is a language that has a hard time being adopted. Born in an era where procedural languages were receiving a lot of attention, it 
suffered from competing against another new kid on the block: \progLang{C}. Some of the problems were of its own making. Basic features like modules 
were not provided by all compilers. Practical features for real world problems were added in an ad hoc way resulting in the loss of its purely declarative 
charm. Some say that \progLang{Prolog} is fading away, \cite{website:prolog-steam,website:prolog-death,website:prolog-killer}. It is apparently not 
used for building large programs cite{wikiprolog,somogyi1995logic,website:prolog1000db}. However there are a lot of good things about Prolog: it is 
ideal for search problems; it has a simple syntax, and a strong underlying theory. It is a language that should not die away. 

\noindent So the question is how to have all the good qualities of \textsc{Prolog} without actually using \progLang{Prolog}?  

\par Well one idea is to make \progLang{Prolog} an add-on to another language which is widely used and in demand. Here the choice is \progLang{
Haskell}; as both the languages are declarative they share a common background which can help to blend the two.

\par Generally speaking, programming languages with a wide scope over problem domains do not provide bespoke support for accomplishing even 
mundane tasks. Approaching towards the solution can be complicated and tiresome, but the programming language in question acts as the master key. 

\par Flipping the coin to the other side we see, the more specific the language is to the problem domain the easier it is to solve the problem. The simple 
reason being that, the problem need not be moulded according to the capability  of the language. For example a problem with a naturally recursive 
solution cannot take advantage of tail recursion in many imperative languages. Many problems require the system to be mutation free, but have to deal 
with uncontrolled side-effects and so on.  

\par Putting all of the above together, Domain Specific Languages are pretty good in doing what they are designed to do, but nothing else, resulting in 
choosing a different language every time. On the other hand, a general purpose language can be used for solving a wide variety of problems but many a 
times, the programmer ends up writing some code dictated by the language rather than the problem.  

\par The solution, a programming language with a split personality, in our case, sometimes functional, sometimes logical and sometimes both. 
Depending upon the problem, the language shapes itself accordingly and exhibits the desired characteristics. The ideal situation is a language with a rich 
feature set and the ability to mould itself according to the problem. A language with ability to take the appropriate skill set and present it to the 
programmer, which will reduce the hassle of jumping between languages or forcibly trying to solve a problem according to a paradigm.  

\par The subject in question here is \progLang{Haskell} and the split personality being \progLang{Prolog}. How far can \progLang{Haskell} be pushed to 
dawn the avatar of \progLang{Prolog} ? is the million dollar question. 

The above will result in a set of characteristics which are from both the declarative paradigms. 
%----------------------------------------------------------------------------------------------------------------------   
   
%The issue being discussed here is that often when a problem is to solved using a given language, it has to be moulded %according to the capability the 
%language can provide.
This can be achieved in two ways,
\begin{description}
\item [Embedding (\chapterReference{sect:embedding}{Chapter 4}):]

\par This approach involves, translating a complete language into the host language as an extension such as a library and/ or module . The result is very 
shallow as all the positives as well as the negatives are brought into the host language. The negatives mentioned being, that languages from different 
paradigms usually have conflicting characteristics and result in inconsistent properties of the resulting embedding. Examples and further discussion on 
the same is provided in the chapters to come.  

\item [Paradigm Integration (\chapterReference{sect:multiparadigm}{Chapter 5}):]

\par This approach goes much deeper as it does not involve a direct translation. An attempt is made by taking a particular characteristic of a language 
and merging it with the characteristic of the host language in order to eliminate conflicts resulting in a multi paradigm language. It is more of weaving 
the two languages into one tight package with the best of both and maybe even the worst of both.       
\end{description}


%----------------------------------------------------------------------------
%\subsection{Research Approach and Contributions}
%----------------------------------------------------------------------------
%



%\subsubsection{Contributions}
%----------------------------------------------------------------------------

%----------------------------------------------------------------------------


%----------------------------------------------------------------------------
\subsection{Proposal Organization}

\paragraph{}
The next chapter, \chapterReference{sect:proposedWork}{Chapter 2} provides details about the short comings of the previous works and the road to a 
better future. \chapterReference{sect:background}{Chapter 3}, the background talks about the programming paradigms and languages in general and 
the ones in question. Then we look at the question from different angles namely, \chapterReference{sect:embedding}{Chapter 4},  Embedding a 
Programming Language into another Programming Language and  \chapterReference{sect:embedding}{Chapter 5}, Multi Paradigm Languages (
Functional Logic Languages). Some of the indirectly related content \chapterReference{sect:relatedWork}{Chapter 6} and finishing off with the 
\chapterReference{sect:conclusion}{Chapter 7}, the expected outcomes.     

%\subsection{The Plan}



\end{document}