archives

Seeking suggestions on how to unify the environment, free variables, and current activation record for closures

In my spare time I'm trying to craft a language, mainly out of curiosity. I'm leaning towards a simple OO-language similar to Python, i.e. highly dynamic. My main goals for the language is simplicity and orthogonality, a rather secondary goal is performance.

I'm looking at unifying the mechanisms for accessing a value within the scope of a closure. Consider the following (in some arbitrary syntax):

class Foo:
   m_x = 2

   function f(x):
      function g(y):
         return m_x + x + y;

It's clear that g is a closure needing access to 1) It's own scope, 2) f's scope and 3) the environment of the instance. The straightforward implementation (which I have seen used in actual production languages) would be to have both closure and function types that upon invocation take whatever combination of environment variables and activation records they need. This implies that the invocation of functions and closures is different as well, and you sort of end up with a big heap of switches and what-if-this-is-a-this-type-of-callable code in your vm. Additionally, the vm ends up with a lot of different load instructions (load-from-stack, load-from-free-vars-stack, load-from-this), which makes anything but a stack-based vm untenable.

The only thing I can come up with is to treat an object and activation records as tables and link them up. A request for a variable can then trickle up these links of tables until a match is found. However, this sounds painfully slow even for the language I was envisaging.

I'm sure this kind of problem has come up and someone language implements this a lot more cleanly. Does anyone have any thoughts on the matter?

kind regards,
Tomas

A relational language extension for Python

Inspired by 'The Third Manifesto', a book by Chris Date and Hugh Darwen, we're putting forward an implementation of a truly relational language using Python (Dee). We address two problems:

1. The impedance mismatch between programming languages and databases
2. The weakness and syntactic awkwardness of SQL

See www.quicksort.co.uk for details.

Better language tools

I have recently been going over merging code from various branches. One rather annoying thing I noticed was the diff and merge tools don't seem to understand enough about the language in order to produce good ideas on what's going on. For instance if I am merging an insert where the inserted code just happens to have the same header bit of a comment and ends with the same bit of the comment it wants to merge this new piece in-between the comment rather than viewing the comment as an entire block. The same happens elsewhere often.
So with that, my question is really if better merge tools are viewed as a necessary problem in dealing with languages or if the outcome is not considered worth the effort?

I realize this is not a question directly at PL (theory) in general so if the question is inappropriate for here please take care of it accordingly.