>> for example, it would be really cool if I could just use the pattern  
>> to match as the name of the method in a normal method browser, and  
>> have the class's dispatcher then do the string matching when it tries  
>> to look up the method.
>Can you give a usage case? just to make it more concrete.

Sure.  The idea was to create something like the AWK mini-language  
in Squeak (call it Sqawk).

>I'm wondering maybe alot of what you want can be done by creating a
>matchOf: that's similar to caseOf:. Rough implementation attached.

It sure can be done that way.  As a matter of fact, the assumption  
behind this idea is that the functionality already exists somewhere  
within Squeak, for example in code such as the one you provided.  For  
this simple case, the functionality comprises a couple of methods.   
For complex cases, typically an entire framework.  The idea is that  
instead of accessing the framework from a general purpose language  
such as Squeak, which is too much to expect of the intended audience,  
you create a domain specific language tailored to that individual  
use, bringing the barrier low enough to match motivation levels for a  
practical solution.

If you look at the research for domain-engineering, you will find  
that frameworks and domain-specific languages are actually very  
closely related artifacts.  The difference is that a DSL usually is  
more effort to build, much easier for novices/non-programmer users  
but more difficult to adapt to new situations.  A framework is easier  
(but not easy), essentially impossible for novices to use, and at  
least somewhat more tailorable to new situations (such as combining  
with another framework).

To illustrate these points, compare using a RegEx package for  
log-file analysis vs. using AWK.  In Awk, you can essentially put  
your requirements straight into code, all the detail is already taken  
care of and packaged very nicely.  Compare that to getting a file  
(or stream), breaking it into lines, setting up the proper patterns,  
matching against them etc. in a general purpose language.  On the  
other hand, AWK is closed, so if you want to maybe plot some of the  
data from your analysis, you must write out ASCII files and process  
them somewhere else.

The really neat idea that Mark touched upon, and which has been on  
my mind ever since I studied that particular problem for my  
"Diplomarbeit", is to use meta-level techniques to easily create new  
DSLs capturing the functionality from a domain-specific framework,  
but also sharing a common base.  There are several reasons why I  
think this is a great idea.

The first is that creating the DSLs gets a whole lot cheaper,  
because you can reuse most/all of the base language.  Just look at  
how easy Squawk can be:  a DNU handler, a compiler subclass that can  
handle the pattern-specification as method header and a class to tie  
it all together with the file/stream handling and auto-iteration.   
All the rest can just remain as it is:  Squeak for method bodies, the  
code-browser, debugger etc.  An essential part of this is that the  
base language must be fairly easy, Squeak fills this requirement  
handily.

Related to the first one is that your DSLs can be much better,  
because instead of creating something ad-hoc under time/budget  
constraints, you use something that's already been pretty well  
refined.

Third, knowledge transfers easily between the DSL and the general  
purpose language, because they are just versions of each other.  If  
you know Squeak, Squawk poses no challenge.  If you just learned  
Squawk, expanding to Squeak also should be a much smoother path.

Furthermore, since the DSL is really just the general purpose  
language, hooking up functionality from other frameworks is also not  
a problem.  A more interesting problem is wether other DSLs can be  
accessed easily, my first guess is no, but it would be interesting if  
it were possible to make it happen given some effort, and a clean  
enough meta-level architecture (just ad-hoc extension probably won't  
do).

Also, note that this idea is different from that of an extensible  
general purpose language!  General purpose code such as frameoworks  
should always remain in the general purpose language, even though  
that language should probably also grow (or rather shrink...) using  
the meta-level facilities.  The DSLs are only, or at least primarily,  
for user-level programming.

Finally, since the DSL is really implemented in itself (being just a  
version of the general purpose language with its meta-level  
facilities) it can easily be extended using those same facilities.

Marcel