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
>>[folks] with
>> 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
>a programmer.
>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?
>Bob H

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:

Reply via email to