"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