Compiler related PlusTools and ToolBuilder Questions

stéphane ducasse ducasse at iam.unibe.ch
Sat Nov 5 17:35:58 UTC 2005


>>>
>>> This needs to be fixed at some point but I believe it's  
>>> important  that all the other changes are applied *first*.  
>>> Perhaps this should  be delayed to a later update/configuration.
>>>
>> I do not get what you want to say exactly.
>> Normally all the changes that you packaged have been conflict  
>> checked  by cees and me, and integrated.
>> So should I interpret that my fixes are ok and putting back the  
>> two  methods described above is ok?
>>
>
> It's okay but *only* for the purpose of making MC happy to load the  
> latest version of the compiler if that was a problem. It is *not*  
> okay for Parser and Compiler to refer to SyntaxError because syntax  
> error is part of the Tools and Parser/Compiler should not directly  
> depend on the tools.

Ok of course. I was missing the context. Sorry. So this will have to  
be fixed.
May be the exception related to the compilation should be part of the  
compiler.
I know that SyntaxError inherits from StringHolder :( (so if it would  
be regular exception this would be much simpler and
it should be moved to the compiler package).


>>> Yes. Because compilation needs to pass along the category as  
>>> well,  so it has been replaced by   
>>> #compile:classified:notifying:trailer:ifFail: which has the   
>>> category as an extra argument.
>>>
>> Ok I did not included in the fix since it seemed to me not  
>> critical  but now I scratch the issues from my head.
>>
>
> It *is* critical. This whole set of changes removes the dependency  
> between Parser, Compiler, and SyntaxError. Before these changes,  
> the class category of the compiled method was only stored in  
> SyntaxError, therefore Parser/Compiler could not do proper error  
> handling in the absence of SyntaxError (since they would not know  
> what the category is). Having the category in Parser/Compiler fixes  
> these issues, but that's why the category must be passed along when  
> compiling a method.

yes
I meant critical to know why basicCompile...disappeared since it was  
not the source of problem.





More information about the Squeak-dev mailing list