[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Help-smalltalk] [task] shared pool environment for compile-time evaluat
From: |
Stephen Compall |
Subject: |
[Help-smalltalk] [task] shared pool environment for compile-time evaluation |
Date: |
Tue, 22 Apr 2008 20:44:31 -0700 |
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./
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Help-smalltalk] [task] shared pool environment for compile-time evaluation,
Stephen Compall <=