Info on Smalltalk DSLs or Metaprogramming...

Ramon Leon ramon.leon at allresnet.com
Tue Sep 5 16:51:20 UTC 2006


> The original example I gave didn't use any setters--not in 
> the conventional sense. For example, body() could simply call 
> toString() on anything passed in, concatenating the string 
> from multiple arguments. It could then append "<body>" to the 
> front and "</body>"  
> to the end. Then it would append the whole string to the 
> current document.

I was talking about attributes to the tag, ie..

<body style="bla;" class="bla" borderwidth="0">

To be able to set attributes on tags, you need setters that return self and
you need functions that return tag objects

html(body(h1("Hello")).style("bla").class("Bla"))

html(body(h1("Hello")).style("bla"))

> On the other hand, interpreted DSL and non-interpreted code 
> is not a continuum. There is a clear line between the two 
> cases. Something is either designed to interpret external 
> strings, or it isn't. There's no ambiguity.
> Secondly, interpreted DSLs require different techniques than 
> bottom- up DSLs. As far as I know, C, C++ and Java cannot 
> natively evaluate arbitrary strings the way Ruby and 
> Smalltalk can. In those languages, you cannot even write code 
> to interpret external strings without building a parser of 
> some sort (thus creating an external DSL). Even in Smalltalk 
> and Ruby, evaluating strings requires (at minimum) an 
> additional method call. More importantly, you have to decide 
> what context you are evaluating the string in.
> 
> There are also other decisions that need to be made when 
> building an interpreting DS that don't have to be made (or 
> cannot be made) when simply building a bottom-up DSL. For 
> example, how do you handle EOL symbols? Most Ruby DSLs 
> interpret a line at a time, treating each line as a separate 
> command. On the other hand, you could interpret the whole 
> text as a chunk and treat EOLs just like any other white space.
> 
> As you can see, even if you're just repurposing the host 
> language, building an interpreting DSL  requires an 
> additional layer of tricks, tips and techniques that are not 
> required for bottom-up DSLs.
> 
> Finally, there's the underlying reason behind why you're 
> using the technique. Bottom-up DSLs are simply a tool for 
> developers.  
> Interpreting DSLS can also simplify the development task for 
> developers; however, they also give end-users tools to change 
> the application's behavior after it has been deployed. So, 
> interpreted DSLs can solve a much broader range of problems 
> than bottom-up DSLs.
> 
> All of this (unambiguous meaning, clearly different set of 
> techniques, and broader range of intentions) are reasons why 
> I prefer to limit the term DSL to interpreted DSLs. To my 
> mind, there seems to be obvious ambiguity between what is a 
> bottom-up DSL and what isn't (as exemplified by the "every 
> significantly complex..." quote).  
> Bottom-up DSLs don't require any specialized 
> techniques--you're simply creating useful methods, classes 
> and operators. And Bottom-up DSLS are simply another type of 
> source code--they don't add any additional value outside 
> development (here I'm including maintenance and 
> testing--basically everything that's done in-house).
> 
> Bottom line is, my definition would make DSLs more obviously 
> different from other, more mundane programming techniques.
> 
> -Rich-

I understand you reasoning, I appreciate the discussion, it's always good to
see how others think, I just don't agree on your redefinition of the word,
and will have to invoke Laynes Law.  

I don't see much further to discuss, you want to call a language a DSL.  We
disagree on fundamental definitions.  You want DSL to hinge on
interpretation or not, it's not a position I can agree with.  IMHO, you
should drop the DS, and just call what you're talking about a language.
Yes, likely a domain specific language, but I'm simply not going to agree on
making everything that's not interpreted "not" a DSL.  Then entire Lisp and
Smalltalk community have been calling their style of programming building
DSL's for far too long to suddenly change the definition and exclude them
because you feel it's too ambiguous.

I did enjoy the discussion, I just don't see where it can go from here.

- Ramon Leon







More information about the Squeak-dev mailing list