Higher Logics

In any system with mutable entities saved in an object store, it's inevitable that you'll want to audit the changes made to a particular entity. Explicitly versioning your entities solves this problem, and it's often pretty useful to end users of a sophisticated application, say for undo purposes. However, it's not always so clear how to transform a mutable entity into an versioned entity. There are also a number of complications to versioning mutable objects: Handling parent-child relations such that a child change does not propagate to every parent Supporting efficient queries on history Supporting efficient queries for the newest version Space complexity of data representation Concurrent changes Some of the above properties also have a natural tension, ie. supporting efficient queries often require storing more data so their space complexity is worse. I'm going to provide an overview here of a very simple schema for versioned entities with the following...

I just wanted to jot down some thoughts on compiling eval/apply curried application using an efficient register-based calling convention. This translation is actually quite simple once you get the trick. Leroy's Zinc abstract machine showed the way: evaluate arguments right-to-left instead of the typical left-to-right. The ZAM wrote these arguments to a stack, but in our case we want them to go to the register file first. So we evaluate arguments right-to-left and write them into registers left-to-right, ie. argN goes in reg0, argN-1 goes to reg 1, ... arg0 goes to regN. At some threshold, we'll run out of registers. If your program is in direct-style with a stack, this threshold is often defined by the callee-save registers of the native calling convention. If your program is in CPS form, then you can use the entire register file. Once you run out of registers, you have to spill the remaining arguments to the stack. However, the stack is simply a register pointing to some...

Algebra.NET is a simple library designed to facilitate easy expression and manipulation of algebraic functions. For instance, here's a simple function: Function<Func<double, double>> a = Algebra.Function(x => 2 * x + 1); We can compile such a function to efficient IL: Func<double, double> func = a.Compile("times2plus1"); Or we can apply some algebraic identities to rewrite it: Identity associative = Algebra.Identity(x => x + 1 == 1 + x); Identity mulEqAdd = Algebra.Identity(x => 2 * x == x + x); Console.WriteLine(a); Console.WriteLine(a.Rewrite(1, associative, mulEqAdd)); // Prints: // ((2 * x) + 1) // (1 + (x + x)) Rewrites can sometimes loop forever (consider "x + y == y + x"), so the Rewrite method takes a number indicating the maximum number of iterations to perform all the rewrites. All the usual arithmetic operations are available, including an extension method for exponentiation: var f = Algebra.Function(x => x.Po...

A few new features in this release, and a few bugfixes and enhancements in MIME parsing. As before, the online docs are available on my site, the full release including experimental assemblies on Sourceforge , and the production assemblies on Nuget . The changelog: * sasametal can now replace columns and FK associations with enums that are provided separately * sasametal can now output an interface file, which generates an interface describing the database entities * many MIME fixes thanks to a few bug reports on Sasa discussion list * added System.Data, which provides useful extensions to ADO.NET and IQueryable, like a simple interface for batched SQL queries * MIME parser now accepts an optional parsing parameter that controls various parsing options, like how strict e-mail address formatting accepted, and whether HTML views should be parsed into MailMessage.Body * added enum as a primitive to Sasa.Dynamics IReducer and IBuilder * fixed Sasa.Enums .IsSequenti...

Just a bugfix release, mainly for the MIME parsing. Changelog: * added support for 8bit transfer encoding, even if not supported by .NET <4.5 * support content types whose prologue is empty * added support for arbitrarily nested multipart messages * added alternative to Enum.HasFlag that invokes Sasa's faster enum code As usual, online docs are available , or the a CHM file is available on Sourceforge .

I've had numerous posts here describing instances where C# has come so close to getting it right, and yet misses the mark by an inch. The original C# enums have a simple semantics: enum SomeEnum { First, // compiler implicitly assigns 0 Second, // compiler implicitly assigns 1 Third, // compiler implicitly assigns 2 Fourth, // compiler implicitly assigns 3 } This worked nicely as a concise expression of a need for a set of distinct of values, but without caring what they are. C# later introduced the [Flags] attribute, which signals to the compiler that a particular enum isn't actually a set of disjoint values, but a set of bit flags. However, the compiler doesn't actually change its behaviour given this change of semantics. For instance, the following enum is completely unchanged, despite the semantically meaningful change to a set of bitwise flags: [Flags] enum SomeEnum { First, // compiler implicitly assigns 0 Second, // compiler implicitly assign...

Mainly a bugfix release, with only a few new features. As always, the docs are available here online , or as a compiled CHM file on sourceforge . Here's the changelog: * a few bugfixes to MIME parsing for header and word decoding (Thanks Evan!) * added combined SubstringSplit function for more space efficient parsing * explicitly parse e-mail addresses for more flexible address separators * NonNull now throws an exception if encapsulated value is null, which is used in the case when the instance is invalidly constructed (Thanks Mauricio!) * build now checks for the presence of the signing key and ignores it if it's not present * a more efficient Enum.HasFlag using codegen * added a new ImmutableAttribute which Sasa's runtime analyses respects * FilePath's encapsulated string now exposed as a property Thanks to Evan/iaiken for a number of bug reports, and to Mauricio for feedback on the NonNull<T> pattern.

This release features a few new conveniences, a few bugfixes and a vector that's faster than any other I've managed to find for .NET. Here's the changelog since the last v0.14.0 release: * more elaborate benchmarking and testing procedures * added a minor optimization to purely functional queues that caches the reversed enqueue list * FingerTree was switched to use arrays as opposed to a Node type * optimized FingerTree enumerator * FingerTree array nodes are now reused whenever possible * Sasa.Collections no longer depends on Sasa.Binary * MIME message's body encoding is now defaulted to ASCII if none specified * added convenient ExceptNull to filter sequences of optional values * NonNull<T> no longer requires T to be a class type, which inhibited its use in some scenarios * fixed null error when Weak<T> improperly constructed * added variance annotations on some base interfaces * added a super fast Vector<T> to Sasa.Collections *...

The µKanren paper is a nice introduction to a lightweight logic programming language which is a simplification of the miniKanren family of languages. The existing µKanren implementation in C# was a translation from Scheme, and thus is verbose, untyped with lots of casts, and non-idiomatic. I also found most of the other Kanren implementations unnecessarily obscure, heavily relying on native idioms that aren't clear to newcomers. uKanren.NET provides a clear presentation of the core principles of µKanren using only IEnumerable<T> and lambdas, showing that µKanren's search is fundamentally just a set of combinators for transforming sequences of states. The values of the sequence are sets of bound variables that satisfy a set of equations. For instance, given the following expression: Kanren.Exists(x => x == 5 | x == 6) You can read it off as saying there exists an integer value to which we can bind variable x, such that x equals either 5 or 6 [1]. Solving this eq...

NHibernate is a pretty useful tool, but occasionally it's not entirely documented in a way that makes it's flexibility evident. Composite keys are a particularly difficult area in this regard, as evidenced by the numerous articles on the topic. Most of the existing articles cover this simply enough, but there is one uncommon corner case I have yet to see explained anywhere: a composite primary key one of whose key properties is an association with a composite key. This is probably pretty uncommon and there are ways around it, hence the lack of examples, but as a testament to NHibernate's flexibility, it's possible! Here's the example in code listing only the primary keys: public class MotorType { public Horsepower Horsepower { get; protected set; } public VoltageType VoltageType { get; protected set; } } public class Motor { public MotorType MotorType { get; protected set; } public Efficiency Efficiency { get; protected set; } } The tables look like this...