[squeak-dev] What I learned today.... Parser & Compiler madness..

> Squeakers,
> Today I learned with Ken Causey's help how to create a SHWorkspace for
> testing out a custom Parser.  And I have to say, the way in which a typical
> workspace derives which Parser and Compiler class that it uses is rather
> confused :)
> Typically the ParagraphEditor evalutateSelection method determines which
> parser to use by sending  'class evaluatorClass' to nil.  This method is
> defined in the Behavior class, and simply returns ^ Compiler.  The parser is
> then determined by sending #parserClass to Compiler, which returns ^ Parser.
>   Parser also has a class side method #evaluatorClass which returns ^
> Compiler, which is used to instantiate the actual compiler it seems.
> To patch your own workspace, it is necessary to subclass whatever workspace
> you're using and add an instance side method #doItReceiver which returns an
> instance of whatever parser you want to use: ^ new MyParser.  This class has
> to reference your own compiler class say MyCompiler in its #evalutorClass
> method, which then must have a #parserClass classide method that refers back
> to MyParser.
> After all of that you can open up your new workspace running your own
> MyParser and MyCompiler, and program in something not totally dissimilar to
> Smalltalk.
> Now #evaluatorClass is implemented in 3 places: Behavior, TPureBehavior, and
> TraitBehavior.  And all three have the exact same definition:
> ^ Compiler

> 3. Compiler instance side:
> ^parser ifNil: [self class parserClass] ifNotNil: [parser class]
> 4. UndefinedObject and PseudoClass implement
> ^ Compiler parserClass
> As you can
> see, most of the time, it does the right thing, except there are instances where you may actually get the wrong information (such as which parser generated a MethodNode), and there are times when you swap out compilers that don't result in the correct behavior. For example Text>>makeSelectorBold explicitly calls Compiler parserClass which necessarily invokes Parser, not necessarily the parser you're using.
> Unmuddying these waters is something I'd love to help out with, but I've
> found poking around in this region is much like performing open heart
> surgery on yourself.  Sure to kill your image :)
> Can anyone shed any light on why the current state of affairs is as it is?
>  It seems like there have been several attempts to make the underpinnings
> more flexible, allow for "user space" parsers and compilers, but ultimately,
> it just feels like a sargasso sea, plagued by dragons...