Re: Operator vs. Command precedence
Re: Operator vs. Command precedence
- Subject: Re: Operator vs. Command precedence
- From: Chris Page <email@hidden>
- Date: Fri, 05 Jun 2009 14:13:44 -0700
On Jun 4, 2009, at 9:47 PM, Mark J. Reed wrote:
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. :)
Clarification: I am not a fan of “magic” that consists of an heuristic
or subtle, non-obvious behavior that, though perhaps intended to “do
the right thing,” is in fact only one of several possible “right
things,” ultimately making it more difficult for a programmer to
correctly predict the behavior of some code. This is made worse in
cases where there is no means for the programmer to explicitly
disambiguate. e.g., although I think it is incorrect to support
coercing non-integral floats to integers, at least you can still
explicitly convert using “round” and its options for rounding, floor
and truncation. If the latter weren’t the case, you’d be in a worse
position if the coercion to integer didn’t do it the way you wanted it
to.
Note that I’m not criticizing any particular feature of Perl here.
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…
No AppleScript command arguments go in parenthesis. Command arguments
are interleaved with the command and parameter names. I believe what
you’re saying is that your expectation is that “floor” should be an
operator either because it only takes one argument or because you know
“floor” is a unary operator in mathematics. That’s what I was
referring to when I wrote, "there are probably reasons … not to assume
that any one-parameter command is to be treated as [an operator].”
I’m just saying that if we were to allow the definition of new
operators (or operator-like commands) we should probably introduce
some explicit means to declare this and not rely on any heuristics.
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?
The Perl rule you mentioned implies that the Perl parser knows when a
function is a “list operator,” indicating that the compiler must have
more static information available about the definition of a given
identifier than does AppleScript, generally. i.e., in AppleScript the
meaning of “foo” at runtime is (apparently) more dynamic than the
meaning of “foo” in Perl.
--
Chris Page
_______________________________________________
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