shared pool environment for compile-time evaluation

Issue status update for 
http://smalltalk.gn
u.org/node/211
Post a follow up: 
htt
p://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./




_______________________________________________
help-smalltalk mailing list
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk