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
|