Info on Smalltalk DSLs or Metaprogramming...

Rich Warren rwmlist at gmail.com
Thu Aug 17 09:36:33 UTC 2006


It may not be necessary (probably isn't). It may not even be wise.  
But I'm still curious--how far can I stretch the boundaries?

  The specific project I'm working on is an AI research project as  
part of my Ph.D. Ideally I would like to have a configuration text  
file that (with an easily-human-readable syntax) configures the  
system for each trial--one line per trial.

Why not just code it all in smalltalk? I want non-programmers to be  
able to look at the configuration file, and look at the data and  
easily understand  the initial conditions for a specific run and how  
it correlates with the resulting data. Having the configuration file  
as a separate artifact will greatly help--but only if I can make it  
easy to read (basically code that doesn't look like code).

I'd like to create a mini-language for the config file whose syntax  
basically consists of objects, selectors and operators. I'm still  
feeling out the infrastructure's requirements--and I'm trying to  
decide whether to implement everything in Smalltalk or Ruby. I have  
good examples for implementing a DSL in Ruby. I think I can port most  
of the ideas easily enough to Smalltalk, but some of the more  
complicated examples do make changes to classes at runtime (I'm not  
sure I'll need that--but I'm also not sure I won't).

So far,they're still running fairly neck-and-neck. In most ways,  
they're both excellent approaches. Here's my thoughts:

Ruby:

I know Ruby better.

All my DSL examples are in Ruby.

For DSL's, Ruby's syntax seems slightly more flexible than Smalltalk  
(or maybe I just know how to abuse it more).

 From my research so far, Ruby as better support for distributed  
objects (especially Rinda). This might be important if we need to  
move the code over to the cluster.

Ruby can more-easily create actual child processes, which might let  
me plow through the data faster on a dual-core machine (though, I  
believe this might lock it into only running on Unix boxes).

I have better Ruby reference books.

I have good instructions for creating charts/graphs directly in Ruby.

Smalltalk:

It would be a good excuse to get more proficient in Smalltalk.

I prefer working in the Smalltalk environments.

Creating a cross-platform GUI will be easier in Squeak.

While getting multiple processes is a pain (as far as I know, I'd  
need to run multiple instances of squeak), I can save and quit squeak  
while the application is running. When I launch squeak, it will start  
up again exactly where it left off. This may actually be the killer  
feature. I can run the experiments on my laptop overnight. Even if  
they don't finish by morning, I can shut things down and take the  
laptop with me to class--without losing any data.

I'm sure there are a lot of other cool reasons to pick Smalltalk that  
I just don't know about, because I'm still kind of low on the  
learning curve.

-Rich-

On Aug 16, 2006, at 10:26 PM, Michael Latta wrote:

> There is another approach available in Smalltalk that is not  
> available in
> many other languages.  The syntax of Smalltalk as is allows for a  
> pretty
> good DSL to be built out of simple classes and blocks with good  
> selector
> naming.  You really do not need to dynamically add code to the  
> system to get
> a DSL when the syntax for Smalltalk is so flexible and has good  
> readability.
> You can certainly do "modeling" and generate the code from some other
> representation.  But, then you lose all the value of the Smalltalk  
> tools.
> If the user wants to model orders just create an Order class and  
> let them go
> to town with Orderish methods and blocks.  Then they can use the best
> debugger on the planet (that actually works when you want to change  
> the
> source, etc).  You can even persist in-flight execution and many other
> things that other environments do not support, letting that DSL  
> support more
> than just in-memory execution.  Integrating database accesses and
> distributed communications is not a barrier.
>
> Michael
>
> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On Behalf Of  
> Rich
> Warren
> Sent: Wednesday, August 16, 2006 6:56 PM
> To: The general-purpose Squeak developers list
> Subject: Re: Info on Smalltalk DSLs or Metaprogramming...
>
> In my tests, I've noticed that Behavior>>compile: actually changes
> the image. Is there any way to make less-permanent changes (e.g. just
> changing a single instance)?
>
> -Rich-
>
>
> On Aug 14, 2006, at 6:55 AM, Wilkes Joiner wrote:
>
>> Here is a blog entry of mine about using the Refactoring Browsers  
>> code
>> to generate classes for me:
>>
>> http://wilkes.blogspot.com/2005/12/simple-code-generation-in-
>> smalltalk.html
>>
>> The Behavior>>compile: method will add a new method onto a class.
>>
>> For instance methods:
>> MyClass compile: 'someAttribute
>>    ^ someAttribute'
>>
>> For class methods:
>> MyClass class compile: 'aClassMethod
>>   "Do some stuff"'
>>
>>
>> On 8/14/06, Rich Warren <rwmlist at gmail.com> wrote:
>>> Hi,
>>>
>>> I've seen several online articles about writing Domain Specific
>>> Languages in Ruby. All the articles mention that the idea of DSLs
>>> comes largely from Lisp and Smalltalk. I've found descriptions on
>>> writing DSLs in Lisp--but I can't seem to find any good references
>>> for Smalltalk.
>>>
>>> Does anyone have any helpful pointers? If I'm going to follow the
>>> Ruby model, then I need to be able to execute arbitrary strings as
>>> code (which Compiler evaluate: and related functions seems to
>>> handle). I also need to be able to add new methods to classes/
>>> instances at runtime--which I haven't found.
>>>
>>> Any help would be greatly appreciated.
>>>
>>> -Rich-
>>>
>>>
>>
>
>
>




More information about the Squeak-dev mailing list