[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 Post a follow up:

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
   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./

reply via email to

[Prev in Thread] Current Thread [Next in Thread]