Info on Smalltalk DSLs or Metaprogramming...

Rich Warren rwmlist at gmail.com
Wed Aug 30 09:58:00 UTC 2006


On Aug 29, 2006, at 10:34 PM, goran at krampe.se wrote:

> But writing Smalltalk code in a file from within Squeak is  
> definitely an
> odd way of doing it, unless you have a specific goal doing that.


You're not writing Smalltalk code in an external file, you're writing  
DSL code (text that happens to be interpreted and parsed as Smalltalk  
code). It's a subtile difference, but I think an important one.

And you might not write any code at all. You could be passing  
messages as strings between remote agents. You could be automatically  
parsing Unix log files. You might be scanning a text document for  
tags which will be automatically replaced with computer-generated  
content (for example, putting actual source code into an article  
about computer programming at the last minute, so you don't have to  
worry about copying-pasting and keeping things in sync as you edit  
both files).


> Eh, "utilize Smalltalk syntax" (and not actually *use* the available
> Compiler) seems less useful.
> I mean, if you want Smalltalk syntax - why not use *Smalltalk* and not
> just the syntax?
> Use the Compiler that we already have and that is battle proven etc.


I'm not sure why I'm having so much trouble expressing myself on this.

Of course I'd use the compiler.

Compiler evaluate: 'some text from file'.

This is exactly what I'm talking about (and why people recommended  
using smalltalk syntax directly as opposed to creating my own syntax  
and building a parser).


>>
>> Here's an example of what I'm talking about. I'm about to implement a
>> neural net. I'll be experimenting with many different sizes and
>> topographies. This is an excellent opportunity for a DSL. I could
>> create several net-building scripts that are then loaded and
>> interpreted by the main application. Then, if someone wanted a
>> different topography, they could just write and load their own build
>> script. I could even build an object to automatically write out build
>> script permutations. The scripts themselves act as both source code
>> and log.
>
> And if *I* would do it I would just use Smalltalk. :) IMHO specific  
> DSLs
> tend to get outgrown. They look simple from the beginning, and then  
> you
> bang your head against the roof. And the effort to create them often
> (IMHO) does not pay off that much compared to "just use Smalltalk" (or
> Lisp etc).

That is certainly a valid option.

For something like this, planning a DSL can be a really helpful  
experiment. Even if I end up implementing it directly, I end up with  
a set of classes/methods that are cleaner and easier to use.

Also, who might use the DSL. If the end-users might want to modify  
the code, then it may be better as a DSL (unless the end-users are  
smalltalk programmers).

And DSLs can often serve dual purposes. A single source file might  
generate both code and documentation (or in my example, function as  
both executable code and as a log file).  You can gain a lot by  
having a single, authoritative copy of the important information  
(provided you back up that copy, of course).

But, if you're not going to get anything out of it, just implement it  
directly.

>
> In Gjallar we use Smalltalk as the "DSL" for defining the workflow  
> graph
> for example, it looks simple enough for most readers AND we can easily
> do special things when we need to. And no time spent writing a custom,
> half buggy parser. :)

Again, I'm not talking about making a full parser. Maybe some light  
preprocessing of the input (maybe), but you should use Smalltalk for  
the heavy lifting, where possible.

>
> Thing is - it is fun to make languages and I think DSLs often are
> created just because it is fun to do it. Or you simply don't have a
> language where the parser/compiler is so readily available. I mean:
>
> 	Compiler evaluate: '3+4'

I really think we're talking about the same thing, just using  
different words. '3+4' is too trivial to be a DSL, but this could work:

run: 'name' trainingSet: 'training file name' testSet: 'test file name'

And, with the right classes (and preprocessing) it could be parsed  
and interpreted directly as code.

e.g.: Compiler evaluate: 'myClass ', lineFromFile.

There's no half-buggy complier. Smalltalk does (almost) all the work.  
And yet, this is exactly the type of DSL I have been talking about.

I hope I'm starting to make more sense.

-Rich-




More information about the Squeak-dev mailing list