Higher Logics

Just a quick announcement that Sasa v0.12.0 was just released. You can obtain the individual assemblies via Nuget , or the whole set from Sourceforge . The docs are available as a CHM file on sourceforge, or online here . Overview This release includes a few fixes, the most prominent of which are in the HTML parser and the parsing of MIME linked resources. Note that since v0.11.0, some extension methods on MailMessage have been deprecated due to Microsoft's recommended usage guidelines. The headers those extension methods accessed are overwritten whenever a MailMessage is sent via SmtpClient, so it's better not to rely on them. A new feature is the sasametal utility, which is basically a wrapper around sqlmetal that normalizes some of the bizarre property names from sqlmetal into more CLR friendly names. A forthcoming blog post will cover the use of this tool. Other new features include first-class references , and first-class slots . These are currently in the core Sa...

Yesterday, I posted about the new extension of IRef<T> to arbitrary reference semantics for the CLR, including referencing inner fields, properties, and array slots. First-class references make it simple to operate on specific mutable data without caring about the underlying type of that data. I just pushed another abstraction that handles a related, but different case: first-class slots . ISlot<T> An object "slot" is a value that designates a mutable location of a specific class of values, not a mutable location of a specific instance like first-class references. Where first-class references hide the underlying object type, slots expose the object type and allow you to mutate the slots of multiple objects at once, as long as they are subtypes of the slot's object type. Here's the declaration of ISlot&ltT>: public interface ISlot<TObj, T> { T Get(TObj obj); T Set(TObj obj, T value); } As you can see, the object we're man...

References in C# are second-class citizens, which is to say, that you cannot pass them around as values. They can appear in function parameter position, but that's it: public static void DoFoo(ref int value) { Action captureRef = () => value = 3; // ERROR: ref can't escape scope } This makes it easy to verify their safety statically, and makes them very efficient, but it somewhat limits their expressiveness. First-class citizens can be passed around as values, and otherwise used in any way that you'd use any other object. The above capture would work, for instance. To make references first-class citizens means constructing an object that exposes get and set operations, and that can reference the internals of any .NET type. IRef<T> Sasa has had the IRef<T> type for quite some time, but its full potential as a first-class reference hasn't been realized. There was only a single implementation, and that was a simple mutable slot as found in ML. I...

Scala and Haskell both have very useful type-directed concepts for resolving implicit function parameters, called "implicits" and "type classes" respectively. To illustrate the impact of this, consider a generic sorting function like Enumerable.OrderBy . It must define two overloads, one that takes a custom comparer, and one that does not and so should use a default comparison for type TKey: public static IOrderedEnumerable<TSource> OrderBy<TSource, TKey>( this IEnumerable<TSource> source, Func<TSource, TKey> keySelector, IComparer<TKey> comparer ) public static IOrderedEnumerable<TSource> OrderBy<TSource, TKey>( this IEnumerable<TSource> source, Func<TSource, TKey> keySelector ) While it's simple to define the second overload as calling the first with Comparer<TKey>.Default for the custom comparer, in general, for N overridable parameters, you would need to define something like f...

A new release of Sasa is now available on Sourceforge and Nuget. This release contains few bugfixes and some minor new convenience features. Changelog MailMessage extension method Reply() now considers the media type of the original body, and if it's not text/plain, then the original body is attached to the reply message as an inline attachment if original e-mail doesn't specify sufficient content-type information, generate it and reset the original e-mail's header new IEnumerable extensions, SingleSelect and FirstSelect, which select a component of the only or first items in a sequence, respectively, that match an optional predicate, even if the item returned is null refactored ToRaw extension to simplify and generalize MIME output more rigourous MIME parsing tests parsing MIME views now properly propagates the transfer encoding and contentId Html parser element tags and content can now be mutated You can also view the full documentation online .

I just uploaded v0.10 of Sasa , my open source class libraries. This release features a few small bugfixes and enhancements to MIME parsing, and some useful new concurrency features. .NET 4.0 binaries are now also provided. Bugixes bugfix: added some runtime fixes due to semantic changes in .NET 4.0 base class libraries bugfix: multipart/alternative MIME messages are now parsed into the containing message's alternate views bugfix: set a MailMessage reply's From property if a source address is available bugfix: ThreadScoped now properly reclaims data across threads bugfix: more efficient and safer Lazy initializer New new: provided builds for .NET 4.0 new: added Atomics.Read and Atomics.Write thread-safe read/write operations that perform atomic reads larger-than-word structs without locks [1] new: added simple load-linked/store-conditional operations, under Atomics.LoadLinked/StoreCondition, and Sasa.Concurrency.LLSC new: added a LockSet object which takes locks in ...

I recently came across Vance Morrison's blog post on the relative costs of dynamic type tests on the CLR, and I was struck by how much my experience differed from the results he received. In past tests, I had concluded that operations and comparisons using System.Type were just as fast as operations on System.RuntimeTypeHandle . This struck me as a little odd at the time, but numbers don't lie. Vance helpfully provided the code he used for his benchmarks, so I decided to see if perhaps I was mistaken. Lo and behold, the numbers I received from running his code matched my past results, ie. RuntimeTypeHandle provided no advantage. This seemed extremely odd, and after digging a little deeper, it turns out that Vance and I are both right. I've been doing most of my development on 64-bit x64 machines, and I suspect Vance was running x86 at the time. It turns out that the x64 runtime for the CLR is woefully underperforming when compared to x86, at least for this type of code...