Projects

Saturday, October 9th, 2004 12:22

Implementing the stream-IO interfaces for E. It's mostly complete, but there's an executing-blocking-code-in-the-wrong-thread bug which Shouldn't Be Happening. I'm inclined to think it's a bug in E, except that the code explicitly does things which break E's reference discipline and I'm not sure that it isn't due to that.

An RDF parsing/processing library in E, which was the subject of the previous post. Stalled because I found the design didn't allow for provenance/contexts in merged graphs.

Recently discovered: Lion Kimbro's OneBigSoup project (weblog, wiki). Lots of ideas here.

Goal, roughly: More interconnection between existing Internet-based social tools.

Pieces I'm finding interesting: LocalNames, UniversalLineInterface

I've been helping Lion with ULI tools (DICT protocol gateway, support for ULI over HTTP GET when appropriate), and talking about capability security principles.

Though I can't imagine any specific use for it yet, I wrote a ULI client on Waterpoint - $local.uli.

The current implementation of E is absurdly slow. It's an interpreter, mostly unoptimized, implemented in Java.

My project: E implemented in Common Lisp—translating E to CL code and implementing ELib with CLOS.

Many Common Lisp implementations compile source to machine code at runtime, and a sufficiently clever translation of E code should benefit from this.

Status: The Kernel-E to CL translator is mostly complete. I have a crude Updoc implementation in CL, which I use for testing the other parts. ELib is only as complete as I've needed to test the translator.

Micro-status: Trying to figure out why var x := 2; x := x returns 0 instead of 2, and yet sets the variable correctly for later code.

Tags:
  • Add Memory
  • Share This Entry

Accidental neat trick

Thursday, September 16th, 2004 08:58

In four easy steps!

  1. Decide to write a toy RDF-processing library in E.

  2. Mangle Improve the RDF data model: instead of having the three disjoint types URI, blank node, and literal, everything in a graph is like a blank node and has 0 or more names which may be URIs, literals, or any E object—which will, you imagine, be used mainly for representing datatyped literals.

  3. Decide to have the basic graph class not know about any types of names, and allow any object, with only conventions for URIs and literals.

  4. Realize that a trivial naive smusher can be written using this data model: for each triple whose predicate is an owl:InverseFunctionalProperty, add a name for the subject of the triple consisting of the predicate and object nodes, and any duplication must then result in the nodes being unified. This also preserves multiple URIs for the same subject without requiring duplicate triples.

Of course, I have no idea yet whether this model and library will be good for anything useful yet. (If nothing else, it will certainly be horribly slow.)

I should collect some use cases.

Tags:
  • Add Memory
  • Share This Entry