Thesis-Proposal/futureScope.tex at master · ms280690/Thesis-Proposal · GitHub

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
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
\documentclass[thesis-solanki.tex]{subfiles}


\ifMain
\externaldocument{thesis-solanki}
\fi
\begin{document}

%----------------------------------------------------------------------------
\chapter{Future Scope}\label{chap:futureScope}

This chapter discusses additions that could be made to the contributions of this thesis.


\section{\progLang{Prolog} quasiquoter with antiquotation}
As discussed in Section~\ref{background:approachestointegration} and Section~\ref{hwh:quasiquotationandhaskell}, a
quasiquoter provides an economy of expression to describe a program in the eDSL.
Listing~\ref{tab:qqprlginhskll} shows an example.

\begin{code-list}[H]
\begin{singlespace}
\inputminted{haskell}{haskell-proto4-qq-prlg-in-hskll.hs}
\end{singlespace}
\caption{A sample quasi quoted expression for \progLang{Prolog} in \progLang{Haskell}}
\label{tab:qqprlginhskll}
\end{code-list}

This not only provides a simpler interface but also allows interchangeable usage of programming constructs of
different languages in the same expression.
For the example above, \prologConstruct{X} is a \progLang{Prolog} variable and \haskellConstruct{varY} is a
\progLang{Haskell} variable injected into the expression

\section{Runtime search strategy selection}
The \progLang{Prolog} interpreter in Chapter~\ref{proto3} can work with multiple search strategies.
The search must be provided at compile time and hence one must make an estimated guess to the nature of the problem
to select the most appropriate choice.
A possible solution to this problem could be the addition of providing and/or switching the search strategy at
runtime.
Listing~\ref{tab:queryresolvervariablesearchstrat} depicts an example query request.

\begin{code-list}[H]
\begin{singlespace}
\inputminted{haskell}{haskell-proto4-query-resolver-variable-search-strat.hs}
\end{singlespace}
\caption{Query resolver with variable search strategy}
\label{tab:queryresolvervariablesearchstrat}
\end{code-list}

A potential improvement would be add a construct to the abstract grammar itself which can allow to change the
search strategy dynamically.

\section{Database operations for \progLang{Prolog}}
Operations for manipulating the clause database containing facts and clauses are provided with many
\progLang{Prolog} distributions such as \progLang{SWI Prolog} \cite{website:swiprologdbops}.
Operations such \prologConstruct{assertz} \cite{website:assertzswiprolog} would provide the ability to modify the
knowledge base at runtime.
This is only partially implemented by \codeLibrary{prolog-0.2.0.1} \cite{prolog-lib}.

Moreover, \progLang{SWI Prolog} provides multiple mechanisms for storage and modification as described in
\cite{website:swiprologdbops}.

\section{Multi type variable language}
The eDSl \haskellConstruct{FlatTerm} has a single type variable i.e.,

\mint{haskell}|FlatTerm a|

This restricts the constructors (generated terms) to all be of the same type or no type.
An eDSL with multiple type variables will provide its constructors with multiple options resulting in multi-type
terms generated by the grammar.
Listing~\ref{tab:multitypevariableedsl} shows an example.

\begin{code-list}[H]
\begin{singlespace}
\inputminted{haskell}{haskell-proto4-multi-type-variable-edsl.hs}
\end{singlespace}
\caption{Multi type variable eDSL}
\label{tab:multitypevariableedsl}
\end{code-list}

In the above example, the \haskellConstruct{c} type variable is not used by any constructor in
\haskellConstruct{FlatTerm} and the fixed point will be calculated around it.

Continuing the example from the previous section, with multi typed constructors one can have constructor specific
unification.
Generally speaking, quantifiers and logic can be programmed per constructor adding to the extensibility of the
language.

\section{Additions and extensions to prototype 4}
Chapter~\ref{proto4} defines a grammar for encapsulating and ultimately controlling impure actions in a language.
The constructors are split into two types representing pure and impure actions.
A program would be a chaining/ sequence of these actions.
The possibility of a constructor having a pure and an impure component would be possible if the language has
multiple type variables.
Listing~\ref{tab:hybridconstruct} provides an example.


\begin{code-list}[H]
\begin{singlespace}
\inputminted{haskell}{haskell-proto4-hybrid-construct.hs}
\end{singlespace}
\caption{Grammar with hybrid constructors}
\label{tab:hybridconstruct}
\end{code-list}

Moreover, Chapter~\ref{proto4} lacks an accompanying implementation.


Recapitulating, this chapter provided us with points where this thesis could be extended in the future along with
suitable samples for the respective implementations.


\ifMain\ifDraft
\begin{scope}
  \nolinenumbers
  \enotesize
  \par
  \begin{singlespace}
  \setlength{\parskip}{12pt plus 2pt minus 1pt}
  \theendnotes
  \par
  \end{singlespace}
\end{scope}
\unbcbibliography{bibliography}
\fi\fi
\end{document}