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: Axel Luttgens <email@hidden>
- Date: Tue, 13 Apr 2004 16:56:43 +0200
Michael Terry wrote:
[...]
But what we've never realized before, because it takes hair-splitting
examinations like this one to tease these things out, is that the list
on the left hand side of a multiple assignment is not just a
convention. It's really a list:
set {x, 7} to {3, 4}
--> {3, 4}
As I wrote in my previous post, this doesn't go about setting lists to
some values.
The above is a just a syntactic matter, kind of pattern matching.
Going back to the ASLG, the "set" command syntax is defined as:
set variablePattern to expression
a variablePattern being "a variable, a list of variable patterns or a
record of variable patterns" and thus having a class of identifier, list
or record.
So, in your "set {x, 7} to {3, 4}" statement, the 7 appearing on the
left-hand side is just a place-holder allowing to ensure that x will be
matched to its companion 3.
And the important thing to note is that as soon your asignement
syntactically differs from "set variablePattern to expression",
AppleScript will go with its usual dynamic rules: evaluate the left-hand
side in to hope to get something asignable, and asign the evaluated
right-hand side to it.
Another big point: that syntactically induced behavior is really a very
basic one:
set {1 + 2, 3} to {4,5}
--> can't set 1 + 2 to item 1 of {4, 5}
Well... just what you said: who would expect some kind of sanity checks? ;-)
Now, it could well be that AS internally constructs the left-hand side
list and tries to pair it with the right-side one.
But the syntax embedded in the compiler clearly leads, for all practical
purposes, to a one to one asignement interpretation.
If it were just a convention to set variables--'set a to 3' and 'set 7
to 4' in parallel--then the 'set 7 to 4' part would raise an error.
It's not the first time AS has let me work with a list literal in the
code:
tell {}
repeat 5 times
set its end to 1
end repeat
return it
end tell
--> {1, 1, 1, 1, 1}
I'm not sure it goes about working with literals.
Through above code, one is asking AppleScript to consider an object
initialized with an empty list, not asking AppleScript to act upon
literal {}.
Sometimes, such objects will also be created implicitely (as soon as one
uses for example lists, records, dates):
set item 1 of {1, 2, 3} to 4
--> 5
but those objects are then fully anonymous ones that will disappear on
the next garbage collection.
Look, if even this doesn't fail:
set {1, 2} to {3, 4}
It doesn't fail because you are in the syntactic "set variablePattern to
expression" context (even if somewhat useless here ;-) )...
... then why should this? (supporting code omitted):
set contents of {a, b} to {3, 4}
... while this one will result in the evaluation of "contents of {a, b}"
for the search of an lvalue.
If we write:
set a to 1
... I don't think it's fair to say that 'a' is just a convention
there. It's a literal reference, 'a of <<script>>'.
Yes, it would be unfair as it is the result of LOTS of conventions that,
put together, end up to associate identifier "a" to a property or a
global variable or a local variable.
If we write:
name of first file of app "Finder"
... that's a literal reference, and we can also put it in a variable:
set a to ref name of first file of app "Finder"
--> name of file 1 of application "Finder"
The result looks exactly like it would if we typed it in the code.
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.
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?
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.
[...]
Can you think of a way to show that the result is really the list on
the right, and not, well, the result? I couldn't come up with one.
Well, what about this one:
set {x, 2, 3} to {1, 2}
--> {1,2}
x
--> 1
Hmmm...
Who spoke about a very basic behavior?
Axel
_______________________________________________
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.