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 =>  
true

or

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.

-Rich-

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.
>
> -Rich-