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

Agreed.

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

Well, sorry if I misunderstood you, my apologies.  It's just that with the
talk about not liking : for arguments, or not wanting a receiver, and not
wanting to quote strings and such, I was led to believe you didn't want an
embedded DSL, that you wanted to parse your own special syntax.

> 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 DSL's?) 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.

Ah!

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

That's the very definition of 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 read the code, do I see C, or do I see lot's of stuff related to the
problem domain.  If reading Lisp, do I see lot's of cons, car, cdr, map,
filter, or do I see something more domain specific.  Some people program
"in" the language, some people program "on" the language.  It's all just
programming, doing a DSL is just a style.

> >> When I spoke about DSL's, I was particularly talking about 
> reading in 
> >> and evaluating text files.

I would consider that an interpreter, and an external DSL, not an embedded
DSL, unless the text needed no preprocessing to evaluate.  If you have to
pre-process it first, it's an interpreter, and an external DSL.

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

Hmm, I think an interpreter evaluates strings on the fly, a DSL is just a
description of the possible syntax, and is orthogonal to evaluation.

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

Again, I don't see this at all related to being a DSL.  I could do this with
the syntax of any language that supported some kind of eval function.  Being
a DSL is about syntax, not about where the code comes from.

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

It seems your definition of DSL == my definition of interpreter, no wonder I
misunderstand you so much.

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

Unfortunately, I loaned my copy out and it seems to have disappeared. :(

> 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 DSL's 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-

No problem, happy to continue the discussion, I find it fascinating.