Info on Smalltalk DSLs or Metaprogramming...

Ramon Leon ramon.leon at allresnet.com
Fri Sep 1 16:16:16 UTC 2006


> Does the embedded/external distinction just capture the 
> no-parser/ parser division? Or is embedded DSL intended to 
> mean something more like Paul Graham's Bottom-up programming 
> (http://www.paulgraham.com/ progbot.html)? I had always 
> assumed it was the no-parser/parser split. But the 
> description is ambiguous. If this technique must be given a 
> name, I prefer the name bottom-up programming.

I consider bottom up programming, and embedded DSL's the same thing.

> >> 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.
> 
> I don't like that definition. In my mind, simply moving a 
> language closer to the problem domain is just basic software 
> engineering (maybe that says a lot about my views on software 
> engineering--and probably explains why I like 
> Lisp/Ruby/Smalltalk so much).

It's not just basic software engineering, because most languages can't be
moved closer to the problem domain.  It's likely you like
Lisp/Ruby/Smalltalk exactly because they can be, but that's why they're
special.  They can be used to build DSL's.  

When I program in Csharp, VB, or Java, I find myself writing a lot of loops,
many of them looking very similar, because these languages offer me no clean
way to stop writing the same loops over and over.  Yet in Lisp, Smalltalk,
or Ruby, you do something a few times, get tired of doing it, extend the
language with a new operator, and program with it.  

If I add a bunch of stuff that makes the language really good at generating
html, say a macro...

(html (:html
    (:head (:title "My Document"))
    (:body (:h1 "My Document")
        (:prin1 (get-universal-time)))))

Or abuse blocks for the same purpose...

SomeObject>>renderContentOn: html
    html 
        head: [html title:'My Document'];
        body: [html heading: 'My Document'; 
                    text: DateAndTime now]

It is most certainly a DSL.  It may also still be valid Lisp or Smalltalk,
and still capable of being used as general programming language, but it's
not being used that way.  I can't do this in most languages.  Most languages
allow you to build libraries and api's, but not DSL's.  I consider them
embedded DSL's because they are still syntactically valid in their native
languages and require no additional parsing.

> Moving closer to the domain is necessary for a DSL, but it 
> isn't sufficient.
> 
> Having thought about it more, here's the crux of the issue 
> for me. To be a DSL it must be (first and foremost) a 
> language in its own right.  
> You must be able to distinguish it from the host GPL (general 
> programming language). The DSL may not have a name, but it 
> must be nameable. You must be able to point to a chunk of 
> code and say, "This is written in BlahBlah".

Agreed, and even with embedded DSL's, you can generally do that. 

> Let's say programming fundamentalists capture me and force me 
> to write applications in C. To survive such harsh conditions, 
> I write an excellent library, RichBrillanceDSL. Now, I write 
> the rest of the application using this library. To me, this 
> doesn't count as a DSL.  
> I'm not writing in RichBrillianceDSL, I'm still writing in C 
> using RichBrillianceDSL.

Because it'll still look like C, a library by definition is not a DSL, you
aren't extending C.  However, if you did it with compiler macro's, I'd say
it was a DSL.

> On the other hand, if I'm making a Rails web page, and I 
> write an RJS template, RJS is a domain specific language. It 
> is clearly separate from the Ruby code used in the 
> application's controller. The file has its own extension and 
> everything.

That makes little difference from my point of view, files are orthogonal to
the issue.  But, you point being that the DSL is somehow separate from the
main use of the language, ok, I get that, and in Smalltalk when using a DSL,
they are generally also in separate methods from ordinary Smalltalk code.
So there's a place to point and say "hey, that's written in So and So".

> To really pick at semantic nits, you shouldn't call bottom-up 
> programming a DSL.  Even though it's been highly tuned for a 
> given domain, it is still (by definition) a general purpose 
> language. The language is still Turing complete, and you can 
> still use it to solve any general problem (or at least any 
> problem solvable with a GPL).

I disagree, as would most Lispers and Smalltalkers I imagine.  Bottom up
programming, where you enhance the language, I think has always been
considered a DSL by those respective communities.

> Of course, I think banishing all Turing-complete languages 
> from the ranks of DSLs is a bit of an over-reaction (after 
> all, it may be possible to misuse an embedded DSL to execute 
> arbitrary code--even if that wasn't the original intention), 
> but I do think DSLs need the general sense of limited 
> usefulness. A DSL should be highly focused.  
> It should only be good at one thing.

I think how a DSL "is" used, says more about it than how it "could" be used.
Sure, embedded DSL's are still fully capable of doing everything the host
language does, but I don't think that disqualifies them when they aren't
used that way.

> The Pragmatic Programmer book has an interesting example:
> 
> They recommend creating a mini-language for the sole purpose 
> of communicating with the client. Originally, this language 
> will not be executable. It is just a simple way for the 
> client to express their requirements.
> 
> However, once the specifications are in place, you could go 
> the next step and turn the specifications into executable code.
> 
> That's very different from the bottom-up approach.
> 
> -Rich-

As Fowler pointed out, they come from a Unix tradition of "little
languages", they're mostly doing external DSL's, not internal or embedded
DSL's.  It's a different style, but not the only one.





More information about the Squeak-dev mailing list