shared pool environment for compile-time evaluation

Tagged:
Project:GNU Smalltalk
Component:STInST
Category:task
Priority:normal
Assigned:Unassigned
Status:active
Description

There are several places you can put expressions that are evaluated during compilation:

  1. class tag arguments (e.g. <import: SomeVar>)
  2. class var initializers (e.g. MyClassVar := SomeVar)
  3. compile-time evals in methods, and in any of the above (e.g. ##(SomeVar) or MyClassVar := ##(SomeVar)

In the VM, all of these are currently managed as compilations on UndefinedObject, with the addition to the pool search of the current namespace (which is twiddled by moving UndefinedObject). This is all very well and recursive, where

GSTParser reads MyClassVar := ##(SomeVar)
  asks new compiler to compile ##(SomeVar)
    asks new compiler to compile SomeVar
      answers method that answers SomeVar in UndefinedObject+Namespace current
    executes method
    inserts the result into a method's literals
  executes do-nothing method
finally gets SomeVar

The builtin compiler uses the same strategy for all of these, because that is what _gst_execute_statements does.

STInST would use the current class instead for #1 and #2, were #evalFor: ever sent to the driver. #3 handling is in the compiler, which doesn't have access to the driver anyway. In summary, STInST does the same as the VM compiler.

Should all these change? If so, which should change?

Note: Paolo brought this issue up when working on PoolResolution; I merely write it up here.

Updates

#1 submitted by Paolo Bonzini on Wed, 03/09/2011 - 11:40
Component:VM» STInST

VM compiler fixed (will push soon), changing component.

User login