rewrite set variable statement order

Stupid question. How do you rewrite this statement?

tell application "System Events" to set theName to (name of every process whose bundle identifier is theBundleName)

I tried this but it doesn’t compile

set theName to (name of every process whose bundle identifier is theBundleName) of application "System Events"

stupid answer :

why are you wanting to use this odd syntax when you know the correct one ?

My understanding is that, as long as you don’t tell it that you are speaking to “System Events” the editor is unable to decipher what is a process so it can’t compile.

Yvan KOENIG running El Capitan 10.11.3 in French (VALLAURIS, France) samedi 12 mars 2016 16:43:04

tell application "System Events" to set theName to (name of first process whose bundle identifier is theBundleName)

‘every’ returns a list.

Touted by Apple when they introduced Libraries, but not to be used in my view:

use application "System Events"

set theName to (name of first process whose bundle identifier is theBundleName)

Just for readability sake.and just to know.
Sometimes you have a bunch of vars that you declare with the form set var to value of something of something and having one tell statement to set a var is somewhat odd, so I’d prefer the former syntax, if possible at all.

I use AppleScript 2.2.4.

As I wrote, as long as you don’t explicitly tell it that you are speaking to “System Events” the editor is unable to know what is a process.
Worse, If you tell it that you will use the vocabulary recognized by System Events :

set theBundleName to "com.apple.iWork.Numbers"

using terms from application "System Events"
	name of every process whose bundle identifier is theBundleName
end using terms from

The editor will be able to compile but the script will fail at execution issuing :
error “Il est impossible d’obtenir every process whose bundle identifier = "com.apple.iWork.Numbers".” number -1728

To be complete, the syntax given by Nigel

set theBundleName to "com.apple.iWork.Numbers"

use application "System Events"
name of every process whose bundle identifier is theBundleName

works under 10.11.3but the events log is exactly the same than the one returned by the original syntax.
Both return the log :

tell application “System Events”
get name of every process whose bundle identifier = “com.apple.iWork.Numbers”
end tell
Résultat :
{“Numbers”, “Numbers”}

Yes, two processes named Numbers because Numbers v2.x and Numbers v3.x share the same process name and the same bundle identifier - which is really annoying because some features available in Numbers v2.x aren’t available in v3.x.
If we quit Numbers v2.x, its process is removed.
If we quit Numbers v3.x, its process remains in memory so, if you run v2.x after quitting v3.x, you have two processes with same name and same bundle identifier.
Happily, there is a way to identify the one to which we want to speak.

Numbers v2.x uses architecture “i386” while Numbers v3.x uses architecture “x86_64”

so,

set theBundleName to "com.apple.iWork.Numbers"

use application "System Events"
application file of first process whose bundle identifier is theBundleName and architecture is "x86_64"
--> {alias "SSD 500:Applications:iPlay '13:Numbers.app:" of application "System Events"}

and

set theBundleName to "com.apple.iWork.Numbers"

use application "System Events"
application file of first process whose bundle identifier is theBundleName and architecture is "i386"
--> alias "SSD 500:Applications:iWork '09:Numbers 09.app:" of application "System Events"
set theBundleName to "com.apple.iWork.Numbers"

use application "System Events"
name of application file of first process whose bundle identifier is theBundleName and architecture starts with "x86_"
--> Numbers.app
name of application file of first process whose bundle identifier is theBundleName and architecture is "i386"
--> "Numbers 09.app"

Yvan KOENIG running El Capitan 10.11.3 in French (VALLAURIS, France) samedi 12 mars 2016 18:03:19

I thought the editor would figure it out in the background. Oh well.I guess it’s the way it is.