Hi!

Rich Warren <rwmlist at gmail.com> wrote:
[SNIP]
> You could argue that, for Smalltalk, the idea of a DSL is a bit  
> strange, since it involves moving some of the code outside the image.  
> Especially in Squeak, since (as far as I know) you have to leave the  
> squeak environment to edit arbitrary text files.

No, you do not need to leave Squeak for that. Filelist and friends edits
files.
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.

> "The Ruby guy wanted a little more, he wanted a certain syntax."
> 
> I'm not entirely sure what this means. I think he means I wanted a  
> specific, non-smalltalk syntax. That's not really true. I'll probably  
> implement my DSL using a pure smalltalk syntax (or smalltalk with  
> minimal text processing). It's close enough for me. However, someone  
> did ask what my ideal syntax would be--and so the thread went off on  
> that tangent.
> 
> In general, yes. The advice to utilize Smalltalk syntax directly is  
> good. That is what I had planned to do from the start. Originally I  
> was trying to find examples of how others had used Smalltalk syntax  
> to do this sort of parsing. I was hoping to learn a few tricks and  
> tips by looking at other implementations.

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.

> "However, creating good languages is not easy, and few people can do  
> it. I think that is the limiting factor in DSLs."
> 
> This is definitely true if you're trying to create a Turing Complete  
> language for general programming. However, most DSLs are not Turing  
> Complete. They are small, focused, little things. They do one thing,  
> and they do it as simply and cleanly as possible. As a result, they  
> are not typically very hard to write.
> 
> 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).

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

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'

regards, Göran