Jordan Brown

This build offers two *alternative* schemes for how objects and geometry values are treated. In the end only one will be used, but it implements both so that we can...

With respect to $self... that seems orthogonal. The same concern would apply in any nested scope.

Taking these one at a time... > Should this not work? > > ``` > o1 = { > size: 10, > pos:[-15,10,0], > shape: {{ translate(pos) > cube(size); >...

> The following o1 and o2 seem functionally exactly equivalent. The advantage of the second is that you have access to local variables. What is the advantage of the first?...

WRT $self as you present it... I think that's orthogonal. The example that you give is that you want to jump over more-local scopes to access a variable from a...

> ContextMemoryManager::~ContextMemoryManager(): Assertion `managedContexts.empty()' failed. Hmm. I'm not doubting you, but I don't immediately duplicate that failure. I took your example, both as a whole and isolating the m2 segment,...

To be clear, the two alternatives are - Having an associative-array type ("object", "dictionary", et cetera), expressed here as `{ ... }`, and a separate geometry type, expressed here as...

> The "geometry literal" has many similarities to a module_literal. Only in the sense that an expression is similar to a function. ``` 1 $fn = 3; 2 x =...

You injected the word "module", which means "a block of source that will be evaluated later", into an expression that is evaluated *now*, not *later*.

WRT the assertion failure: I haven't had time to look into it deeply, but I understand it at a high level: the context garbage collector is unhappy that it's shutting...