Re: Why is AppleScript compiled?
Re: Why is AppleScript compiled?
- Subject: Re: Why is AppleScript compiled?
- From: email@hidden (Michael Sullivan)
- Date: Mon, 11 Aug 2003 17:51:41 -0400
- Organization: Business Card Express
>
Does anyone know why AppleScript is a compiled language? When introducing
>
people to AppleScript, it has happened that someone was surprised that
>
AppleScript is compiled instead of being simply interpreted like shell
>
script or Perl. And when asked the question, I can't figure out why Apple
>
made that choice. Does anyone know?
Applescript isn't compiled in the sense that most people mean when they
talk about a "compiled language". "Compiled language", as people tend
to use it, is a misnomer. Implementations can be compiled or not
(though most implementations of most languages do at least some
compiling even if they are not "compiled"). I suppose you could define
a language standard that said conforming implementations must *only*
interpret, or *only* compile, but that would be pretty stupid, since
there is no good reason for the restriction.
The compilation that applescript does is much more like parsing and
syntax checking than what happens when one compiles a C program in
codewarrior, frex. What you end up with is a kind of bytecode. Your
program is converted into an internal representation that doesn't look
much like your original "english-like" program, but if you looked at and
understand the file, it's essentially the same program and the same
language, just that all your easy to remember names have been converted
to the 4-character codes of their internal representation, etc. The
structure is essentially the same (except you probably have
s-expressions or some kind of parse tree in place of english-like
syntax)
This is exactly what compilers typically do as their first step.
As far as speed-up is concerned, this middle step doesn't make for a
huge improvement over a pure interpreter (that looks straight at the
actual source code file, a la dos batch files, or shell scripts in
unix), but it's worth something (especially on slow machines).
The real speed gain from compilation comes when converting to machine
code. In applescript that's done solely at run time, which is one
reason (among many) that you would not normally use applescript for very
computationally intensive tasks.
The advantage of interpretation is that good debuggers are relatively
easy to write (compared to source debuggers for compiled programs), and
the time to run a first bit of code is much less. If you have a
complicated C program, a compile might take half an hour or more, and
any change usually requires recompiling your whole project. In
applescript, you only need to recompile (parse) the file with the
change, and even that is faster since you are mostly parsing, and not
translating/optimizing/etc.
Interpretation generally trades off runtime speed in favor of
development speed. More often than not, this is a good trade. In an
ideal world (subliminal man: lisp) you can choose your paradigm, and run
interpreted when you want, and compile when you want (or compile
individual functions that are time consuming, leaving other stuff
interpreted.
Note that it's a lot of work to write a really good compiler for a
language with as much flexibility as applescript. For the most part,
scripting languages get interpreted (or mostly interpreted, like AS) for
this reason. If applescript were ever to be adopted as a serious
general purpose language, it would have to either end up with an IDE
that operated more like a typical lisp environment in this respect
(IMO), or a lot of powerful compiled libraries (like Perl/Python).
Michael
_______________________________________________
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.