[Help-smalltalk] [task] shared pool environment for compile-time evaluation

[Stephen Compall]

Issue status update for 
http://smalltalk.gnu.org/node/211
Post a follow up: 
http://smalltalk.gnu.org/project/comments/add/211

Project:      GNU Smalltalk
Version:      <none>
Component:    VM
Category:     tasks
Priority:     normal
Assigned to:  Unassigned
Reported by:  S11001001
Updated by:   S11001001
Status:       active

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


   *  class tag arguments (e.g. <import: SomeVar>)
   *  class var initializers (e.g. MyClassVar := SomeVar)
   *  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./