diff options
author | thing 1 <thing1@seacrossedlovers.xyz> | 2025-01-09 10:29:44 +0000 |
---|---|---|
committer | thing 1 <thing1@seacrossedlovers.xyz> | 2025-01-09 10:29:44 +0000 |
commit | fb261fb2239a11b89060e4383d2f98950f4c40ad (patch) | |
tree | 5256cd57d189df375a2431affb97c2d51a8207aa /comp/lucas-standen-NEA/writeup2 | |
parent | c3c2da104d75a0a75804377b99057f0be2fe2bcc (diff) |
made the final change to my comp sci
Diffstat (limited to 'comp/lucas-standen-NEA/writeup2')
-rw-r--r-- | comp/lucas-standen-NEA/writeup2/writeup.tex | 109 |
1 files changed, 77 insertions, 32 deletions
diff --git a/comp/lucas-standen-NEA/writeup2/writeup.tex b/comp/lucas-standen-NEA/writeup2/writeup.tex index d81163d..ad925d0 100644 --- a/comp/lucas-standen-NEA/writeup2/writeup.tex +++ b/comp/lucas-standen-NEA/writeup2/writeup.tex @@ -514,25 +514,24 @@ Zippy must support the following features, it needs them to be a usable language many uses. \subsection{Core objectives} \begin{description} - \item[A compiler for the Zippy language] - \item[AST's used to compile source code] - \item[A lisp like syntax] - \item[Functional paradigm language] - \item[Recursion] - \item[Higher order functions] \textit{(this means functions can be passed as arguments to - other functions)} - \item[High performance language] - \item[A package manager] - \item[Ability to call C functions] + \item[1) A compiler for the Zippy language] This will have to take in Zippy code and return some other format, that can be executed. + \item[2) AST's used to compile source code] This means a tree like data structure is needed to process the incoming data and output it in the correct format. + \item[3) A lisp like syntax] This means every expression should look like a lisp S-expression, which is like so \textit{(function arg1 arg2)}. + \item[4) Functional paradigm language] This means the language should draw from other projects like Haskell and Common Lisp, using recursion heavily. + \item[5) Recursion] The language should not have any real limit to how deep recursion can go, unlike languages like python, which have a maximum depth. + \item[6) Higher order functions] This means functions can be passed as arguments to other functions, which is key for the language to be functional. + \item[7) High performance language] The language should be fast, with speeds at or better than python. + \item[8) A package manager] There should be a simple tool used for putting together projects and automating the compiler call. + \item[9) Ability to call C functions] To ensure one can actually do things in the language, they need to be able to call the existing set of C functions. \end{description} If possible I would like Zippy to also meet the following extra objectives. While not needed to make the project usable, it will make it far nicer to work with. \subsection{Extra objectives} \begin{description} - \item[String parsing in the stdlib] - \item[graphs in the stdlib] - \item[networking in the stdlib] - \item[graphics in the stdlib] + \item[1) String parsing in the stdlib] This should be a small library that allows for comparison and modifying of strings. + \item[2) Graphs in the stdlib] This should be a small library that allows the user to easily make graphs and trees. + \item[3) Networking in the stdlib] This would be a wrapper around C-socket style networking. + \item[4) Graphics in the stdlib] This would be a simple front end to a library such as Raylib. \end{description} I think with these objectives in mind I will make a well rounded language that achieves my @@ -1009,30 +1008,29 @@ used with C libraries. \section{Evaluation} At this stage in my project, I have created a full project, and now I need to compare it to my original goals. -Here is a copy of my original goals to avoid needing to flick between many points. +Here is a copy of my original goals to avoid needing to flick between many pages. \subsection{Core objectives} \begin{description} - \item[A compiler for the Zippy language] - \item[AST's used to compile source code] - \item[A lisp like syntax] - \item[Functional paradigm language] - \item[Recursion] - \item[Higher order functions] \textit{(this means functions can be passed as arguments to - other functions)} - \item[High performance language] - \item[A package manager] - \item[Ability to call C functions] + \item[1) A compiler for the Zippy language] + \item[2) AST's used to compile source code] + \item[3) A lisp like syntax] + \item[4) Functional paradigm language] + \item[5) Recursion] + \item[6) Higher order functions] + \item[7) High performance language] + \item[8) A package manager] + \item[9) Ability to call C functions] \end{description} \subsection{Extra objectives} \begin{description} - \item[String parsing in the stdlib] - \item[graphs in the stdlib] - \item[networking in the stdlib] - \item[graphics in the stdlib] + \item[1) String parsing in the stdlib] + \item[2) Graphs in the stdlib] + \item[3) Networking in the stdlib] + \item[4) Graphics in the stdlib] \end{description} \subsection{Comparing the goals to the product} -In order I will evaluate and show where and how these came to be. +In order I will evaluate and show where and how these came to be in my final code. \subsubsection{A compiler for the Zippy language} This was the main goal of the project and I achieved this perfectly as planned, the compiler generates C code that runs @@ -1047,6 +1045,16 @@ it made the rest of the compilation process far easier as there was less worry f This goal was fully met. +This can be seen here: +\begin{lstlisting}[language=C++, caption=AST definition] +typedef struct astNode { + char *func; + char *args[8]; + struct astNode *children[8]; +} astNode; +\end{lstlisting} + + \subsubsection{A lisp like syntax} This goal was also met thanks to the advanced tokeniser I wrote that is capable of generating AST's from individual lines of Zippy, you can see this first hand when you look at the use of parentheses in the language. @@ -1075,11 +1083,28 @@ low level development, which is where Zippy lies on the tech stack. This goal was fully met. +This can be seen here: +\begin{lstlisting}[language=C++, caption=Function pointer support] +else if (strcmp(names[28], node->func) == 0){ // converting function pointer definition staments + checkNULL(node->args[0], "expected function ptr type"); + checkNULL(node->args[0], "expected function ptr name"); + out = appendsnprintf(out, MAXOUTLEN, "%s (*%s)", node->args[1], node->args[0]); + int i = 2; + while (node->args[i] != NULL){ + if (i != 2) out = appendsnprintf(out, MAXOUTLEN, ","); + else out = appendsnprintf(out, MAXOUTLEN, "("); + out = appendsnprintf(out, MAXOUTLEN, "%s", getVarType(node->args[i])); + i++; + } + out = appendsnprintf(out, MAXOUTLEN, ")"); +} +\end{lstlisting} + \subsubsection{A high performance language} As it was previously seen in the examples section, zippy has been able to crush python, and for me this was enough. For most use cases python is fast enough, and thus zippy being faster means it will never be too slow. -This goal was fully met. +This goal was fully met as seen in my comparisons against python. \subsubsection{A package manager} I believe zpypkg was exactly what I wanted to make, it is small fast and too the point, it doesn't get in the programmers way @@ -1109,6 +1134,7 @@ One could argue that all of these things are possible, as it is possible to link for you, but in some ways that cheating, and also won't work for libraries written in C++. \subsection{Final client response} +\subsubsection{Amy c} To finally test my project I will get my client (Amy C) to use zippy for some simple tasks, and see what they thing of it. \begin{description} @@ -1119,10 +1145,29 @@ To finally test my project I will get my client (Amy C) to use zippy for some si \item[What would you change about Zippy?] I would add syntax highlighting to editors (VSCode, micro, etc.) \item[Any other comments about Zippy?] - It meets enough requirements to be usable. + I would have preferred if the language felt more fleshed out in some places, such as error messaging. As + in the current state the language doesn't feel fully finished. \end{description} +\subsubsection{Response to Amy C} +I overall agree with the points Amy has made, the language could have been made bigger and error messages could have been put +ahead on the projects planning. I would also have liked to implement code editor integration but it was out of the scope of the +project. + +\subsubsection{Myself} +As previously stated I am one of the clients for this project as I wanted to make something that I could use or extend. I feel +that I have achieved this, however I'd like to remake large chunks of it into something bigger, and with hindsight I feel confident +to explore the concepts I first introduced here into something larger. + \section{Conclusion} +\subsection{What would I change if I did this again?} +If I was given the opportunity to remake Zippy I would like a few things different. Firstly, I wish I had thought of how +I was going to implement error messages earlier on in the process, as they felt rather slapped on the side, and didn't give +messages in a verbose enough manner. Secondly, I would have liked it if the language drew less on C functions when being used; +the point of the languages was to be higher level than C, and while it was in some aspects, some rather missed the mark. Finally +I would have liked to have made the AST's that power the compiler to rely less on strings and more on nested data structures; +I found the compiler became messy in the code generation section as it was a lot of string parsing which should have been done +in earlier steps in the compilation process. \subsection{Final thoughts} Overall I believe this project has achieved its goals nicely, I have made a simple language that has the power of C and the syntax of lisp, with added memory safety; this is what I set out to do. Along this project many things changed, from |