[Help-smalltalk] Re: STCompiler ignores current namespace change for var lookup in evals

[Stephen Compall]

Stephen Compall wrote:
> Using STCompiler>>#evaluate:parser: in the valueWithUnwind'd block would 
> also subtly change STFileInParser>>#evaluate:'s meaning -- because 
> compiler errors wouldn't cause exceptions that could escape the 
> evaluate: context.

Here's a STCompiler class>>#compile:asMethodOf:classified:parser: (needs 
also my previous change to compile:for:classified:parser:) that lets me 
load the previously mentioned 'innamespace.st':

compile: methodNode asMethodOf: aBehavior classified: aString parser: 
aParser
    | compiler | 

    compiler := self new. 

    compiler class: aBehavior parser: aParser. 



    "Usually, when making UndefinedObject methods, you want the 

    current namespace to be specially added" 

    aBehavior == UndefinedObject 

        ifTrue: [compiler addPool: Namespace current]. 



    ^(compiler visitNode: methodNode) 

        methodCategory: aString; 

        yourself

This version has the advantage of being inconsistent with desired 
practice (when compiling methods truly intended for installation within 
UndefinedObject), but more consistent than the failure I reported to 
start this thread.

However, I am not sure that I wouldn't prefer the semantic change of 
putting compilation in the valueWithUnwind (using STCompiler 
class>>#evaluate:parser:) or removing it entirely.

Why shouldn't an exception during evaluation by the FileInParser (which 
only happens in RBParser>>#parseDoits AFAICS) halt parsing/loading of a 
stream without further intervention/resetting by clients of the 
FileInParser?

--
Stephen Compall
http://scompall.nocandysw.com/blog
##smalltalk,#gnu-smalltalk on Freenode IRC