Issue status update for
http://smalltalk.gnu.org/node/211Post 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./
_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk
Locked
