Re: Operator vs. Command precedence
Re: Operator vs. Command precedence
- Subject: Re: Operator vs. Command precedence
- From: "Mark J. Reed" <email@hidden>
- Date: Fri, 5 Jun 2009 00:47:18 -0400
On Fri, Jun 5, 2009 at 12:29 AM, Chris Page<email@hidden> wrote:
> Yes, Perl does have some magical properties. I am not a fan of magic in
> programming languages. ;-)
I'm a fan of contained magic. In the case of Perl, the result of the
magic is that it generally does what a naive user expects it to do.
The more sophisticated user may have to do some digging and head
scratching to figure out exactly *why* it does what a naive user
expects it to do. :)
> In this case, as I mentioned, “floor” is not a unary operator, so it
> wouldn’t be covered by this rule if we added it to AppleScript.
Well, the rule uses Perl's definition of "operator", as I said. Floor
as implemented in Satimage is necessarily an operator in the Perl
sense because its arguments don't go in parentheses...
> The issue remains that there is no means to indicate that a command is meant to be
> treated with some operator precedence, and there are probably reasons (other
> than backwards compatibility) not to assume that any one-parameter command
> is to be treated as such.
Sure. As I said, I wasn't proposing that AppleScript behave like
Perl. I was just momentarily confused into expecting it to.
> Also, AppleScript is more dynamic than Perl and doesn’t know whether a
> command is a “list operator”, either.
Whoa, back up there, Nelly. Could you explain what you mean by "more
dynamic" than Perl?
> Adding this information about commands is an interesting idea, though it
> opens the door to user confusion. When the rules become more subtle and
> complex, it makes it harder for someone to read and understand code without
> first looking up the definitions of every term seen. i.e., someone would
> have to know the precedence of every command in a script to be sure of its
> meaning. Treating all commands with the same precedence may confuse some in
> some cases, but once explained the rules are easy to correctly remember and
> apply.
When it comes to precedence, my preference is to parenthesize early
and often, to make it clear what's going on. Sometimes I get carried
away, in which case the extraneous parentheses can overwhelm the
reader and negate the clarity benefit. So then I will trim some of
them even if the result is ambiguous to the underinitiated.
> 1. The “round” command takes a parameter “rounding” that includes the
> ability to perform a floor (or other) operation:
> round 1.9 rounding down -- i.e., "floor"
> --> 1
Ah, I see. Plain "round" rounds to the nearest integer, "round
rounding down" does a floor(), "round rounding up" does a ceil(), and
"round rounding toward zero" does a trunc(). Good enough. No
enhancement request forthcoming. :)
> 2. Coercion is a limited and sometimes ambiguous operation that should be
> used sparingly. I think it’s probably unfortunate that you can coerce a
> non-integral float to an integer. It’s better to provide a robust set of
> operations like rounding and truncating, which may be used to implement the
> desired semantics precisely.
I agree. So let's get back to the topic of defining a robust set of
operations for converting a numeric value into text... :)
--
Mark J. Reed <email@hidden>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden