From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2007-06-14 06:52:10
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