Re: (2 of 2) Application Scripting Question - Theoretical? (was Re: Technote 2106 is da Bomb)
Re: (2 of 2) Application Scripting Question - Theoretical? (was Re: Technote 2106 is da Bomb)
- Subject: Re: (2 of 2) Application Scripting Question - Theoretical? (was Re: Technote 2106 is da Bomb)
- From: BJ Terry <email@hidden>
- Date: Tue, 13 Apr 2004 20:09:57 -0700
On Apr 13, 2004, at 7:56 AM, Axel Luttgens wrote:
Notwithstanding the "exactly" locution, you are in fact speaking about
the general nature of a programming language, which uses tokens to
describe actions to be performed.
And sometimes those tokens have various interpretations according to
their context.
I don't see why AppleScript should differ, from that point of view,
from
any other language.
More exactly, I don't see why such a behavior should be considered as
buggy when happening with AppleScript; unless, of course, that behavior
goes against the specifications.
While the behaviour isn't buggy, it certainly isn't consistent. It
isn't enough to say that "programming language tokens have various
interpretations according to their context," the issue is that it is
needlessly inconsistent. One SHOULD be able to "set contents of x to
{3, 5, 6}" if x is a list of three items, simply because it's a more
powerful expression. It just makes sense in terms of the expressions
one can write now. How AppleScript does differ, and shouldn't, is in
its lack of power, because of issues like this. In Perl, one can pass
around lvalues. In that language, things are made inconsistent, but
never without reason. Context-sensitivity improves the ease of use of
the language. In my daily language (Scheme), everything in the language
was designed for almost perfect consistency. Obviously, things have
different meanings in different contexts, but it isn't arbitrarily
limiting as in AppleScript. That is why AppleScript is a toy language,
even though it has no need to be.
I'd think it oddly inconsistent that for the one case of multiple
assignment, the left hand side of the 'set' wasn't a real AS type.
So, let's suppose that the pattern matching behavior were not
restricted
to syntactic constructs, but allowed to occur in a dynamic (ie
execution) context, so as to be more "useful".
What should then be the meaning of, for example:
set x to 1
set L to {a reference to x, 2}
set L to {3,4}
Asign {3, 4} to L?
Or asign 3 to x (but then, how could second line have even worked)?
Or should one need to introduce new operators/commands to avoid any
ambiguity?
Obviously, if you simply set a symbol to something, that symbol should
take on the meaning you were setting it to, so L would be {3, 4}. In
this case we already have a keyword which makes sense in this
situation, "contents". If someone asked me about the following:
set x to 1
set L to {a reference to x, 2}
set L's contents to {3, 4}
I would expect it to behave in a manner consistent with AppleScript's
normal behaviour, multiple simultaneous assignment.
So, let's take a line of code such as "set {...} to {...}" for exactly
what is is in the language's framework: some kind of convenient
notation, nothing more.
We shouldn't forget that AppleScript provides a basis for interacting
with other apps; it thus has to somehow remain humble.
So as to allow other apps to introduces their own data handling
conventions (such as bulk asignements) without fearing (in principle)
some bad interactions.
Developer are so bad at supporting the commands that are given to them,
I don't know that they can be trusted to see the wisdom of implementing
new, extremely useful but somewhat creative commands.
This wouldn't even be an issue, except that the Apple Event server is
so incredibly slow. Almost any operation which ends up iterating
through a list of references, for example, becomes unbearably slow. We
have workarounds, but the goal is always, in AppleScript, to do more
work with fewer events. Really, if we could see an improvement in the
speed of Apple Events, we could do away with much of what makes writing
scripts hard.
BJ
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.