-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathintroduction.tex.bak
More file actions
93 lines (51 loc) · 7.53 KB
/
introduction.tex.bak
File metadata and controls
93 lines (51 loc) · 7.53 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
\documentclass[proposal.tex]{subfiles}
\begin{document}
%----------------------------------------------------------------------------
\section{Introduction}\label{sect:introduction}
%----------------------------------------------------------------------------
\begin{comment}
This is the introduction. This is a sample bib citation \cite{chin2003type}, \cite{claessen2000typed}, \cite{hinze1998prological}, \cite{spivey2000functional}, \cite{erwig2004escape}, \cite{spivey1999embedding}, \cite{seres1999algebra}, \cite{seres2001algebra}, \cite{seres2000optimisation}, \cite{seres2001higher}, \cite{spivey1999algebra}, \cite{hoare1998unifying}, \cite{gibbons2013unifying}, \cite{friedman05reasoned}, \cite{krishnamurthi2007programming}, \cite{website:lambda-the-ultimate}, \cite{website:takashi-workplace}, \cite{website:mini-prolog-hugs98}, \cite{website:logic-programming-haskell}, \cite{website:stackoverflow}, \cite{website:haskell-choice}, \cite{website:prolog-steam}, \cite{website:prolog-death}, \cite{website:prolog-killer}, \cite{nanoprolog-lib}, \cite{prolog-lib}, \cite{cspm-To-Prolog-lib}, \cite{prolog-graph-lib}, \cite{prolog-graph-lib-lib}, \cite{hswip-lib}, \cite{logict-lib}, \cite{logic-classes-lib}, \cite{proplogic-lib}, \cite{cflp-lib}, \cite{logic-grows-on-trees-lib}, \cite{unification-fd-lib}, \cite{cmu-lib}, \cite{peg-lib}, \cite{monadiccp-lib}, \cite{monadiccp-gecode-lib}, \cite{csp-lib}, \cite{liquid-fix-point-lib}.
\nocite{website:caio},
\end{comment}
The main focus of the
%----------------------------------------------------------------------------
\subsection{Problem Statement}
%----------------------------------------------------------------------------
Programming languages are emerging more frequently than ever before. They include new concepts and features to simplify the process of coding a solution and assisting the programmer by lessening the burden of carrying out standard tasks / procedures. A new one tries to capture the best of the old, learn from the mistaken, add new and move on. But all is not that straight forward, shifting from one language to another is not always easy.
Prolog has a similar story. The original version has given rise to a large number of different flavours but a few drawbacks remain through the bloodline. 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 Prolog is dying if not dead, \cite{website:prolog-steam}, \cite{website:prolog-death}, \cite{website:prolog-killer}, not many people use it and most of the times when it used, the variant is usually "DOWN AND DIRTY PROLOG" and that also many a times in academia. It is not suited for building large programs \cite{wikiprolog}. But there are a lot of good things about Prolog that should not die away. Moreover, Prolog is ideal for search problems.
So the question is how to have all the good qualities of Prolog without actually using Prolog?
How can the two most important Declarative Programming Paradigms be brought together, in this case the idea is to bring Haskell, a Purely Functional Programming Language, one step closer to being something like Prolog, a Logical Programming Language.
Programming languages pop up from time to time. The number of languages today is in the hundreds or even thousands. Not all of them survive or end up being scarcely used. But many a times the case is that even though a language has a lot going for it the reluctancy to change. Other reasons could be that the need dies out or the language is unable to adapt to the changing requirements.
Flipping the coin to the other side we see, the more specific the language 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.
So putting 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.
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 would be 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 will reduce the hassle of jumping between languages and / or forcibly trying to solve a problem according to a paradigm.
The subject in question here is Haskell and the split personality being Prolog. How far can Haskell be pushed to dawn the avatar of 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{enumerate}
\item Embedding
\\*Please see Chapter 8,
\\*{\color{blue} \underline {\nameref{sect:eplipl}}}.
\\*This approach involves, translating a complete language into the host language as an extension such as a library. 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
\item Paradigm Integration
\\* Please see Chapter 11,
\\*{\color{blue} \underline {\nameref{sect:ummcpp}}}
\\* 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.
\end{enumerate}
%----------------------------------------------------------------------------
\subsection{Research Approach and Contributions}
%----------------------------------------------------------------------------
%
\subsubsection{Contributions}
%----------------------------------------------------------------------------
%----------------------------------------------------------------------------
\subsection{Thesis Statement}
%----------------------------------------------------------------------------
The aim of this thesis is to add and / or extend the logical capabilities of the purely functional programming language Haskell which are derived from the logic programming language Prolog.
%----------------------------------------------------------------------------
\subsection{Proposal Organization}
%----------------------------------------------------------------------------
\subsection{The Plan}
\end{document}