On Aug 30, 2006, at 7:39 AM, Ramon Leon wrote:

>> Part of the problem is different people seem to have
>> different interpretations of what a DSL is. In some
>> definitions, any significantly complicated project becomes a
>> DSL (or at least any well- written project).
>
> This is the definition I think most of us have.  We should be more  
> explicit
> and call them embedded DSL.

As I understand it, the term embedded DSL already refers to DSLs that  
are created by bending the syntax of an existing language--basically  
making a new language from building blocks of an old language. The  
other sort (external DSL) is where you use yaCC or smaCC or something  
similar to build actual parsers/compilers.

Based on these definitions, I have always been talking about creating  
an embedded DSL. Yes, people keep recommending that I create an  
embedded DSL. Yes, this is good advice. Yes, this is what I plan on  
doing. For some reason, I keep getting replies that suggest that I'm  
resisting this advice, and that I'm bounding off to create a full  
parser. I'm a little bit confused by this.

Originally I had asked if anyone had samples or tutorials on creating  
embedded DSLs using Smalltalk. I've built them in Ruby and Lisp.  
Especially in Ruby, there are some useful tricks in manipulating  
(some might say abusing) the language to provide a desired syntax for  
your DSL. I was hoping to pick up similar tricks for Smalltalk.

I think the discussion got off track because people asked me a few  
questions (What would your ideal syntax be? Why do you think ruby  
syntax might be better for DSLs?) and I tried to answer them. I  
probably should have changed the subject line or something. So, when  
answering a question, I might have said,  "I'd like to be able to do  
something like XYZ", but that didn't mean I wanted to go out and  
actually implement XYZ. I was simply answering a hypothetical question.

I'm still interested in an embedded DSL.

However, I'm not convinced that simply altering an existing language  
so it is closer to the domain should count as a DSL. Some people  
count it--but to me it seems like that's just programming. C's  
functions, OOPs objects and Lisp's macros all serve the same basic  
function--they allow you to define additions to the language to more- 
closely model your domain. Where do we draw the line between  
programming and DSLs?

>
>> When I spoke about DSLs, I was particularly talking about
>> reading in and evaluating text files.
>
> I don't think that is a good definition of a DSL.  Files are  
> orthogonal to
> the issue of DSL or not DSL.

I don't think I meant for this to become a universal definition of  
DSLs. Rather, I think I was trying to explain what I had meant by DSL  
in my earlier posts.

Still, to return to my previous question, where do we draw the line?  
For me (and this is strictly a personal definition, don't feel  
obligated to adopt it), a DSL must be able to interpret code that was  
not part of the original application (support files that ship with  
the application, like configuration files, are OK). I'm talking about  
raw strings that have not been previously compiled. A DSL evaluates  
these strings on the fly.

The code in question could come from a file, could be entered  
interactively at the command line, or could be sent across the  
network. It really doesn't matter where it comes from. The important  
thing is,  in some way the code is external to the executable.

Why do I like this definition? For me, there are very practical  
reasons. Creating a system to evaluate external strings is more  
complicated than simply writing an object or macro. There are the  
obvious IO issues. More importantly, you need to decide whether  
you're looking at each line as a separate command, or whether you're  
dealing with the entire string as a single chunk. Strings can be  
interpreted as new objects and method calls, as method calls on a  
given object inside your code, or as numerous other possible variations.

Also, this definition seems to match closely with the discussion on  
"Domain Languages" in the Pragmatic Programmer book--which has been  
my initial source for all things DSL.

> You seemed hell bent on using a syntax that
> wasn't valid Smalltalk, and I understood you pretty much as Ralph  
> did, and
> wondered, why?  Yes, this is building a DSL, but it's building a  
> custom DSL
> that requires parsing.

I don't think I'm hell-bent on anything. I'm sorry if I gave you that  
impression.

I also don't think I ever suggested anything that would required a  
parser (except possibly as an answer to a "what would your ideal  
syntax be?" style question). Some of my suggestions did use trivial  
pre-processing of the text. But, no. I don't want to mess with  
parsers at this stage--probably never for this project.

> While a valid approach, it's certainly not the
> easiest or most practical solution, which is all the Smalltalkers were
> getting at.  Even if you did want to build a custom DSL, the practical
> approach would be to prototype it as an embedded DSL first, get it  
> working,
> and then decide after that, if a custom syntax would be useful.   
> Just my
> $.02

I agree with this. I've agreed with it every time it has come up  
(though I may not have commented on it directly--human nature, I  
guess. I tend to comment on things I disagree with). Still, this has  
been, is and will continue to be my plan.

Sorry to repeat myself, but I feel like I've tried to say this  
before--somehow the idea keeps getting lost under the cushions.  
Again, I think this is largely my fault--I should have separated the  
tangential conversations (e.g. the differences between Ruby and  
Smalltalk syntax as applied to DSLs in general) from the main point  
(what are the best practices for developing an embedded DSL to  
process externally provided strings in Smalltalk?).

I'll try to be clearer in the future.

-Rich-