• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Compiler oddities
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Compiler oddities


  • Subject: Re: Compiler oddities
  • From: has <email@hidden>
  • Date: Sat, 02 Jul 2016 14:29:16 +0100

Shane Stanley wrote:
On 2 Jul 2016, at 10:07 PM, 2551phil <email@hidden> wrote:
>
>How come?
You have to tell the compiler where to look up the terminology, which means before theSysEvents is resolved.

using terms from application "System Events"
	set theSysEvents to "System Events"
	tell application theSysEvents
		set theItems to name of every file of folder "bin" of folder "usr" of startup disk
	end tell
end using terms from


You mean, "before the `tell application ...` block is parsed". This is purely a compile-time issue. It has nothing to do with evaluation of expressions like `theSysEvents` which can only be resolved when the script is actually run.

For those that aren't aware of how AS parsing works, the AS parser treats `tell application STRING_LITERAL ... end tell` blocks as a special case[2], using them to locate the application whose terminology it should import and use those terms in addition to AS's own [1] to identify tokens within that block. If you replace that text literal with an expression that can only be evaluated at runtime then the AS compiler cannot automatically import that extra terminology so will only recognize terms it already knows (e.g. 'file', 'properties') but not others (e.g. 'startup disk').

Wrapping the relevant section of code in a 'using terms from APPLICATION_SPECIFIER ... end using terms from' block explicitly tells the AS parser to load and use the terms from the specified app when parsing the code within that block, avoiding the need for magical 'tell' block behavior to do it for you. Ugly and clunky and not user-friendly at all, but within the limitations AppleScript has established for itself probably the best and only practical workaround it could hope for.

As I've said before, AppleScript is all smoke-n-mirrors and sleight of hand: it tries to give you an English-like syntax, but to do so it cheats like mad. Most of the time it gets away with it, as long as users stick to established 'safe' idioms such as writing `application "NAME"`, not `application VAR`, as the target of the tell block. As soon as you step of the trodden path though, all that cleverness turns into a big old shitshow. And then of course you're on your own, as the whole reason AppleScript was lying to you in the first place was that so it wouldn't have to explain to you just how gory and complex it really is, so of course it doesn't.

..

Aside: Crap like this is one of the big reasons I've gone into end-user language design myself. AppleScript has already proven that having white space in names can and does provide some significant usability advantages - not least that it looks much more inviting to non-programmers - but it's also proven that doing it via deep dishonesty is absolutely the wrong way to do it: a false economy that ultimately bites its users on the butt in the most unexpected and unfriendly ways possible. Still, I absolutely believe the overall objective is sound. I already made some progress in my artwork templating language, kiwi [3], which freely allows spaces in names simply by not using white space for anything else; whereas AppleScript and most other languages use a combination of white space and punctuation to delimit 'words', kiwi relies on punctuation only. The downside of kiwi's syntax is the bane of all Lispy syntaxes: too many damned irritating parentheses everywhere (though kiwi code, being special-purpose, rarely gets complicated enough for that to become a major problem).

If/when I get back to working on entoli, my general-purpose Logo-AppleScript mashup, I'm fairly confident I can achieve a good balance between visual clarity (white space in names, minimal parenthesizing) and rigor (clear and unambiguous meaning, no 'magical' cheats), at which point we could be looking at something that finally delivers on [almost] all the end-user friendliness AppleScript originally promised. Though the day job's gotta come first so unless someone wants to sponsor that work it'll probably be a while before I get back to it. The only thing that surprises me is that nobody else in academia or business has tried to do it themselves, especially with word-centered technologies like Siri taking off; but, eh, programmers… just means more opportunities for the rest of us. :)

HTH

has

--

[1] Ditto for 'tell script TEXT_LITERAL ... end tell' blocks in 10.9 and later.

[2] Strictly speaking, AS's own terminology *plus* any global terminology injected by scripting additions and/or `use` statements.

[3] http://www.mantasystems.co.uk/documentation/kiwi-language-guide/introducing_values.html

_______________________________________________
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


  • Prev by Date: Re: FastScripts and script editor discrepancies
  • Next by Date: Extracting Table Data from Word 14.6.5
  • Previous by thread: Re: FastScripts and script editor discrepancies
  • Next by thread: Extracting Table Data from Word 14.6.5
  • Index(es):
    • Date
    • Thread