<?xml version="1.0" encoding="utf-8"?><!-- generator="WordPress/2.9.2" -->
<rss version="0.92">
<channel>
	<title>samskivert</title>
	<link>http://samskivert.com</link>
	<description>Ramblings by one Michael D. Bayne</description>
	<lastBuildDate>Sun, 07 Mar 2010 01:28:32 +0000</lastBuildDate>
	<docs>http://backend.userland.com/rss092</docs>
	<language>en</language>
	
	<item>
		<title>Integration of Typed and Untyped Code in Thorn &#8211; Wrigstad, et al.</title>
		<description><![CDATA[I already reviewed the other Thorn paper, Thorn—Robust, Concurrent, Extensible Scripting on the JVM. This one just goes into more detail on the type system, and how like-types interact with dynamic and static types. I like the idea of minimizing the impact of converting part of your code to being type checked, as a step [...]]]></description>
		<link>http://samskivert.com/2010/03/integration-of-typed-and-untyped-code-in-thorn-wrigstad-et-al/</link>
			</item>
	<item>
		<title>Lackwit: A Program Understanding Tool Based on Type Inference &#8211; O&#8217;Callahan and Jackson</title>
		<description><![CDATA[Another crazy use of type systems. Here the idea is to completely ignore the declared types of variables and instead just run a type inference algorithm (Milner&#8217;s Algorithm W) on the program and see what types you get. Instead of using primitive operations (like addition) to constrain variables to representation types (like int), you just [...]]]></description>
		<link>http://samskivert.com/2010/03/lackwit-a-program-understanding-tool-based-on-type-inference-ocallahan-and-jackson/</link>
			</item>
	<item>
		<title>Principal type-schemes for functional programs &#8211; Damas and Milner</title>
		<description><![CDATA[This is a follow-up to Milner&#8217;s introduction of the type inference algorithm known as Hindley-Milner or Algorithm W. Here they provide a sketch of a proof that it infers &#8220;principal&#8221; types which are the most general possible types. (This proof was given by Hindley over a decade earlier, but apparently Milner nor the any of [...]]]></description>
		<link>http://samskivert.com/2010/03/principal-type-schemes-for-functional-programs-damas-and-milner/</link>
			</item>
	<item>
		<title>Finding User/Kernel Pointer Bugs With Type Inference &#8211; Johnson and Wagner</title>
		<description><![CDATA[More fun with type systems! Here they use type annotations to distinguish between pointers under user control and pointers under kernel control, and type inference to allow them to only add annotations on system calls and on functions where passing a user pointer is safe and where it&#8217;s not. The type inference fills in everything [...]]]></description>
		<link>http://samskivert.com/2010/03/finding-userkernel-pointer-bugs-with-type-inference-johnson-and-wagner/</link>
			</item>
	<item>
		<title>The Design of a Task Parallel Library &#8211; Leijen et al.</title>
		<description><![CDATA[Describes a library for .NET that introduces constructs for lightweight parallel programming, mainly Parallel.For and Parallel.Aggregate. These are parallel for-loops and fork/join (also popularly known as map/reduce). Unlike DPJ, these guys don&#8217;t provide a type system or any guarantees that you&#8217;re not shooting yourself in the foot. They claim those are &#8220;orthogonal concerns&#8221; which is [...]]]></description>
		<link>http://samskivert.com/2010/03/the-design-of-a-task-parallel-library-leijen-et-al/</link>
			</item>
	<item>
		<title>Strictly Declarative Specification of Sophisticated Points-to Analyses &#8211; Bravenboer and Smaragdakis</title>
		<description><![CDATA[Describes a points-to analysis expressed entirely as a Datalog program. (Datalog is awesome!) They focus on the optimizations done to the Datalog program to allow the analysis to be faster and more scalable than the state-of-the-art (the paper being from OOPSLA 2009). The existing techniques have moved toward using BDDs to improve scalability and these [...]]]></description>
		<link>http://samskivert.com/2010/03/strictly-declarative-specification-of-sophisticated-points-to-analyses-bravenboer-and-smaragdakis/</link>
			</item>
	<item>
		<title>Points-to Analysis by Type Inference of Programs with Structures and Unions &#8211; Steensgaard</title>
		<description><![CDATA[Extends the work described in Points-to Analysis in Almost Linear Time, which didn&#8217;t handle structs or unions (all this is for C). Unfortunately, C&#8217;s &#8220;type system&#8221; makes this work very messy because they need to account for all the nasty things you can do with structs (like overwrite two adjacent int fields by assigning through [...]]]></description>
		<link>http://samskivert.com/2010/03/points-to-analysis-by-type-inference-of-programs-with-structures-and-unions-steensgaard/</link>
			</item>
	<item>
		<title>Points-to Analysis in Almost Linear Time &#8211; Steensgaard</title>
		<description><![CDATA[Describes a cool technique for turning a points-to analysis into a type inference problem&#8212;one that can be done in almost linear time, hence the title. As type checking is flow-insensitive, so is the analysis, and since it infers monomorphic types, the analysis is also context-sensitive, but there&#8217;s nothing stopping you from doing a polymorphic inference [...]]]></description>
		<link>http://samskivert.com/2010/03/points-to-analysis-in-almost-linear-time-steensgaard/</link>
			</item>
	<item>
		<title>Using Predicate Abstraction to Reduce Object-Oriented Programs for Model Checking &#8211; Visser, et al.</title>
		<description><![CDATA[My introduction to predicate abstraction (not the first work to make use of it), another interesting technique. Basic idea is: you have some complicated state in your program that is causing your model checker to blow up (i.e. consider too many states), replace it with a predicate over that state that captures whatever it is [...]]]></description>
		<link>http://samskivert.com/2010/03/using-predicate-abstraction-to-reduce-object-oriented-programs-for-model-checking-visser-et-al/</link>
			</item>
	<item>
		<title>Counterexample-Guided Abstraction Refinement &#8211; Clarke, et al.</title>
		<description><![CDATA[This paper was part of my introduction to model checking. It introduces an idea that has gotten a lot of mileage in the program analysis and model checking community. To wit: start with a rough (but soundly over-approximating) abstraction, if said abstraction demonstrates a violation figure out whether the violation is real (you&#8217;re done) or [...]]]></description>
		<link>http://samskivert.com/2010/03/counterexample-guided-abstraction-refinement-clarke-et-al/</link>
			</item>
</channel>
</rss>
