Problem

There are only a limited number of utils available. Many actions with automata require converting between types, creating new automata etc.

Related: #13

Solution:

Introduce utilities for:

• Parsing DFAs #13
• Defining a NFA for a language that is the reverse of another NFA language
• DFA/NFA to regex.

• Support Epsilon edges
• Convert NFA to DFA

Problem

There is no way to convert a NFA in to a DFA.

Possible solutions

Create an algorithm to convert NFAs to DFAs using the Sipser's algorithm described in "Introduction to the Theory of Computation"

Problem

The exceptions present are not helpful. Currently there are only two IllegalArgument IllegalAutomatonState.

Solution

Introduce more exceptions.

Extending from IllegalArgument:

• InputNotInAlphabet(c:char) - to deal with situations where the character is not part of the automaton alphabet
• UnkownState(stateName:string) - to deal with when the input state does not exist
• StateAlreadyExists(stateName:string) - to deal with adding of state if it already exists

Problem

There are numerous action flows that are currently being done manually, such as running the test suite on pull requests and manually publishing the package on new tag release. There should be a CI to deal with this issue.

Possible solution

Add workflows to deal with this.

• Tag release to npm publish
• Running Jest on pull request

Problem

The creation of alphabets is very awkward and bloated. There must be instead an Alphabet class with according methods to add and remove characters.

This however opens an issue as the Alphabet remains mutable which could introduce problems with concurrency in the DFA.

Possible solutions

Create an Alphabet class. Disallow mutation of the alphabet once the DFA has been created with it.

Problem

Having covered regular languages and algorithms for them, the package should be upgraded to encompass context free languages and stack based automata

Solution

Define a PDA class, update the Alphabet to employ different types of input (to allow for pushing and reading from the stack)

Problem

The creation of a finite automaton, especially the definition of the transition function, is bloated and requires a lot of lines of code for simple automata.

Possible solution

Introduce a Builder design pattern for the Finite Automata.

Problem:

As suggested by @vesk4000, there could be a DFA / Automata parser from some string that represents the DFA. This could come particularly handy (naive to say) when TM are introduced into the package.

Solution:

• introduce a DFA parser to construct DFAs from a string representing it
• make it fail on illegal, ill-formatted input.
• OPTIONAL: make it possible to choose the delimiter symbols to support other ways of representing DFAs as a stringr