Info on Smalltalk DSLs or Metaprogramming...

stéphane ducasse ducasse at iam.unibe.ch
Sat Aug 19 10:51:26 UTC 2006


Rich I would suggest you to read the paper on aconcagua and unit  
published at OOPSLA and ESUG last year by hernan Wilkinson.
They should that extending in a clever way numbers they have a really  
natural way of expressing units and time.
For example, imagine that 1 st, April is a valid Smalltalk expression  
returning a date.

Then I think that you should pay attention about the assumption tthat  
you have regarding the syntax your readers can understand.
For example I'm skeptical that : is bad for argument. But you will  
tell us.

Stef


On 18 août 06, at 22:19, Rich Warren wrote:

>
> On Aug 18, 2006, at 6:28 AM, Ramon Leon wrote:
>
>>>
>>
>> Seems to me the difference between
>>
>> name: my name, id: 0, number of agents: 200, target function:  
>> 30sphere,
>> maximum error: 1e-10, visualize
>>
>> And this
>>
>> TrialRun name: 'my name'; id: 0; numberOfAgents: 200; targetFunction:
>> #30sphere; error: 1e-10; visualize: true
>>
>> Are so trivial, why bother with the parsing step at all, just use  
>> direct
>> Smalltalk syntax, if kids can learn Smalltalk, so can users of a  
>> DSL.  As
>> far as samples of DSL's go, I use one daily in the Seaside  
>> framework for
>> generating html http://www.seaside.st/Documentation/ 
>> GeneratingHTML/, and
>> another http://scriptaculous.seasidehosting.st/, for generating  
>> JavaScript.
>> Both I think are good examples of embedded DSL's in Smalltalk in  
>> daily use.
>>
>>
>
> First, thank you so much for the samples. I'll look at them as soon  
> as I have time.
>
> As far as justifying the parsing step, my main motivation is to  
> have a config file that non-programmers can easily read. I don't  
> want them to have to learn anything (or as little as possible). I  
> would like it to be simple to write or change by hand too--so they  
> can script their own series of trials--but that's a secondary  
> consideration. For the actual trial runs, I'll undoubtedly create a  
> large config file automatically, in order to ensure a thorough  
> coverage of the possible permutations.
>
> But non-programmer readability is the reason I'd love to have multi- 
> word selectors (instead of things_like_this or thingsLikeThis), and  
> the reason I'd like to avoid strange punctuation (like => or the  
> Smalltalk semicolons, or syntax to indicate that something is a  
> string or symbol). And, finally, I'd like to get rid of any  
> unnecessary words (new_run and TrialRun new)--unless I have  
> different types of runs, it's just uninformative boilerplate.
>
> Also, the parsed version could easily be case insensitive, allowing  
> me to switch to something like this (if I thought it added clarity):
>
> NAME: my name, ID: 0, NUMBER OF AGENTS: 200, TARGET FUNCTION:  
> 30Sphere, MAXIMUM ERROR: 1e-10, visualize
>
> Or if I was just varying one parameter, and wanted to highlight it,  
> I could use all caps for just that selector.
>
> But it's only worth it if it's simple to implement. Case  
> insensitivity is trivial. As is stripping off leading (or trailing)  
> boilerplate. Replacing 'number of agents' with 'numberOfAgents' is  
> also trivial, as is switching from commas to semicolons.
>
> The only slightly tricky part is automatically adding quotes to  
> strings and # to symbols--so I may just leave that out.
>
> -Rich-
>




More information about the Squeak-dev mailing list