<commit_before>\chapter{Discussion}

Here a discussion on future development plans will follow. It will examine ideas that was not imlemented, but was considered by the group for future adition. The discussion will consider the results of adding features to TLDR, and how the principles of the language could have been futher supported or changed by those.

TLDR, being a language focused on allowing easy modelling shares a lot of principles with object oriented programming languages, and so the inclusion of common object oriented features is a likely idea. Including inheritance in some form or another would be a good way to allow for faster and more precise programming. Possible candidates could be traits, interfaces, abstract actors or some type of inheiritance. Interfaces could be very useful for making sure that messages are only sent to actors which actually implements a receive for that message, while still allowing multiple types of actors to be candidates. The usefulness of inheiritance or other ways of sharing functionalities across different actors, are also a good idea, since it will allow for more concise code and faster writing.

Another matter is the support for discrete simulations, as described in \cref{iterprob}. The solutions suggested are based around grouping actors into units, which work isolated from the rest of the actors. This idea of grouping actors, could potentially be used for other purposes, such has highly modular programs and functionalities, and promote purity when writing code in TLDR. But what is more interesting, is the possibility of a change of focus, from having the programmer think in terms of how actors mimic real things, to focusing on having environments mimic the conditions reality sets for things. Examples could be chemistry or physics, where one could want to find the optimal conditions for a chain reaction to occur. This problem could be approached by creating a single version of the actor, and then have the environments implement the changes in values, temperatures, pressure or what it might be. Such an apporach might be useful for problems where certain objects behavior can be discribed through know matematical structures, but where the conditions can change immensely and by extension, the results of a given simulation.

\section{Compiler}

The compiler developed for TLDR does not fully implement TLDR. This section will list which parts of TLDR is implemented in the compiler, and which parts are not.

Not implemented:

\begin{itemize}
\item Functions - Code generation is not implemented
\item Dynamically allocated lists. The lists currently implemented are simply arrays. See \cref{codegen:lists}
\item Tuples - Code generation is not implemented
\item List operations - Currently lists can only be manipulated by indexing into the list and can be iterated with a for-in-loop
\end{itemize}<commit_msg>afsnit om hvad vores compiler kan/ikke kan<commit_after>\chapter{Discussion}

Here a discussion on future development plans will follow. It will examine ideas that was not imlemented, but was considered by the group for future adition. The discussion will consider the results of adding features to TLDR, and how the principles of the language could have been futher supported or changed by those.

TLDR, being a language focused on allowing easy modelling shares a lot of principles with object oriented programming languages, and so the inclusion of common object oriented features is a likely idea. Including inheritance in some form or another would be a good way to allow for faster and more precise programming. Possible candidates could be traits, interfaces, abstract actors or some type of inheiritance. Interfaces could be very useful for making sure that messages are only sent to actors which actually implements a receive for that message, while still allowing multiple types of actors to be candidates. The usefulness of inheiritance or other ways of sharing functionalities across different actors, are also a good idea, since it will allow for more concise code and faster writing.

Another matter is the support for discrete simulations, as described in \cref{iterprob}. The solutions suggested are based around grouping actors into units, which work isolated from the rest of the actors. This idea of grouping actors, could potentially be used for other purposes, such has highly modular programs and functionalities, and promote purity when writing code in TLDR. But what is more interesting, is the possibility of a change of focus, from having the programmer think in terms of how actors mimic real things, to focusing on having environments mimic the conditions reality sets for things. Examples could be chemistry or physics, where one could want to find the optimal conditions for a chain reaction to occur. This problem could be approached by creating a single version of the actor, and then have the environments implement the changes in values, temperatures, pressure or what it might be. Such an apporach might be useful for problems where certain objects behavior can be discribed through know matematical structures, but where the conditions can change immensely and by extension, the results of a given simulation.

\section{Compiler}

The compiler developed for TLDR does not fully implement TLDR. This section will list which parts of TLDR is implemented in the compiler, and which parts are not.

\sinote{ikke helt sikker på alt er noteret}

Implemented:

\begin{itemize}
\item Addition, subtraction, multiplication, division, root, power, modulo, equalityoperations on ints and reals
\item And, or, equality operations on bools
\item For-in statement
\item Lists as arrays. See \cref{codegen:lists}
\item If and if-else statements
\item While loops
\item print, printint, printreal functions
\item Actors
\item Spawn, send, receive and die operations
\item Integer, boolean and real number constants
\item Struct definition, struct field access and initialisation
\end{itemize}

Not implemented:

\begin{itemize}
\item Functions - Code generation is not implemented
\item Dynamically allocated lists. The lists currently implemented are simply arrays. See \cref{codegen:lists}
\item Tuples - Code generation is not implemented
\item List operations - Currently lists can only be manipulated by indexing into the list and can be iterated with a for-in-loop
\item Data casts - Only supported in grammar
\item NAND, NOR and XOR - Code generation not implemented
\item Char constant - Code generation not implemented
\item Comparison of tuples, structs - Type checking and code generation not implemented
\end{itemize}
{'fraction_non_alphanumeric': 0.030718265321487727, 'fraction_numerical': 0.0, 'mean_word_length': 4.898756660746003, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, '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': '3585095', 'n_tokens_mistral': 1445, 'n_tokens_neox': 1400, 'n_words': 1004}