Oleg Andreev: Archive

Oct 5, 2008

Source code is an object too

What is the shortest example code which shows great flaw in Ruby comparing to Java, for example? It is a literal “string”. That’s it. Every time interpreter hits the literal string, it creates a brand new object. The only useful thing is that it is already mutable, so you don’t have to copy it in rare cases when you want to modify it. But in reality you end up with such kind of code:
# Yeah, these constants look kind of tacky. Inside of tight loops, # though, using them makes a small but measurable difference, and those # small differences add up.... C_asterisk = '*'.freeze C_empty = ''.freeze C_header_close = 'HTTP/1.1 200 OK\r\nConnection: close\r\n'.freeze C_header_keepalive = 'HTTP/1.1 200 OK\r\n'.freeze C_slash = '/'.freeze C_slashindex_html = '/index.html'.freeze C1_0 = '1.0'.freeze C1_1 = '1.1'.freeze C_304 = "HTTP/1.1 304 Not Modified\r\n".freeze Caos = 'application/octet-stream'.freeze Cat = 'at'.freeze Ccache_directory = 'cache_directory'.freeze Ccache_extensions = 'cache_extensions'.freeze ...

The first thing “Better Language” should implement is source code being a first-class object with all the literals instantiated as immutable objects and referenced by this object. This helps to resolve a lot of issues with floats, strings and regexps.

However, the interesting things remain:
1. Complex literals should be recognized: like JSON (Arrays and Hashes) full of other literals should also be an immutable object attached to the source code object.
2. Literals which include variable references should turn into new objects creation on each method call, but only in a case when the variables are not already immutably binded to some values. This brings us to a whole world of functional programming from Lisp to Haskell.

Oct 5, 2008

Selector namespaces

Object-oriented design lets us avoid a bunch of “if-elsif-else” lines of code and use polymorphism instead. Sometimes it is extremely helpful to be able add or replace methods in core classes like strings, numbers and arrays. Ruby has such ability, but sometimes it turns out to be a nightmare. One library may redefine some String method for its own purpose and completely fuck up things in another library. In reality, library needs to redefine String class in that library’s namespace only. Let’s examine the possible ways to achive this:

1. In a pure OO-language only thing we have is message sends. When we write “string.size” we pass a message “size” to an object referenced by the local variable “string”.
Suppose, we have a library doing some low-level byte manipulations which relies on byte count behind “size” method. On the other hand, our application would like to deal with character count (one Cyrillic character is encoded with 2 bytes in UTF-8).
We want to keep the string in a same class (“String”) and also use the very same selector “size” for the different methods. So, how do we determine which method to choose, when class String receives the message “size”? The solution is to keep a thread-local stack of namespaces which is updated on each method call and ask it for a correct version of the “size” method. Maintaining such stack is not that hard, but method call becomes more complicated and slow: late binding overhead sums up with the namespace selection. Finally we have two virtual tables: for the eigenclass and for the namespaced extensions to that class.

2. In a statically typed language we know the type of the object from the lexical context. Thus, it is extremely easy to bind the correct version of the method according to that type using pattern-matching mechanisms, for example (see Haskell).

3. In case of polymorphic types, we have to curry type information with the objects and determine methods based on the lexical scope. However, we may reduce overhead if we use polymorphic virtual machine: such machine which injects itself into a compiled piece of code with its namespace in mind. In such case, message send is executed differently depending on the lexical scope of the code, where the send is performed. This allows us to avoid virtual table scans. But we have to waste memory keeping namespace-specific pieces of executable code.

Oct 5, 2008

Better programming language

I use Ruby everyday. I like C and Java for performance, but dislike their lack of expressiveness and build/configuration issues. I like Io’s garbage collector, coroutines and local state, but dislike its awful performance which cannot be optimized by design.
I generally hate Perl, but the idea of extensible grammar is interesting (remember E4X: why not to have an API to the parser to embed other grammars?).

In Ruby i’d like to extend core classes, but i don’t like to pollute other libraries with my helper methods. Thus, i need to narrow scope of some selectors to the lexical context.

I want pthreads, but with no implicit resource sharing: every thread must see only those resources, which are exposed for it explicitly. Communication between threads must be done through the efficient queues/pipes.

I want to compile arbitrary part of source code in runtime with arbitrary explicitly defined context. I want to have both portable bytecode and machine-dependent code and both serializable. Source code and runtime state must be serializable too.

At the core of the language, I want to have an extensible parser/interpreter, FFI and a compiler API.
The language should suit well for object-oriented programming, but should not be purely object-oriented.

Oct 5, 2008

Github > Rubyforge

I have removed EMRPC project from Rubyforge because it is not fun to work with their fucked up API. Github is much nicer (just update a gemspec and wait for 10 minutes). Add github to your gem sources list (if you haven’t done it already):

$ gem sources -a http://gems.github.com

Remember, that github names gems in form of “username-projectname”, not just a “projectname” as rubyforge does. To install EMRPC:

$ sudo gem install oleganza-emrpc

Oct 3, 2008

Oleg Andreev

October 2008

October 1986