Info on Smalltalk DSLs or Metaprogramming...
rwmlist at gmail.com
Fri Aug 18 11:34:47 UTC 2006
Of course, the best ideas always come after I hit the send button.
It dawned on me that I could always preprocess the incoming string on
either platform. A relatively trivial amount of code means I could
write the (now case insensitive) DSL as:
name: my name, id: 0, number of agents: 200, target function:
30sphere, maximum error: 1e-10, visualize
And have it converted into a simple format for either platform:
new_run :name => 'my name', :id => 0, :number_of_agents =>
200, :target_function => :30sphere , :error => 1e-10, :visualize =>
TrialRun new; name: 'my name'; id: 0; numberOfAgents: 200;
targetFunction: #30sphere; error: 1e-10; visualize: true
Then evaluate the string.
Of course, this is moving a big step towards the full parser/
interpreter approach. Well, maybe not that big a step, given the
limited scope of the DSL, but a step.
On Aug 18, 2006, at 12:35 AM, Rich Warren wrote:
> It looks like I'll need to set the following information:
> Run name, ID, number of agents, target function, max error,
> visualization on/off, verbose on/off
> In Ruby this could be done as follows (calls the new_run method and
> passes in a hash):
> new_run name => 'my name', id => 0, agent_count => 200, target =>
> 30sphere ,error => 1e-10, visualize => true
> Since we are passing a hash into the new_run method, these
> arguments can be in any order. They can also be omitted (the target
> object presumably sets a default for anything not present).
> The same thing in smalltalk would look like this (note, they can be
> in almost any order--'name:' is a constructor and must come first--
> the others can be in any order and can be dropped):
> TrialRun name: 'my name'; id: 0; agentCount: 200; target: 30sphere;
> error: 1e-10; visualize: true
> or, for a prettier option (but one that sacrifices flexibility)
> TrialRun name: 'my name' id: 0 agentCount: 200 target: 30sphere
> error: 1e-10 visualize: true verbose: false
> None of them are really as readable as I would like, but any would
> do. The last one is the most readable, but if the number of
> optional flags started to grow--it would quickly become a real pain.
More information about the Squeak-dev