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

The method #parserClass is implemented in 9 places, in a few different ways:

1. Compiler (class side) and MethodNode implement:

^ Parser

2. Behavior, CompiledMethod, TPureBehavior, and TraitBehavior implements:

^ compilerClass parserClass

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...

Dave

-=-=-=-=-=-=-=-=-=-=- http://blog.dloh.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090710/9551532c/attachment.htm