Thanks for quick reply, and good point about keeping math expressions
familiar to most users. In this first round I settled for a simple
prefix "function(parameter1 parameter2 ...)". All the python infix
operators like "a + b" have equivalent prefix functions "add(a b)" so the
latter are used.
Yes, infix "a + b" parsing would be easier to read, and I was thinking we
could try that on our next iteration (and remain backward compatible) but
more opinion may shift that up! (Some other issues to tackle too:
decisions about whether "/" should map to "div(a b)" or "truediv(a b)",
and how to avoid conflict with our namespace method of referring to
variables via a/b/c paths).
I'm definitely avoiding eval() since we do have to control exactly which
functions, conditionals, and loop constructs are executed. Not trying to
provide the all-out iPython approach.
On 2016-01-11, 12:03 PM, "Bob Harris" <rshar...@bx.psu.edu> wrote:
>On Jan 11, 2016, at 2:42 PM, Dooley, Damion wrote:
>> ... we're testing out a basic scripting language ... meant to provide
>> ways to [do something] without having to be programmers ...
>> if( lt(/N50 200000) set(report/job/status FAIL))
>> Math is accomplished by python built-in math functions ...
>It could well be that's the only way to accomplish what you want in
>whatever environment you're in. But the use of prefix notation and a
>funny name, for an operator like "<" that non-programmers use familiarly
>as infix, would seem contrary to the stated goal that the user needn't be
>If math can be accomplished via python, why not "<"? By "math" do you
>only mean function calls, and not arithmetic operators? Is it that
>python eval() can't be used because of security issues?
Please keep all replies on the list by using "reply all"
in your mail client. To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
To search Galaxy mailing lists use the unified search at: