Marshaling objects

Posted: April 15th, 2011 | Author: Mars | Filed under: Progress | Comments Off

The first batch of marshaling objects are in the library now. They all live in the ffi module for now, but they will be useful in any situation where one might want to render values as bytes or retrieve values from bytes, so I may end up breaking them out into their own module. The current list is uint64, int64, uint32, int32, uint16, int16, uint8, int8, ascii, and utf8. A marshaling object is one that implements the to_bytes and from_bytes methods; these methods accept a value and return a sized sequence of bytes, and accept a byte buffer and return a value, respectively.

FFI implementation

Posted: April 11th, 2011 | Author: Mars | Filed under: Uncategorized | Comments Off

Now that the built in container types are finished, the next most important item on the to-do list appears to be a foreign-function interface: that is, a mechanism for calling functions from external libraries.

We can break this problem down into several pieces. We need:

  • IO function to load a function pointer, by name, from some library file
  • Mechanism to marshal Radian values into C types, and to create Radian objects from C values
  • Annotation scheme so we can describe the parameter and return value signature for some function pointer
  • IO function to invoke some annotated function pointer with some values to be used as parameters

It’s not clear what use a bare function pointer would be, so perhaps the annotation operation should occur at the same time as function-loading. Even still, the result cannot be an invokable, since we can’t know which external functions might have side-effects or thread interactions; the external function pointer must be a type of IO action.

As usual with a big, complex problem, I’m going to start by implementing the piece that seems simplest and most obvious. That looks like the marshaling scheme: I will develop a system of type-objects, which can produce a byte buffer from a Radian value, or can create a Radian value from a byte buffer. I will need to consider endianness, and provide some support for variable-length buffers. This system will probably also incorporate support for text encodings, since those can be seen as schemes for marshaling an abstract string of characters into some concrete byte representation.

List implementation (finally!) finished

Posted: April 9th, 2011 | Author: Mars | Filed under: Uncategorized | Comments Off

It turned out to be a much bigger project than I had expected, but that really just demonstrates why this list object is such an important part of the Radian language. The Radian list does everything you’d expect a list to do, in a language of this type, but it’s an immutable (or “persistent”) data structure, so it is memory efficient and plays nicely with multiple threads.

Immutability has another advantage: it’s a bad idea to return an array from an object method in REALbasic, or a list from a method in Python, because you must either make a copy of the array every time, or you give any caller the ability to modify your object’s internal data storage. With an immutable list, however, giving away a reference to a list is effectively the same as making a complete copy, without actually taking up any additional memory. You can safely return a list from a method – the caller can make any changes they like to their new copy of the list without altering your object’s internal data.

Python exception redesign proposal

Posted: April 7th, 2011 | Author: Mars | Filed under: Reference | Comments Off

PEP 3151 takes a look at the organization of exception classes in the Python library and suggests a new, more useful arrangement.

While Radian has an exception mechanism, I have thought very little about an organization of exception objects yet. Radian doesn’t really have a class hierarchy, so it’s not clear how I would replicate the Python approach, much less a system like Java. It seems like exception values ought to have a type identifier as well as some data chunk; perhaps I’ll define an “exception” object with those two fields, then use a set of well-known symbols for the type identifiers.

List object progress

Posted: April 5th, 2011 | Author: Mars | Filed under: Progress | 2 Comments »

Implementing the log-time finger tree algorithms has proven to be a substantial challenge. Examples are few, and most are written in Haskell, which I find largely unintelligible. After several false starts, however, I am making some progress. I’ve re-implemented the indexed element lookup, in a way that will survive splits and concatenations, and have roughed out the concatenate method. With that and a split function, I can easily build insert, remove, and assign.

The list object has been more of a slog than I expected; the finger tree is substantially more complex than the Andersson-tree used in the map object. It is still clearly the right approach, however, and I am pleased to have such a powerful tool built into the foundation of the language.