2012-07-09: runtime class creation saves my bacon

[nikodemus]

Foolang has syntactic sugar for records:

{ x: 1, y: 2 }

On the bootstrap host this used to de-sugar into:

Record x: 1 y: 2

There each record contained a dictionary under the hood, with catch-all #perform:with: methods creating the instance
with appropriate dictionary and accessing the correct elements.

Easy-peasy, but terribly inefficient, so I thought about it and wrote a better design, where each combination of record keys gets their own class for more compact storage and faster access. This meant losing the de-sugared ad-hoc constructor, but I thought that was fine. (In the design note I wrote "that can still be supported if necessary", and I remember thinking that the ad-hoc form could just use a dictionary under the hood like before.)

The new design got (partially, without full normalization) implemented in the transpiler a bit later.

However, turns out the transpiler was having it's cake and eating it: while the generated code represented records with distinct classes, when evaluating a define containing a record expression it would hand it to the AstInterpreter which would use the old de-sugared method of construction:

    method visitRecord: aRecord
        aRecord name
            sendTo: Record
            with: (aRecord values
                       collect: { |each| each visitBy: self }) asArray!

(That's calling the Record key1: ... key2: ... method based on the AstRecord node being visited.)

...so when transpiled transpiler ran into a define with containing a record it would try to do things the old way, which it had no support for.

Oops. 🔥 ⚡ 💣

I has mentally ready to roll up the "dictionary in a trenchcoat" solution for this, but feeling sad about it. If I needed to do this here, there would be legitimate code elsewhere that also wanted to do this, and having sad subpar records for those would not be nice.

Then I realized that I now had working metaobjects in the transpiler, and could construct fully functional classes, layouts, and methods at runtime.

A bit of code, and now the self-hosted Record class supports the same ad-hoc construction, creating new classes on the fly.

It's not quite as nice yet as I would like it, though:

• The classes are not cached, since there's nowhere to cache them in absence of mutable globals. I made a gesture towards allowing users to cache them by adding a Record classFor: <selector> method, but even the transpiler doesn't use it yet. This is a tricky problem with memoization in Foolang in general.
• I would like to generalize the reader methods so that code used here would be shared with regular readers. That would also cut down on generated code nicely.

Anyhow, this morning's effort: #713

[nikodemus]

(The design note still needs updating to current state of affairs...)