About Jolt.NET Libraries

Inspired by the Boost C++ libraries, Jolt.NET aims to complement the .NET Base Class Library (BCL) with algorithms, data structures, and general productivity tools. It is the hope of the authors that the features of Jolt.NET will one day be part of, or represented in the BCL and the .NET Framework.

Return to Developing Jolt.NET

Good day readers!

Over the past few months, I haven't spend any time time on the Jolt.NET project as I've experienced several life-changes that require the reallocation of the limited time I have to spend on hobbies.  My daughter was born in February and she has brought much joy to my family.  As with most newborns, she is a handful, and requires near-constant supervision.  I've also recently changed roles within my firm, and my new responsibilities require more of my time.  Recently, things have started to become more routine and so I'm hoping to return to the Jolt.NET project and complete some pending items of importance.  

Non-deterministic FSM Support

One such item of importance is the support of enumerating non-deterministic automata.  When implementing this feature, I realized that I needed to introduce a breaking change into the generalization of an FSM enumerator as the IFsmEnumerator<T> interface conveys that all enumerator implementations return one state as part of a transition.  Since this is not true for non-deterministic FSMs, the interface is changed to the following.

public interface IFsmEnumerator<TAlphabet>
{
bool Next(TAlphabet inputSymbol);
string CurrentState { get; }
IEnumerable<string> CurrentStates { get; }
}

The main differences in this interface revision are the semantics of the CurrentState and (new) CurrentStates properties for different types of enumerators.  When the enumerator is reading a deterministic FSM, CurrentState refers to the current enumeration state, and CurrentStates is a collection containing a single reference to CurrentStates.  However, when the enumerator is reading a non-deterministic FSM, CurrentStates contains the current enumeration states (which may be more than one) and CurrentState refers to the first element of the CurrentStates collection.

The consequences of this interface change propagate to the following FiniteStateMachine<T> methods.

public class FiniteStateMachine<TAlphabet>
{
// ... other members omitted for brevity ...

public virtual IFsmEnumerator<TAlphabet> CreateStateEnumerator(EnumerationType type, string startState);

public virtual ConsumptionResult<TAlphabet> Consume(EnumerationType type, IEnumerable<TAlphabet> inputSymbols);
}

When creating an enumerator via the CreateStateEnumerator() method, the type of enumeration must be specified.  Consequently, the type of enumeration must also be specified when consuming a set of input symbols via the Consume() method.

Finally, the ConsumptionResult<T>.LastState property is replaced with the LastStates property, returning a collection of states denoting the set of states viewed immediately prior to completing the symbol consumption.

public sealed class ConsumptionResult
{
// ... other members omitted for brevity ...

public IEnumerable LastStates { get; }
}

ReadOnlyDictionary<T,U> Support

Creating a read-only IDictionary<T,U> collection is a fairly straight-forward task, but this analog to ReadOnlyCollection<T> is surprisingly missing from .NET 4.0.  I have an immediate need for this type in a side project and thus will include a complete implementation it in the library.

For reference, ReadOnlyCollection<T> is an adaptor to IList<T> that prevents a caller from changing the internal structure of the adapted collection (i.e. adding/removing elements).  When a method to change the structure of the collection is called, a NotSupportException is raised and the collection remains unmodified.

Honoring Existing Interfaces on Generated Types

When first developing Jolt.NET, I focused on a tool that will generate an interface and proxy type to any other type.  The goal of this task was to facilitate dependency injection for static types as this is a common problem to tackle when unit testing with existing, non-modifiable static types.  Note that the current implementation doesn't restrict you from generating the interface/proxy pair for just static types.

One challenge that arose during the implementation was dealing with propagating public interface implementations to the proxy/interface pair.  This made a lot of sense since you could use the generated types with methods that accept the abstraction, and everything would just work.  Unfortunately, I found this to be very difficult at the time and postponed implementing it.

I believe I now have a good algorithm to solve this problem (as described in this forum post), and will to try to implement it.