On Jun 12, 2007, at 6:00 PM, Ethan Mallove wrote:
We'll need to revamp all the current funclets to accept
arrays and return [potentially] arrays of arrays. What
if, as a counterproposal, we have a &perl() funclet?
Then you could do the following:
btls = &perl("if ($hostname =~ /foo/) { \
return ("self,sm,tcp"); \
} elsif ($hostname =~ /bar/) { \
return ("udapl"); \
} else { \
return ("sm", "tcp", "sm,tcp", "udapl", "sm,udapl"); \
}")
I like that. Is that in anticipation of having &ksh(),
&zsh(), &python(), &php(), &tcl(), ... ?
Well, I wasn't really thinking of adding all those other
languages... :-)
To reduce some
clutter, maybe a param like this would be fun, e.g.,
default_ini_evaluator = perl
So MTT will assume you mean &perl() if there's
no leading '&'.
Hrm. How would you reconcile this with today's evaluation? E.g.:
foo = bar
This is not legal perl, and would cause an error if we subject that
to an internal perl eval. This is why I was suggesting a &perl()
funclet -- we would know that the entire contents were perl and safe
to submit to eval.
--
Jeff Squyres
Cisco Systems
