[Q] Compiler evaluate: question
Anthony Hannan
ajh18 at cornell.edu
Thu May 22 03:34:56 UTC 2003
"John W. Sarkela" <sarkela at sbcglobal.net> wrote:
> As for the specific case of the compiler, I believe I have heard our
> friends in Berne lament the direct reference to morphs in the Compiler
> and IIRC Diego has called for some kernel level Exception design.
> There should be a family of CompilerError exceptions, (as well as
> CollectionError, FileError, etc). The default handler for
> CompilerSyntaxError should be the one to open the syntax error morph
> In that event, more stylish and intentful code might read as,
> [Compiler evaluate: 'xlerb ; frobnozz ;;;']
> on: CompilerSyntaxError
> do: [<what you will in this particular context.>]
Agreed. Exceptions have been refactored this way in the Closure
Compiler (http://minnow.cc.gatech.edu/squeak/ClosureCompiler). There
are ParseError and SemanticError exceptions which the interactive
compiler handles. Example:
"Generate dumb syntax tree. Only syntax errors will be raised here"
[ parseTree _ SqueakParser parseDoIt: "or parseMethod:" sourceText
] on: SmaCCParserError do: [:ex |
self notify: ex description at: ex tag position].
"Analyze syntax tree, binding variables, etc. Sematic errors will be
raised here"
[ parseTree verifyIn: aClass
] on: SemanticError do: [:ex |
ex correctIn: self].
"Generate compiled method"
method _ parseTree generate: #(0).
"Place method is a method dictionary, or in the case of do-its, place
in a closure with the target receiver"
closure _ MethodClosure new
receiver: aClassInstance;
method: method.
"Execute closure (do-it)"
closure value.
Note, a MethodClosure is similar to a BlockClosure, the difference is
how they are created. A BlockClosure captures home context temps, while
a MethodClosure just captures a receiver.
Cheers,
Anthony
More information about the Squeak-dev
mailing list
|